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... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]