Martin Cooper <martinc <at> apache.org> writes: > > > Any exact targetting for unresolved issues will lead to "this > > > issues hasn't made it into the latest release, we try to get it into the > > > next one" mails polluting the mailing lists without nearly any additional > > > value. > > > > I think that is a good thing as it means someone is looking at that > > issue each release and deciding that it won't go in that release. If > > it keeps getting punted all the time then someone can ask if it's ever > > going to happen. > > This is exactly why we moved to something like what Hen is proposing for > Struts. We had oodles of issues just sitting there with no indication of > when, if ever, they were likely to be fixed, and no indication of whether > anyone was committed to looking at them. Once you start versioning the > issues, you get the beginnings of a roadmap rather than just a bucket of > issues.
Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in Cocoon changing this would just not work (or end in 300 "issue version re-addressed" mails per release). For the maintenance branch the development is much less targeted as it is more or less only project-driven, i.e. an issues that a committer needs on his current project gets handled rapidly. Other issues are mostly done on demand or on request. For littler projects or projects with less chaotic project management (which I like much though :)) the above might indeed be useful. Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
