"Milestones" are 'abused' as "Releases"

[ilias@…]

The usage of "milestones" on "trac.edgewall.org" 'teaches' users into a wrong direction, because milestones are associated directly with releases.

But milestones describe a _point_ on the _way_ to the _goal_ (e.g. release).

On a short term, this can be adressed by placing more milestones, like e.g.:

• 0.11sqlalchemy
• 0.11refactoring
• 0.11workflow

On a longer term, a Release Module should be introduced (after providing a working plan and collecting feedback on this).

some more information/discussion within this thread

[cmlenz]

How the Trac project uses milestones is up to the core developers, and we use the current system because it works okay for us. To me, the close association between milestones and releases makes a lot of sense. A milestone is completed when a release is made. Nice and simple. If we'd be using your suggested approach, we wouldn't really know when a milestone could be closed, because basically work on individual milestone objectives continues until a release is made.

You are free to use whatever model you want for your projects.

[cboos]

Replying to cmlenz:

... work on individual milestone objectives continues until a release is made.

especially this one: "0.11refactoring" ;)

[ilias@…]

Replying to cmlenz:

How the Trac project uses milestones is up to the core developers, and we use the current system because it works okay for us.

Of course it's up to the core-developers, and possibly it works ok for you (although I doubt this, seeing the projects progress speed and the existent intransparency).

To me, the close association between milestones and releases makes a lot of sense. A milestone is completed when a release is made. Nice and simple. If we'd be using your suggested approach, we wouldn't really know when a milestone could be closed, because basically work on individual milestone objectives continues until a release is made.

which is a basic fault of the project-organization (see e.g. the dropped branches "sqlalchemy" and "workflow")

If there's really a "permanent task" (like e.g. "Quality Assurance", or "Abstraction" , or "Refactoring" then you just don't add this as a milestone.

Must I really explain thos fundamentals (that you most possibly know)?

You are free to use whatever model you want for your projects.

this is my project (role: user/contributor)

I've reported a defect, from a users/contributors point of view and stated some _rationales_.

I insist that this is a _defect_, and that you misslead users (and visitors) of trac by using the term "milestones" instead of "release", especially in conjunction with the gigantic release-cycles of > 1 Year.

Additionally, I see this Issue as the main reason for the missing transparency, which makes synchronization of development efforts with the trac-project nearly inpossible.

So, instead of closing this defect report, you should possibly take some more user-feedback in account in order to realize this defect.

[ilias@…]

Replying to cboos:

Replying to cmlenz:

... work on individual milestone objectives continues until a release is made.

especially this one: "0.11refactoring" ;)

As said, permanent tasks don't need to get a milestone.

I've just placed a "0.11refactoring" as an example, e.g. for an intensive refactoring, applied in a single chunk by all developers.

[anonymous]

Replying to ilias@lazaridis.com:

this is my project (role: user/contributor)

L'état, c'est moi! :-)

[ilias@…]

Replying to anonymous:

Replying to ilias@lazaridis.com:

this is my project (role: user/contributor)

L'état, c'est moi! :-)

sounds like... "I am the State", see some references

[pacopablo]

Replying to ilias@lazaridis.com:

Replying to cmlenz:

How the Trac project uses milestones is up to the core developers, and we use the current system because it works okay for us.

Of course it's up to the core-developers, and possibly it works ok for you (although I doubt this, seeing the projects progress speed and the existent intransparency).

I'd argue that the apparent speed of progress has little to do with how the milestones are laid out and more to do with available developer time. Can't speak for all of the trac devs, but I know that a majority of them actually have lives outside of trac

To me, the close association between milestones and releases makes a lot of sense. A milestone is completed when a release is made. Nice and simple. If we'd be using your suggested approach, we wouldn't really know when a milestone could be closed, because basically work on individual milestone objectives continues until a release is made.

which is a basic fault of the project-organization (see e.g. the dropped branches "sqlalchemy" and "workflow")

How are these branches dropped? I know that they are still planning to implement these. Yes, they are both out of sync with trunk, but, once again, this is entirely due to the fact that the devs maintaining those branches ran into real life. Also, the whole point of branches, is so that experimental development can be done without borking the trunk. I know of know contract that says that once a branch is made, it must be followed up on and merged back in.

You are free to use whatever model you want for your projects.

this is my project (role: user/contributor) I've reported a defect, from a users/contributors point of view and stated some _rationales_.

Note the article a

I insist that this is a _defect_, and that you misslead users (and visitors) of trac by using the term "milestones" instead of "release", especially in conjunction with the gigantic release-cycles of > 1 Year.

And why is using a release as a milestone some unforgivable sin?

Additionally, I see this Issue as the main reason for the missing transparency, which makes synchronization of development efforts with the trac-project nearly inpossible.

What transparency is missing? The source is available, an idea of what is going to be merged is available, the dev mailing list is open to all, and the devs seem to be quite available via IRC.

So, instead of closing this defect report, you should possibly take some more user-feedback in account in order to realize this defect.

As another user/contributor where this is also "my project" I find that the current scheme works fine. I also don't think it's misleading in anyway, shape or form. As cmlenz said, if someone else wants to use milestones in a different manner, nothing is stoping them. If they are not smart enough to realize that one could possibly use milestones in a different manner, then they will either not use trac, or be happy with the milestone<=>release mapping

[cboos]

Please, don't let discussions of tickets turn into flame wars.

Ilias, this ticket has already been closed once as invalid, I'm going to close it once again because:

• the short term action you proposed was already discussed on the trac-dev mailing list and wasn't followed-up
• for the long term action (Release Module should be introduced), feel free to develop such a module as a plugin or a patch on Trac core, then eventually come back to discuss its merits and propose it for inclusion in Trac core. An alternative could be to propose a hack on TracHacks if you don't have the resources to do it yourself (and I wonder if there isn't already something like that: TH:TracDownPlugin).
• for more information/discussion, the thread you linked to is quite adequate

In the future, you should refrain from opening tickets on topics that were already not well received on trac-dev. The people on that list and in charge of this Trac are the same, and it's wasting our time to force us to have to explain twice why we don't want to go this or that way.

So again, if you really want to help, first do no harm.

[ilias@…]

Replying to cboos:

Please, don't let discussions of tickets turn into flame wars.

I assume that this is a general statement, not adressed to me (at least not alone).

Ilias, this ticket has already been closed once as invalid, I'm going to close it once again because: - the short term action you proposed was already discussed on the trac-dev mailing list and wasn't followed-up

This was another topic.

this here is about a defect: "Milestones" are 'abused' as "Releases"

- for the long term action (Release Module should be introduced),

this is not the main relevant point(I just stated it for completeness)

- for more information/discussion, the thread you linked to is quite adequate

see below

In the future, you should refrain from opening tickets on topics that were already not well received on trac-dev.

of course I'll follow again this standard-process:

A topic was used to start a discussion, to clarify if there's acutally a defect/weakness.

Within the thread (despite the off-topic's), it became clear that there _is_ a concrete defect, which was filed in a ticket.

The people on that list and in charge of this Trac are the same, and it's wasting our time to force us to have to explain twice why we don't want to go this or that way.

It's the project which forces me to explain twice and more times (not only with this issue).

So again, if you really want to help, first do no harm.

Sorry, that's completely nonsense.

I think it's the trac-team which is harming, by ignoring given facts, by keeping up deficient project resources, by blocking contributions and by it's missing activity/agility.

I've collected the information and provide a report shortly here, possibly you realize the project weaknesses when they are written down clearly.

I accept the state "closed/wontfix" of this ticket, thus I leave it as closed.

.