Christian, first off, thanks a lot for this great response!
Am 10.09.2007 um 16:26 schrieb Christian Boos: > Christopher Lenz wrote: >> 1) Too many changes with too much impact [snip] > 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). That sounds good. We should get together and discuss what the right way forward should be in this regard, on a separate thread. I must admit I'm still a bit lost here, due the pervasiveness of the Context stuff in the code, so I think your support with refactoring this will be really appreciated. >> 2) Too many API changes without much benefit [snip] > 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. Yeah, that's what my impression was. IMHO, things such as the wiki formatting/parsing split should have gone on a branch, and be proposed/discussed here. I don't think that releasing a version sporting "half refactored" APIs is a good idea, as usually you only find out whether an API actually works when you put it to serious use. When you try to anticipate how an API *should* look in a future version, chances are that the actual API will need to look different. > 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. I fully understand that the lack of involvement of team members like myself plays an important role in how we got here. In my defense I can only say that I was frustrated at the time about some of the changes being made. Sometimes frustration paralyzes, and that of course doesn't help at all. This is basically me breaking out of that paralysis and trying to start being constructive again :P That said, I think there were still too many changes done too quickly without seriously trying to trigger discussion on this list. And complaining about a change after it's been made is harder than when it's still a proposal. So for the future, that's something that we should try to avoid. But let's not talk about spilled milk... >> 3) Added bloat [snip] > 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. I think in these cases we (a) need to keep the Trac motto of being minimalistic in mind, and (b) only add features for which there's a consensus in the team (+0), or even active support by other members (+1). If there's a feature that someone else on the team thinks should not be added, there needs to be discussion, and if in the end there is no agreement, it should not be added. I don't see how we as a project can work otherwise. On a related note, we've now evidently reached a size and state where we need to write down some basic rules on this decision making process. > 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. I'm glad that you raise this concern. As you know, I've always been skeptical about the TracObject ideas, which basically go back to the xref branch; the main problem I see is premature/over-ambitious generalization, and a design that is not user-oriented. But we shouldn't discuss that here, it's obvious that we're in disagreement. And the problem is that it's disagreement over vision and long-term goals. I personally would encourage you to explore this vision in a separate branch or fork. This will give you the advantage of being able to make faster progress with fewer tiresome discussions over what amounts to a conflicting vision. If you choose to follow that path, I think you would really want to run the project on a separate system and repository (using svnsync or somesuch), enabling you to "eat your own dogfood" and all that. I also think that having a branch following a decidely different direction than Trac proper would be confusing to our users But that's not to say that there shouldn't be synergy; for example, it's rather unfortunate how DrProject has lost any connection to the Trac project since it was forked. I think keeping up healthy communication benefits both sides of a fork (for example by trying to keep at least parts of the APIs and technologies in sync). > 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. Sounds great. >> 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. I would like the emphasize that I think the amount of work and time you've put into Trac has always been a tremendous boon to the project. I don't think anyone doubts that. The other side of the medal, though, is that with one person able to contribute a seemingly infinite amount of time and resources to an open-source project, getting involved may at least seem harder for others (committers and potential contributors alike). The same could be said of myself when we were around the 0.9 mark. It's probably no coincendence that we're having this discussion at a point when you've seriously scaled back your activity on Trac ;-) 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 -~----------~----~----~----~------~----~------~--~---
