Manuzhai wrote: > On 6/3/07, Alec Thomas <[EMAIL PROTECTED]> wrote: > >> That being said, I wouldn't be opposed to more of a "release early, >> release often schedule". Reduce the number of changes we put into a >> single release. >> > > I agree (and I've said so in the past on this mailing list), but solo > turn is correct in the sense that the Trac project for some reason > seems unable to do this. >
Among the reasons, one is pretty simple: they are not that many developers working on Trac. As for any open source project, the developers come and go, and contribute based on their available time and things they wish to see happen. The Trac project could easily afford one or two more developers helping with ticket triaging and taking care of some of the long standing issues. For example, a lot of time which could have been spent on 0.11 had to be spent first on fixing long standing issues that affected both trunk and 0.10-stable. Those improvements have been made more readily available as bug fix releases. I think they also count as "releases", so we certainly still know how to make them ;-) The 0.11 release is indeed a few months behind the schedule, as we originally wanted a beta in February/March. But in the meantime, things have well progressed, and all the major items we had on the list for milestone 0.11 are now in trunk (1), simply needing a bit of polishing and stabilization. Also, one area which could greatly benefit from user contributions is the update of the documentation for 0.11 (2). Another reason for the delay is about the special nature of 0.11: we changed a lot of the internals (Genshi for templating, setuptools for packaging) and while those were really big changes, they didn't bring so much immediate added value to the users. So we also wanted to bring in some "big" new features that would reward the upgrade. Not presuming what the schedule for 0.12 / 1.0 will look like, I'd agree that we should aim for a shorter turnaround, something like 0.12 in December 2007 and 1.0 in one year from now. > By the way, I think using Mercurial instead of SVN would be great. > Mercurial seems mature enough, although possibly the TracMercurial > plugin would need some work (get some caching going, most > importantly). I think that Linus is correct when he says that > distributed development is both a more natural fit for many open > source development and fosters collaboration by allowing the easy > branching and related benefits. > Caching, yes, but also multi-repository support, support for "non-linear" revision logs, visualization of merges in changesets, etc. The list of things to enhance in this area is pretty long... Whether we should adopt this for Trac development itself or not is a discussion which belongs to Trac-dev, but I don't see this happening in the next year, at least. -- Christian (1) http://trac.edgewall.org/milestone/0.11 (2) http://trac.edgewall.org/wiki/TracDev/ToDo#Documentation --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
