Re: Feature Freeze
On Sat, Oct 07, 2006 at 10:19:02PM -0400, David Nusinow wrote:
> If you have concrete suggestions for how to handle these things in the
> future, and even right now, please post them in a reasonable manner. I
> won't reply to the thread for a little while (probably some days) to give
> myself the chance to calm down and figure out some ways for this to work
> well for everyone. I'd appreciate any help you guys could offer to make a
> workable solution for all of us.
Ok... let me try this again without the psychotic power tripping...
I'd like to really start doing a feature freeze on most of our packages.
The whole of the archive is going in to freeze for etch in a few days
anyway, so we need to keep new upstream versions out of unstable during
that time so we can deliver bugfixes that are candidates for the etch
release. I'd like to keep experimental as open as usual for more fun stuff.
7.2 is looking more sexy with XACE and Randr 1.2, so getting it moving will
be fun.
As Drew pointed out, we're missing some updates that do need to get done.
I did a few updates last night of the input drivers, but there's a few
missing still. When it was just me doing everything for 7.0, I could keep
track in my head of what was going on. That's obviously not going to work
now. As a possible solution, I created a wiki page based on the one Drew
did as an attempt to help coordinate driver uploads [0]. It is located at
http://wiki.debian.org/XStrikeForce/ReleaseStatus.
The basic idea is documented at the top of the page. It's meant to be a
reflection of consensus of where we're at with respect to freezing packages
for release. We can also use this in between Debian releases in order to
coordinate new upstream releases, ensuring that they migrate to testing
before we start pushing new stuff in to unstable.
The way I envision it working is that we discuss first, on-list, if it's
time to start a freezing process. This should be pretty obvious to all of
us, so I don't see it being a real problem. When anyone feels like a
package is ready to be frozen, they just edit the page and include in the
comment for the change why they want to freeze the package. If it's a
problem, then we discuss it on-list and figure out a solution. We should
also discuss on-list what sort of freeze it's going to be. For example, I
feel that currently we're only fit to freeze on new features on our core
packages (libs, server, drivers, main apps) but not for anything else. This
should be documented at the head of the page. Coordinating all this should
be easy if you just subscribe to the page.
The current state of the page is simply the way I see it right now. If
there's something that needs to be done, please change or add it. I didn't
add things like apps because I'm lazy, so if you want to add them go for it
[1]. This isn't meant to be a word of law sort of thing, just a way for us
to coordinate and have a single place to look at. If you guys disagree with
going after the feature freeze, please discuss it and let me know why. If
you don't think the wiki page is a good move, let me know that it's crack
and we'll just delete it and get on with our lives. If no one has any
strong opinions, I'm going to assume we're all ok with this and go on from
there.
This isn't going to be the end of me trying to figure out a good way for
this all to work, but I'm hoping it's a positive start.
- David Nusinow
[0] I thought this was a very good idea, but I had learned from the
experience of doing 7.0 that it's way easier to just set a for loop to
build all the drivers at once and then upload them. The idea should work
better here, where we can't use simple things like for loops.
[1] xterm needs an update, and compiz should ship with 0.2 for example...
Reply to: