PROJECT - Inproper usage of Milestones within Trac Edgwall org
Ilias Lazaridis
Essentially, the milestone mechanism is 'abused' as a "release
mechanism".
But the meaning of a milestones is different.
As an example, take "Milestone 0.11" (which essentially means:
_release_ 0.11)
* Ditch ClearSilver in favor of Genshi for templating (r3832)
* Timezone support and internal use of datetime (r3935)
* Use jQuery for Javascript (r3947)
* Integration of WebAdmin into core (r4095)
All 4 points above are essentially "milestones" (at least ClearSilver
and WebAdmin)
The "In the works:" section contains "milestones", too:
* Use setuptools for setup (see sandbox/setuptools)
this would be the next to reach _milestone_ on the _way_ to the _goal_
(_release_ 0.11).
Of course this would contribute to exact what trac is for: _tracking_
of the development.
[sidenote: Tickets subjecting this milestone would be assigned to it,
developers/contributors would join forces to reach this milestone].
-
Some more thoughts:
The next (tiny) milestones would be "sqlalchemy", "refactoring",
"OO-Model" and then "workflow" (very complex topic, which will become
much simpler based on the simplified sources and implementation).
0.11.0.x - developement milestones
0.11.1 - first release
Automated release mechanisms would enable users to fetch this way the
"latest stable 0.11 dev milestone".
.
tr...@nogga.de
> Essentially, the milestone mechanism is 'abused' as a "release
> mechanism".
>
sorry for answering in the developer list and not beeing an active
member or even a contributer of source code.
I would like to add one more point to this "thought" of milestones and
releases, that is very important for release tracking and that plagues
me every day.
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. Additionally the tree nature of source control
systems could automatically help in tracking defects through the
branches if one could assign the defect to a specific revision.So the
ticket stays open in one branch until someone comes by and closes it,
while it is already closed and released in a maintenance release for
another branch.
One of the current problems is exactly that there is no idea of version
numbers and their logical order. The second problem is, that the issues
and issue status fields are tight together.
If I only could provide some code or even had some time to help out in
this field, ...
Best regards
Dirk
Erik Huelsmann
> numbers and their logical order. The second problem is, that the issues
> and issue status fields are tight together.
Looking at one of the communities I'm part of the developer community:
In the Subversion community there is no logical ordering of version
numbers: 1.3.3 may well be released after 1.4.0, so, I like the
current scheme: it doesn't impose any ordering which might not fit my
needs. (I don't mean to imply Subversion actually uses Trac to track
issues...)
I do feel the multiple-branch-fix problem wrt. issues though: I'd like
to be able to close an issue on trunk while it may stay open for a
release branch until the release has actually been done. I'm not sure
this is within the bounds of Trac though: I like Trac for its
simplicity and having this functionality seems like a major feature to
add (and making it far more complex).
bye,
Erik.
Christian Boos
> Hi,
>
>
>> Essentially, the milestone mechanism is 'abused' as a "release
>> mechanism".
>>
>>
>
> sorry for answering in the developer list and not beeing an active
> member or even a contributer of source code.
>
He, no problem, contributions from long time users are more than
welcomed on this list as well ;)
> I would like to add one more point to this "thought" of milestones and
> releases, that is very important for release tracking and that plagues
> me every day.
>
> 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.
Another idea would be to use sub-tickets, with sub-tickets for detailing
the status of a particular issue and the particular way it should be
solved in each branch. The cross-referencing would come for free
(providing the SubTickets feature is implemented, of course).
> Additionally the tree nature of source control
> systems could automatically help in tracking defects through the
> branches if one could assign the defect to a specific revision.So the
> ticket stays open in one branch until someone comes by and closes it,
> while it is already closed and released in a maintenance release for
> another branch.
>
I'm not sure I fully understand you here. Do you mean there should be
known relationship from branches and milestone/version and when a branch
is created, the existing bugs are updated and linked to the
corresponding milestone (in the ticket -1--n-> milestone scenario)?
> One of the current problems is exactly that there is no idea of version
> numbers and their logical order. The second problem is, that the issues
> and issue status fields are tight together.
Ok, possibly there could be something done on the ticket <-> milestone
relationship.
-- Christian
Ilias Lazaridis
> Hi,
>
> > Essentially, the milestone mechanism is 'abused' as a "release
> > mechanism".
>
> sorry for answering in the developer list and not beeing an active
> member or even a contributer of source code.
>
> I would like to add one more point to this "thought" of milestones and
> releases, that is very important for release tracking and that plagues
> me every day.
> If I only could provide some code or even had some time to help out in
> this field, ...
I suggest the following process:
Ask on the trac-user list how other users handle your problem (open one
topic for each problem).
Then, if you see that there's no solution/workaround available that
you've overseen, you can file tickets, one for each problems that you
have:
http://trac.edgewall.org/newticket
>From a personal estimate, it does not look that the functionality
you've described will go soon into trac.
Finally, there's always the option to rent developer time, although the
task must
a) the taks must be applicable with reasonable effort
b) the task must fit into the developers shedule
e.g., it would not fit in my personal shedule / plans:
http://dev.lazaridis.com/base/wiki/WorkingPlans
and (as said above) it does not look that this functionality could be
implement with reasonable effort in the current implementation of trac.
.
Christian Boos
>> One of the current problems is exactly that there is no idea of version
>> numbers and their logical order. The second problem is, that the issues
>> and issue status fields are tight together.
>>
>
> Looking at one of the communities I'm part of the developer community:
> In the Subversion community there is no logical ordering of version
> numbers: 1.3.3 may well be released after 1.4.0, so, I like the
> current scheme: it doesn't impose any ordering which might not fit my
> needs. (I don't mean to imply Subversion actually uses Trac to track
> issues...)
>
... but usually 1.4.1 comes after 1.4.0, at least 1.4.2 does, no? ;)
The current ordering in Trac is quite intuitive: first the closed
milestones, sorted by the completion date, then the opened milestone,
sorted by scheduled date, finally the opened and not scheduled
milestone, sorted using the "natural sort order" (i.e. 0.10 comes after
0.9). The only improvement I think we could still make is to make this
grouping more apparent in the UI.
> I do feel the multiple-branch-fix problem wrt. issues though: I'd like
> to be able to close an issue on trunk while it may stay open for a
> release branch until the release has actually been done. I'm not sure
> this is within the bounds of Trac though: I like Trac for its
> simplicity and having this functionality seems like a major feature to
> add (and making it far more complex).
>
Well, there's always the possibility to simplify things in one area, and
make it slightly more powerful in another, so the overall simplicity is
preserved.
For example, we could think about merging the version/milestone into a
single concept (named version/release/milestone, whatever, but *one*
thing). That would be on the simplification side of things.
Then, the "Version" field could be renamed "Affects" and contain
multiple releases and the "Milestone" field could be renamed "Scheduled
for" and contain multiple releases as well, like one of our not-so-free
competitor does.
For the status, a global "closed" state is probably enough in most cases
when the fix is done for all the scheduled versions. Likewise, if a fix
in a new version is needed (e.g. a regression happens), then the bug
could be globally reopened.
-- Christian
Sergey Lipnevich
> For the status, a global "closed" state is probably enough in most cases
> when the fix is done for all the scheduled versions. Likewise, if a fix
> in a new version is needed (e.g. a regression happens), then the bug
> could be globally reopened.
I'm nor sure I follow. To take three most common use cases, let's
suppose ticket 123 is closed on trunk with next milestone v5 and open
on branch 4.5 with the next milestone v4.5.6. #1: search for all
tickets for milestone v4.5.6 has 123 as open. #2: search for all
tickets for milestone v5 has 123 as closed. #3: search for all open
tickets must show 123 as open. Does having a global state for a ticket
work for all of these?
If milestones are used for short iterations, such as in agile
development, there's going to be many more milestones than branches.
Or, the other extreme, Trac itself has many milestones and many more
branches, all unrelated to each other. So milestones are valuable
regardless of whether Trac supports status-per-branch concept.
Sergey.
Ilias Lazaridis
> The use of milestones within the trac project seems incorrect.
The replies within this thread are going off-topic.
The main topic is:
> Essentially, the milestone mechanism is 'abused' as a "release
> mechanism".
...
it would be nice to have some comments from the trac-dev-team about
this issue.
.
Christian Boos
> Ilias Lazaridis wrote:
>
> ...
>> Essentially, the milestone mechanism is 'abused' as a "release
>> mechanism".
>>
> ...
>
> it would be nice to have some comments from the trac-dev-team about
> this issue.
>
Your proposal is basically a rehearsal of what I proposed myself in
another mail on trac-dev
(http://groups.google.com/group/trac-dev/msg/6b253d55c9588fd3). There, I
proposed to use 0.11preX milestones. In the follow-up thread, arguments
were brought against and we decided to keep things as they were. So I
don't see the need to repeat this discussion and probably nobody else
does either.
-- Christian
Ilias Lazaridis
> Ilias Lazaridis wrote:
> > Ilias Lazaridis wrote:
> > ...
> >> Essentially, the milestone mechanism is 'abused' as a "release
> >> mechanism".
> > ...
> >
> > it would be nice to have some comments from the trac-dev-team about
> > this issue.
>
> Your proposal is basically a rehearsal of what I proposed myself in
> another mail on trac-dev
> (http://groups.google.com/group/trac-dev/msg/6b253d55c9588fd3).
No, it is not.
> There, I proposed to use 0.11preX milestones.
In this thread you describe a possible workaround to the "milestones
are overloaded" problem, which I had 'described' already witthin this
thread:
Actual Roadmap (0.10 and 0.11)
http://groups.google.com/group/trac-dev/browse_thread/thread/5055720f18373119/#
> In the follow-up thread, arguments
> were brought against and we decided to keep things as they were.
ok
> So I don't see the need to repeat this discussion and probably nobody else
> does either.
Because this discussion/thread is about the "Milestones are abused as
Releases" problem.
The usage on "trac.edgewall.org" 'teaches' users into a wrong direction
(including me, that's why I was so confused about the milestones).
So, possibly the participants of this project should start to accept
that this is a high priority problem that needs to be addressed:
http://trac.edgewall.org/ticket/4236
.
Calen Martin D. Legaspi
Sub-tickets will allow us to do an initial planning of broad tasks then refine our plan into smaller and smaller sub-tasks later. Fits in better with an iterative planning process.
Calen
Emmanuel Blot
> that this is a high priority problem that needs to be addressed:
>
> http://trac.edgewall.org/ticket/4236
I think the reply from cmlenz says it all.
I understand that *you* are not satisfied with the way the project is
managed, but it seems ok to me.
Cheers,
Manu.
Christian Boos
> On 11/21/06, Christian Boos <cb...@neuf.fr> wrote:
>
>> For the status, a global "closed" state is probably enough in most cases
>> when the fix is done for all the scheduled versions. Likewise, if a fix
>> in a new version is needed (e.g. a regression happens), then the bug
>> could be globally reopened.
>>
>
> I'm nor sure I follow. To take three most common use cases, let's
> suppose ticket 123 is closed on trunk with next milestone v5 and open
> on branch 4.5 with the next milestone v4.5.6. #1: search for all
> tickets for milestone v4.5.6 has 123 as open. #2: search for all
> tickets for milestone v5 has 123 as closed. #3: search for all open
> tickets must show 123 as open. Does having a global state for a ticket
> work for all of these?
>
Well, having a global state is a bit how Trac works today, except that
one must pick either one milestone (v4.5.6) or the other (v5), so things
/appear/ to be more coherent. Likewise, when a regression happens, the
information about the original milestone is lost in the queries (the
info is still there in the ticket history, of course). So the status-quo
is not really satisfying either.
Ideally, if one wants to have the most precise information, there should
be one actionable ticket per release line, and the current model of
1-to-1 is OK for that, except for the overhead as Dirk said. Either the
TracCrossReferences ideas or the related SubTickets proposal could help
to ease that in the future. Instead of sub-tickets, maybe a plugin can
be made to add a "Clone ticket" button, that would also create the
appropriate relations.
Now there's also the JIRA model (and probably lots of other bug trackers
work like that too), where one can list multiple "affects version(s)"
and "fix version(s)" per ticket. I'm not sure how this is usually
handled, but I think that in JIRA at least there's only a global status
per ticket, and reopening a ticket seems(?) to clear all the fixed
versions; doing things this way would "work around" the problem you
described.
In that 1-to-n model, however, we could imagine going further and
provide detailed status information for each version, *provided* we know
the sequence information between the releases ("based-on" relations).
Let's take an example:
- in bug 123, "Affects version(s)" is "v4.5.4, v5", "Fix version(s)" is
"v4.5.6".
- we have the following sequence of releases: v4.5.4, v4.5.5, v4.5.6 and
v5, v5.1
Based on that information, we could display the bug #123 as closed in
v4.5.6, and opened in v4.5.4, v4.5.5, v5 and v5.1.
The global status would be used when working outside of the context of a
specific version:
- "opened" would mean "there's at least one version for which the bug is
open"
- "closed" would mean "the bug is closed in all development lines"
This approach would admittedly be a bit more complex to implement, not
to mention what would be required for more complex workflows where QA
states enter into play...
On the UI side, this could remain quite simple for the users:
- when creating a new milestone, one could simply pick a "base"
milestone in the list of existing milestones
- the reopen state transition could happen automatically as soon as a
new release is added in the "Affects" list and there's not already a
follow-up release that's listed in the "Fix" list
- the closed state transition could happen when for each release listed
in "Affects", there's a follow-up release in the "Fixed" list
- similar logic could be implemented for QA with a "Verified in
version(s)" field, for "closed-verified" intervals, in addition to
"opened-closed" ones.
> If milestones are used for short iterations, such as in agile
> development, there's going to be many more milestones than branches.
> Or, the other extreme, Trac itself has many milestones and many more
> branches, all unrelated to each other. So milestones are valuable
> regardless of whether Trac supports status-per-branch concept.
>
Indeed. The approaches suggested above would retain this flexibility, I
think.
-- Christian
Ilias Lazaridis
I cannot be satisfied with the way the project is managed - simply
because the project is essentially unmanaged.
But as you said, the replies of cmlenz (and other participants) within
ticket...
http://trac.edgewall.org/ticket/4236
say's it all.
I give up at this point, and will rearrange my development effort's, as
it is inpossible to synchronize/contribute to an unmanaged process-less
project, where the few existing core committers resist to give up any
control to the _many_ available subsystems.
I'll post a followup-thread shortly - and hope that the team assist me
at least to close the open issues which I cannot close in _any_ way
myself.
I will then reduce the new ticket's to just those issues which I cannot
implement as plugins or dyna-patches.
.
Sergey Lipnevich
> Let's take an example:
> - in bug 123, "Affects version(s)" is "v4.5.4, v5", "Fix version(s)" is
> "v4.5.6".
> - we have the following sequence of releases: v4.5.4, v4.5.5, v4.5.6 and
> v5, v5.1
>
> Based on that information, we could display the bug #123 as closed in
> v4.5.6, and opened in v4.5.4, v4.5.5, v5 and v5.1.
No objections, but a minor point maybe. I think it's not necessary to
make assumptions about any version sequencing and stick only to items
that the ticket directly relates to. That would eliminate guesswork
for Trac and prevent possible confusion for users.
For practical purposes it doesn't even have to use unique versions.
Unless the team decides to support an earlier version of the code to
fix a bug on that branch, it doesn't really matter what version it was
discovered it: it's either still present on the trunk or not. So,
having a concept of a branch (line of development, "stream," whatever)
may be quite sufficient and still not very complex. A ticket could be
associated with one or more branches and have status on each of these.
Trac may allow creation of "supported branches" without actual
branching in Subversion.
If the branch concept is useful somewhere else in Trac, such as in
milestones, or maybe in Browser when associated with actual branches
in SCM, I think it may stick.
Sergey.
tr...@nogga.de
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.
The static or ticket related information is maintained as before, and is
a continuing list of changes to the ticket throughout all versions.
The version or source related information is managed for every version,
where the ticket plays a role. In an ideal world, this relationship is
deduced from the source archive itself, e.g by assigning the ticket to a
specific revision number by setting a custom subversion property or
whatever. In an non ideal world the human has to enter this information,
e.g by telling trac how versions are related.
Therefor it is important, that trac understands how versions work. It
does not matter whether they are numbered or hierarchical. I can be any
ordering system, but trac needs to deduce from the version number, that
if a ticket is assigned to version 1.12, that it is persistent in
version 1.12.1, 1.12.2, ... and also in 1.13, 1.14. Closing the "ticket
for version" 1.14 will not close it for 1.12.2 and so on.
Consider the following scenario:
* someone will find a bug in version 1.10 and will file this bug and
assign the version 1.10 to the bug
* a developer will find, that this bug was introduced in revision 1234
and will assign the bug to this revision.
* revision 1234 was also the base for version 1.9, so the bug is also
persistent in release 1.9
* A query for the 1.9 release will show, that there is a new bug.
==> Up to this point, there is only on ticket and one ticket properties
block
* Some QA person will assign a high priority to esp. this bug in
version 1.9 and will request to have it fixed in the next maintenance
version 1.9.5
* He will add a new target milestone 1.9.5
==> Here we have a second block of ticket properties.
* The milestone will be assigned to one developer, not necessarily the
developer how will fix it for the trunk
* The developer will fix the bug only within the 1.9 maintenance line
and will close the ticket for 1.9.5
==> Here only the second properties block is closed.
Using subversion as the version archive backend this 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.
> Another idea would be to use sub-tickets, with sub-tickets for detailing
> the status of a particular issue and the particular way it should be
> solved in each branch. The cross-referencing would come for free
> (providing the SubTickets feature is implemented, of course).
>
I don't think it is necessary to create a different history for every
different version branch. But it could be a handy feature.
On the other hand this could also be used as a kind of "customer" /
developer separation. The customer will enter a ticket, the developers
will continue to work on a subticket without giving all details to the
cutomer. And finally when the subticket is closed, the customers ticket
will be updated also.
Thanks for listening
Dirk
Christian Boos
> Hi,
>
> sorry for not answering earlier, esp. there was some interesting
> feedback for this issue.
>
> ...
> Consider the following scenario:
> <snip>
> ... could be solved by
> 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
Jeroen Ruigrok/asmodai
>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...