headers
Kurzweil | 1 Dec 18:46
Picon

[Trac-dev] Re: Workflow branch


> Not at this time.  Alec deleted the old branch since major changes in
> the trunk made it more difficult to merge those changes into the branch
> than to start fresh and reimplement the changes on top of the current
> trunk.  Most of the changes have not yet been added back to the new
> branch, so it's not very useful at this time.  You can go back and
> check out the earlier branch prior to its deletion, but of course the
> APIs are likely to change before it's completed.

This news is bit disheartening.

We are currently heavily using Trac at our shop and have found the
workflow branch enormously helpful in allowing us to create plugins for
milestone and ticket dependencies and ticket priorities. Are there any
estimates on the time and work required to reintegrate the workflow
changes? Workflow api enhancements are something I can see my company
devoting resources in helping your project. Please advise.

I can be contacted directly at: kkurzweil (at) lulu (dot) com

I have also included a diff of a few of the suttle changes we have made
so far. They, and ofcourse the changes found in the workflow branch,
have allowed us to write the plugins we needed for our process. These
were some of the changes we would have liked to eventually submit as
patches.

Index: model.py
===================================================================
--- model.py	(.../vendor/workflow-r3578/trac/ticket/model.py)	(revision
564)
(Continue reading)

Permalink | Reply | 0 comments |
headers
trac | 1 Dec 23:11
Picon

[Trac-dev] separating Ticket history and Ticket status was Re: PROJECT - Inproper usage of Milestones within Trac Edgwall org


Hi,

sorry for not answering earlier, esp. there was some interesting 
feedback for this issue.

>> I think, that the issues and issue status are not necessarily a 1 to 1 
>> relationship. For example you can have an issue in the software that 
>> will affect one release branch and the current trunk. You need to close 
>> the issue in both pathes, in order to be sure that you have solved the 
>> problem forever. Currently I copy tickets and cross reference them, but 
>> this is extra overhead. 
>>     
>
> I think there are many ways we could address this in the future.
> The first idea would be to have a 1-n relationship from tickets to 
> milestone, and declare a ticket closed when it's fixed in all the 
> relevant milestones.
>   

Is there an explicit need to finally close a ticket? I don't think so. 
If the ticket doesn't show up in any relevant branches, you can consider 
the ticket closed. But a lot of tickets in trac itself, which are closed 
in later versions are still open in earlier versions. No one is 
interested in this any more.

I would prefer to distinguish between static or ticket related 
information, like component or keywords, and version or source related 
information like milestone and priority. Even the "assign to" field 
could be different for two different maintenance paths of the software.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Boos | 2 Dec 11:53
Picon

[Trac-dev] Re: separating Ticket history and Ticket status was Re: PROJECT - Inproper usage of Milestones within Trac Edgwall org


trac <at> nogga.de wrote:
> Hi,
>
> sorry for not answering earlier, esp. there was some interesting 
> feedback for this issue.
> <snip>
>   
> ...
> Consider the following scenario:
> <snip> 
> ... could be solved by 
> a tighter integration with subversions custom properties, e.g like the 
> svnmerge properties. You would assign a ticket to a specific revision, 
> and as long as you don't close it in another revision the ticket will 
> show up in the leaf of this branch.
>   

Thanks for the clarifications, I see know what you meant with the 
repository level branches vs. the version/milestones and ticket status.

Please also take a look at: http://trac.edgewall.org/ticket/4298

-- Christian

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeroen Ruigrok/asmodai | 3 Dec 10:30
Gravatar

[Trac-dev] Re: separating Ticket history and Ticket status was Re: PROJECT - Inproper usage of Milestones within Trac Edgwall org


-On [20061201 23:11], trac <at> nogga.de (trac <at> nogga.de) wrote:
>Is there an explicit need to finally close a ticket?

In general, without all the other context of this thread: yes.

It is the last state in the finite automata of the ticket workflow. It means a
ticket has been dealt with, one way or another.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
Seize from every moment its unique novelty and do not prepare your joys...

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
mbern@gmx.net | 3 Dec 14:37
Picon

[Trac-dev] Custom checkboxes and genshi ???


Hi,

we'd like to add a few custom fields to our trac installation. One of
these fields
is a checkbox, that must be checked by default. So I set the value to
"1" in the
trac.ini. This value is placed in the value attribute of the checkbox,
which doesn't
help very much, since the state of a checkbox is determined by the
attribute
checked.

Did I make a mistake or is this a known (or even new) bug?

Now to the genshi part of the subject. I tried to tweak the genshi
templates, so that
the checked attribute would show up. I changed the lines pertaining to
checkboxes
in ticket_new.html to the following:

        <input py:when="'checkbox'" py:if="field.value == 1"
               type="checkbox" id="field-${field.name}"
               name="field_${field.name}" value="${field.value}"
               checked="checked" />
        <input py:when="'checkbox'" py:if="field.value == 0"
               type="checkbox" id="field-${field.name}"
               name="field_${field.name}" value="${field.value}" />

