Previously Richard Braakman wrote: > Wichert Akkerman wrote: > > Previously Richard Braakman wrote: > > > * Be loud. Keep the developer community aware of what is suppposed > > > to happen when, what the release goals are, and if we're waiting why > > > we're waiting. This probably means weekly mails during the > > > development period, and announcements whenever necessary during the > > > freeze. > > > > No weekly announces during the freeze? > > I assumed that "whenever necessary" will be more frequently than once > a week :) Okay. Make it `whenever necessary, but at least once every week' :) > I had hoped that you would continue to maintain that list. It's > something that can be split off from other release management tasks > with relative ease. I'm noticing organizing things and bussiness takes more time right now, and I fear I'll end up not having enough time to properly maintain that list. I already feel it deserved more attention during the slink freeze then I put into it. > I also think release goals are good, they motivate people and they > give such warm happy feelings when they are accomplished. And they're > an incentive to clean up those last few loose ends. True, but we tend to set big goals, and if we make them release-critical we'll never release. We have to be realistic here and consider them non-release-critical release goals, ie project goals :) > Our development model requires support for hybrid systems in any case, > since "unstable" is always updated gradually and most developers run > unstable. Witness the libc5 to libc6 conversion. I have libc5 > support on my system even today. Hmm, I still seem to have it, but nothing uses it anymore. Oh, I see there's OSF Motif 1.2 in /usr/local. Oh well.. > > Within limits; this probably needs some further discussion. > > What kind of limits did you have in mind? At least give a maintainer a couple of days (2? 3 if there's a weekend in there?) to respond, unless you have a very hard timelimit. I think the same should apply to the security-team by the way. > With "create unstable", do you mean freezing? Then it wouldn't be a > pre-freeze :) The big difference between freezing and not freezing is > that uploads won't go into the upcoming release by default during the > freeze. And I don't think we can change that; we get more than 100 > uploads per day, and confirming them all manually would drive me sane. It would drive you sane? good! :) You can automate that: only demand manual confirm for packages going into section libs. > I discussed this pre-freeze idea in more detail in two other mails. > I'll wait for you to catch up to those :-) Hmm. I'll see if I can track them down. Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wakkerma@cs.leidenuniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/
Attachment:
pgpTOgzqawq2d.pgp
Description: PGP signature