on Mon Sep 10 2007, Christopher Lenz <cmlenz-AT-gmx.de> wrote:
> 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. Wow, that sounds really familiar. Boost.org recently went through a 1.5 year release cycle; it was agony. We've been working hard to revamp our release tools and procedures so that we can release quarterly. So, excuse me for butting in here as I've only contributed a very little bit to Trac development, but I have a big stake in Trac's future and I have been thinking about similar issues a lot recently. I hope I won't ruffle any feathers by injecting my opinions without further apology. > 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. The need to interrupt the spiral of never releasing is much more important than releasing exactly the right thing. If I were in your shoes I would release it with that API in its current state, but "deprecated." That is, you make a loud announcement that it's going to go away very soon. It was never in an official release, so nobody can really complain too loudly. Sometimes, unfortunately, one needs to get some usage experience with an API before you can tell that it's wrong. If it hadn't been so long since an official Trac release, I think you could afford to take some time to fix it. However, you also probably wouldn't have so much experience with it, so you might not know that it's wrong yet, or at least what the right interface is. The bottom line: you have to expect that occasionally you'll release design errors and you need a procedure/mechanism for dealing with them. Deprecation is one good approach. Another point: as odious as some people may find it to make and follow rules, I think you need some policies in place that will prevent half-baked (e.g. never completed on a branch or not having consensus) checkins. Trac has probably become too big and important to be run as informally as it has up 'till now. > 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. Again, you need to write policies for this stuff, IMO. Since the project is growing quite large, I strongly suggest you consider ways to spread responsibility across the team so that you don't end up having to act personally as a gatekeeper for everything. Another point about these APIs: you can gain a lot of power by distinguishing documented interfaces from what's in the code. I know it's very common that people crawl through source (and are often expected to) to find out what they can take advantage of, but if you make it very clear that the official Trac API is the one you've documented, you can make a choice to release before cleaning up ugly/mistaken "APIs" as long as the code works and you either don't document, or deprecate, the mistakes. > 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. That's a good start on a policy. I think you ought to define precisely what you mean by broad consensus before this is over. > 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. Hooray! You can bet I'm going to try that out! > 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. I strongly suggest you consider compromises that can bring it closer. Such huge divergence of the development branch from the state of the latest released software is really harmful, especially in a world where so much functionality comes in from plugins. If, instead of planning one release out, you carefully plan the next two or three releases, an imperfect 0.11 release doesn't seem so bad. You can chart a course that brings the world up-to-date, lets you fix design errors, and still make progress on new features. > 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. Hear hear! Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