This leads to the checkboxes not being displayed at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Waldemar Kornewald | 3 Dec 18:45
Favicon

[Trac-dev] UserDirectory


Hi,
what is needed to finally get real user support integrated into Trac?
There is IUserDirectory, but that patch
(http://trac.edgewall.org/ticket/2456) wasn't accepted because it
didn't seem to make you happy. I'd like to work on a simple patch with
a new interface to finally make it possible for authentication plugins
to provide extra user data instead of using the session API.

What do you need, exactly?

Is the following interface good enough? It consists of two interfaces
which separate the user from his attributes. In order to make the API
centrally accessible, I'm planning to add a UserManager (as part of
the env) which will provide the same functions as the two interfaces.

class IUserDirectory(Interface):
    """
    Extension point interface for backends that store known users.
    """

    def get_known_users(self):
        """
        Generator that yields a list of known users.

        @return username
        """
        pass

    def delete_user(self, username):
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ilias Lazaridis | 4 Dec 02:57
Favicon
Gravatar

[Trac-dev] POLICY - Ticket Descriptions should be treated as "original content"


mgood has removed an addition to the TracTicketTriage completely, with
the comment:

"editing descriptions is limited to administrators and we're capable of
making that judgement on our own"

http://trac.edgewall.org/wiki/TracTicketTriage?action=diff&version=29

-

My change relates to the following ticket:

"
I've noticed that ticket descriptions are changed.

Ticket descriptions are "original content", that should not be changed.
That's way comments are fore. Only the original author should change
his own wording.

If the team decides to not protect "original content", then it should
be possible to track the changes, thus anyone can verify who's written
what.

see #4297 for an example

(this should be clarified within the relevant project documentation)
"
http://trac.edgewall.org/ticket/4299
(Continue reading)

Permalink | Reply | 12 comments |
headers
Ilias Lazaridis | 4 Dec 03:46
Favicon
Gravatar

[Trac-dev] POLICY - Patch Acceptance


In order to engourage other projects to use the *original* trac source
code base instead of writing customized code, a patch acceptance and
application policy should be provided.

This is mainly to avoid rejection of patches, e.g. due to personal
reasons, non-understanding reasons (e.g. due to missing time) etc.!

A patch from a contributor A could be rejected, but the patch would be
of benefit for the reusability of the trac-code-base, and thus for all
other users.

A example rule of such policy could be:

 * A patch which makes a function general, thus it can be used from
outside of trac-application
  * should be applied *immediately*, if the existent behaviour is not
broken.

-

An example:

This patch would pass without *any* discussion, as it enables the
"load_components" function (implemented as one function with one env
parameter) to be used in conjunction with searchdirs passed as an
optional parameter:

http://trac.edgewall.org/attachment/ticket/4317/LoaderOptionalSearchdirs.diff
(Continue reading)

Permalink | Reply | 16 comments |
headers
Brad Anderson | 4 Dec 04:30

[Trac-dev] Re: POLICY - Ticket Descriptions should be treated as "original content"


Ilias Lazaridis wrote:
> mgood has removed an addition to the TracTicketTriage completely, with
> the comment:
> 
> "editing descriptions is limited to administrators and we're capable of
> making that judgement on our own"
> 
> http://trac.edgewall.org/wiki/TracTicketTriage?action=diff&version=29
> 
> -
> 
> My change relates to the following ticket:
> 
> "
> I've noticed that ticket descriptions are changed.
> 
> Ticket descriptions are "original content", that should not be changed.
> That's way comments are fore. Only the original author should change
> his own wording.
> 
> If the team decides to not protect "original content", then it should
> be possible to track the changes, thus anyone can verify who's written
> what.
> 
> see #4297 for an example
> 
> (this should be clarified within the relevant project documentation)
> "
> http://trac.edgewall.org/ticket/4299
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ilias Lazaridis | 4 Dec 04:48
Favicon
Gravatar

[Trac-dev] Re: POLICY - Ticket Descriptions should be treated as "original content"


Brad Anderson wrote:
...
> Dude, didn't you promise to leave in like three months [1] if you couldn't get
> things done to your satisfaction?  Isn't that time here now?

not exactly, I just said that I'll work 3 months intensive on track:

RFC - Simplify multiple installations with shared environments
http://groups.google.com/group/trac-dev/msg/5a29018a024244a7

Due to the missing cooperation of the team (which has oviously a main
goal to delay the 0.11 release even more than the 0.10 release), I need
to work more autonomously, thus I'll not fulfill everything within 3
months.

But whatever happens, the 'base' project will go 'live' on 2007-01-01,
and it's main component will be trac 0.11dev.

http://dev.lazaridis.com/base

> BA
>
> [1] I have no link to back this up.  Merely wishful thinking.
>
> http://dev.lazaridis.com/base/getthefuckoutofhere

People like you make companies taking open source not that serious as
the could, keeping commercial interest and thus development resources
out of the projects.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane