Hey folks, when I went on my honeymoon in December of last year, I thought we might be able to do the unthinkable and get 0.11 out in spring, only about half a year after 0.10. That optimism was based on the great progress that had already been made at that point. Now it's September, and if anyone asks me when 0.11 will be released, I can only say that I have no idea. And that disturbs me big time.
So here's my highly subjective analysis on how things went off track this year. 1) Too many changes with too much impact There've been numerous changes, such as the introduction of trac.context and the flexible permissions system, that have gone in without ever having been completed on a branch, or without having gotten a solid consensus among the team. trac.context in particular has been an extremely broad change that has spread through the code base in an almost viral manner. And now we're at a point where there's actually a consensus (AFAIK) that the design should have been different, that there should be a separation between "resource descriptors" and "wiki rendering context". So what we have now is a newly introduced API that is already used all over the Trac code that noone actually thinks is properly designed. Personally, I don't feel like shipping that API and maintaining it for a few more major releases, trying to put a proper API into place while still providing some sort of backwards compatibility. IMHO We really need to fix this before releasing 0.11. And that won't be a trivial undertaking. 2) Too many API changes without much benefit At least in part based on the (controversial) introduction of trac.context, there have been some API changes, such as the introduction of a new ITimelineEventProvider API. Again, there's already a consensus that that API should look quite different, and the API isn't even released yet. When we make API changes, they need to be solid. And if there is no consensus, or even no review feedback, they really *should not go in*. Changes like this shouldn't go in just because noone actively objected. You need other developers to say that they are a good idea! These things really need more care. There's also the incomplete refactoring of trac.wiki, with the split between parser and formatter. The only thing those changes have done were to move lines of code around, AFAICT. Also, I don't recall them being discussed explicitly on this list. The discussion may have happened somewhere across several tickets, wiki pages, and IRC, but let's be honest: that's not the only kind of communication that should be happening for a project this size when changing APIs around. 3) Added bloat There are a number of features currently in trunk that I think should have never made there way in. Ticket cloning is one example, and I know that many others share the sentiment that this shouldn't be in the core. I don't care whether there's no appropriate plugin API for implementing it outside of core; instead of just adding it, come up with the extension API! We don't even have ticket deletion in core, but we're adding cloning?!? Similar deal with "ticket history": I don't recall those changes being properly presented or discussed here. They really should have been. There's also things like the "coloring" of directory listings, which I would've vetoed, if (a) we had real policies on vetoing, and (b) I hadn't been on my honeymoon at the time. I don't really understand how anyone thinks this coloring by age is needed, but if there was a need, add a friggin extension API instead! Let's call it "IDirectoryListingAnnotator" or something. As the last example, there's the auto-linking of all timestamps back to the timeline. I personally think this is quite distracting, there are links in many more places now, and it isn't really obvious what a datetime can possibly link to. I argued back then on IRC that I don't think anyone actually needs this, but Christian thought it was a good idea, so he implemented it and checked it in. I don't remember anyone else ever asking for such a feature. Please let's handle such "enhancements" with a *lot* more care, especially if they require rather dirty hacks to implement. That's just a couple of examples, I could go on here, and probably will in a future mail. The important point here is: adding functionality is a slippery slope; we've adopted a plugin archictecture because we really want Trac to be a minimalistic and lightweight system out of the box, so adding features should be done very carefully, and only with a broad consensus in the team. 4) Not enough testing The unit test suite has seen many prolonged phases of being broken. A lot of functionality has been added, but there are relatively few new tests. This really needs to change. Now I know Eli is working on functional testing on a branch, but that doesn't replace a good and expanding unit test suite. Functional testing is on top of unit tests, not a replacement. To be honest, this is one of the reasons I started working on Bitten again. I want us all to see how rapidly our test coverage is approaching zero on trunk. 5) Not enough communication The trac-dev mailing list has been extremely quiet. A lot of discussion is taking place exclusively on IRC and on tickets, and that means that anyone who doesn't have the bandwidth to follow those channels (which are both very high traffic, and often with a bad signal-to-noise ratio) is out of the loop. Let's *please* get development discussions on this list. Now, I'll definitely take some blame for being rather unresponsive on the list this year. I could say I didn't have the time, and as that's a reason that's not going to upset anyone, I'll just leave it at that ;) I hope I'll do better from now on, and I hope you'll all join me in breathing life back into this list. So that was me venting. I hope I didn't upset anyone too much, and that I made my point of view reasonably clear. What do I think can be done? Well, first I think we need to realize that 0.11 is further off than some had thought. We need to organize around fixing the biggest problems, and for the future we need to figure out ways to avoid such situations and "stay on Trac". I also think we really need to get away from these feature-packed releases, and move towards releasing often and early. And we need to stop adding features over features to the core, and instead concentrate on getting the infrastructure in place to be able to release a 1.0 version sometime this millenium. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
