"Chad" <innocentkiller(a)gmail.com> wrote in message
news:BANLkTikd4Eb-V8W-kA1qe+=bnJxMJ+OxUA@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