Christopher Lenz wrote: > ... > > So here's my highly subjective analysis on how things went off track > this year. >
First, thank you for bringing the discussion on a good fact-based level... makes it easier for me to mostly agree with your analysis. Let's go through some details though, and see where we can go from there. > 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 WikiContext related changes seemed to me a good idea at first, as I was able to address a few long-standing issues with this approach (http://trac.edgewall.org/wiki/WikiContext#FixedIssues). But after some time, I realized by myself a few of the drawbacks already pointed out in the initial review by Christopher, and I think that a resource descriptor / rendering context split can achieve the same results in a cleaner way. So right, these concerns will be top-prio for me, and I'll try to address them in a new branch, along the lines already outlined in that other mail (1). As for too many changes, well, yes, the scope of 0.11 could certainly have been narrowed down. > 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. > Some of these changes are perhaps wrong or not as good as they could have been, others are "work in progress" (or merely just started, like the wiki split). Sure. The point is that at the time when I was working on those changes, nobody really seemed to be interested enough to give feedback, so trunk was for a while a working area which I used to build "a better Trac" in an incremental way. It's now easy to say "if there were no feedback, then you shouldn't have integrated the changes", but this would have applied to /most/ of the changes. Often the distinction between a newly introduced feature and a bug fix is difficult to make (e.g. the whole WikiContext thing was introduced in the first place to address existing issues), so never introducing any change which didn't get any feedback would have led to a status quo, which I didn't want. Instead, I preferred to make the changes, at the risk of taking criticism afterwards. > 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. > Mea culpa, I certainly went down that slippery slope of adding features in a too liberal way, or rather, in a way that *I* thought would benefit the user. That leads to the question of who ultimately has the last say on each and every big and little design issue in Trac. If someone (you) thinks that e.g. the timeline links are distracting and useless and someone else (me) thinks that they have a real value (like the ability to put a change in context, in this case), whose opinion should prevail? Not to mention other issues where the disagreement comes down to a choice of colors (ok, I slightly exaggerate here, but not by much). Adding a configuration switch is not an answer, neither can "just create another plugin" be one, as we are in the end talking about things that are done in the core. So we have different taste and judgment... So what? Do we really have to come down to some middle ground that would presumably satisfy none of us? Is there any other solution? Probably. I wouldn't mind creating my own "feature rich" branch (even outside of t.e.o, though I'd prefer have it stored there for ease of merging and comparing) if that could help to make the development process go smoother. What I won't do is to "give up" on my ideas and what I think are worthy goals for Trac, stated quite a long time ago in TracObjectModelProposal, and in (2). Those longer term goals are probably not all shared by other core developers, but it's not what makes them less valuable in my eyes; I see enough echo of my ideas in suggestions from various people in tickets or mails so that I know I'm not completely loony ;-) If there's a consensus saying that t.e.o is not the right place to develop such a vision, so let it be and I'll find another way to eventually make it happen. On the other hand, what I also won't do is to leave trunk in a messy state, and what the consensus says should go away will go away. So keep assured that I'll actively work toward releasing 0.11 the way the *team* wants it to be. I'll also be more conservative about what goes into trunk in the future /and/ play the plugin game a bit more. > 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. > I agree that the signal-to-noise ratio argument is a good reason to discuss things on trac-dev. > 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. > ... and it's a reasonable point of view to have. Now I think this analysis misses one big part of the picture: what's also gone wrong on the road to Trac 0.11 was that there could really have been a bit more contributions given to the project by its team members. I certainly don't claim having done all the work and assuredly some of it would have been better spent in a more focused / inspired way, but all in all, if at least someone else had put an equivalent amount of work in ticket triaging, troubleshooting, bug fixing (including for the 0.10 line), giving feedback, testing, then Trac 0.11 would already have been released since quite some time. > 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. > \ > Yep, agreed. -- Christian (1) http://groups.google.com/group/trac-dev/browse_frm/thread/f6fb241963be9178/95b255ce192ba5c5#95b255ce192ba5c5 (2) http://trac.edgewall.org/wiki/ChristianBoos#NextSteps --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
