Re: Stable branch will freeze.

[Rob Browning]

Neil Jerram <address@hidden> writes:

> I think that's rather harsh, thi.  A small amount of focus and
> control to get a release out is hardly dictatorship.

Agreed, and without having some kind of say about what does and
doesn't go into the stable branch I certainly won't be able to
effectively manage a release.

In particular, from now on, I feel like publically visible, i.e. not
bugfix related changes to the stable branch should be discussed (even
if just briefly) on the list *before* they're made.  Documentation
improvements don't count, but adding/removing/modifying the public
API, changing command argument signatures, etc. does.

For example, if you're fixing an off-by-one error in some internal
array access code, fine, but if you're removing macros from a public
header file or changing the GC algorithm, we should discuss it.
Actions already accepted into the TODO for the release would obviously
be excepted.  (In the future I'd like to see the TODO become even more
heavily used to keep track of release items.)

Overall I don't really think this will be a lot of effort, and I
suspect it'll help a lot with respect to making sure we all have a
good sense of what's going on.

> The real problem here is that we don't have a shared view of what is
> release critical.  We used to, but I think that sense was blown off
> course by the volume of bugs that have been reported recently.

FWIW my goal when we started this release was to take what we had, fix
anything that was seriously broken (where seriously for this release
meant "much worse overall than 1.4"), fix the remaining items on the
1.6 TODO list, make sure we removed any things that we didn't want to
be stuck with going forward that were *easy* to remove, and then
release 1.6.

It would have been nice if we could have released 1.6 about six months
ago, and we were now having these arguments about 1.8, perhaps basing
a lot of our decisions at least partially based on (hopefully
increasing) user feedback (good and bad), and hopefully having made a
lot of progress migrating toward the much cleaner API we're planning.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD