"Chad" <innocentkil...@gmail.com> wrote in message news:BANLkTikd4Eb-V8W-kA1qe+=bnjxmj+o...@mail.gmail.com... > > I understand, respect, and value the contributions of people who want to > add new features. Features are what moves the product forward, and at > no point do we want to be hostile to people willing to put in their time > and > effort to add functionality. > > Given that our patch review process isn't fantastic, I really don't think > it > would affect the majority of bugs anyway. Mainly affected would be > people with core access who write a new feature without putting it > through BZ first. Given that our core group is relatively small, I figured > we could come to some sort of consensus, if we do indeed move forward > with this. > > ... > > I don't know what our development community wants. I just happened to > think it was a good idea and so brought it up for discussion. If we > collectively decide I'm nuts, we can toss this proposal, I won't be upset. > I know we'd need to keep development on a very strict timeframe, which > is why I outlined a more strict branching and timeline to stick to. As > Roan > and others pointed out, 6 months is a little long. I don't think we > couldn't > decide on a branch point and stick to it, especially if we're not holding > up > a branch for someone to finish sorting out a rewrite or major feature they > didn't quite resolve. > >> Given our past record, I'm not really confident that we can pull that >> off. There's a risk of screwing it up badly and offending a lot of >> people. Release management isn't exactly an organisational strength. >> > > I agree it's not our strength, but I don't think we can't do it. I > think sticking > to a firm branch date would largely alleviate this issue. I remain > convinced > that a stability-focused release would be a good idea at some point, > whether > we do it now or in a year.
Feature freezes don't have much potential in the current development climate because the choice is basically between committing a feature to trunk and not committing a feature at all. Development work done in branches might as well be left in a working copy for all the attention it gets, BZ patches doubly so. What would almost certainly happen in a feature freeze would be that developers who are interested in core rewrites / major features would simply queue up their work for the next release, which would make 1.20 another massively-rewritten monster. That, if not properly managed, is just creating a bigger problem down the line; although conversely you could say it would make for a particularly Awesome(TM) milestone release. If a feature freeze is to work, it has to either a) be for a very short period so that developers neither get disenchanted and wander off nor start stockpiling working-copy changes to empty onto trunk once it's thawed, or b) be part of a fundamental change in the way we approach rewrites. It would be perfectly acceptable to move to a completely different paradigm where branches are used properly, regularly reviewed, get plenty of inter-developer testing and can be smoothly merged back into trunk in an organised fashion. But right now, the only way to reliably get external eyes on code is to put it in trunk; the occasions when multiple developers are working on the same branch are both rare and not quite the same thing. My login rewrite was done as a branch merge and was reverted three times from 1.16 (not unreasonably, for sure, but for bugs flagged up by precisely the sort of diverse testing that being in trunk provides and being in a branch doesn't); it's now 30,000 revisions bitrotted and will probably have to be redone from scratch. The 1.18 blocking rewrite was done in pieces in trunk and looks to have settled in reasonably well. A feature freeze will probably result in rather more of those Big Scary Commits (TM) -- either branch merges or whole features put together in a working copy -- and fewer features implemented through incremental changes. If we don't have provisions in place to handle that in some way, it will probably create more problems than it solves. --HM _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
