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? Incendentally I feel the release manager should manage the release-critical buglist as well, but you already know how that works :). Also, I thought we had decided to no longer have release goals, but project goals. Do you mean to reinstate release goals, since you mention them here? > * Authorize NMUs to fix specific bugs when necessary. (I think the > release manager should have this power.) Within limits; this probably needs some further discussion. > * Have a pre-freeze of one or two weeks, during which new packages > can be held until after the freeze so that they can be installed in > the next "unstable". Conveniently, "new packages" tends to include > incompatible library versions and major reorganizations as well. Maybe a 2-week library and base-system freeze and immediately create unstable? > * Be present and active during important events like the freeze or > the release. When the release time is measured in hours, I expect the > release manager to take whatever drugs are necessary to stay awake :-) Amen :). 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:
pgpcyZxqJeudM.pgp
Description: PGP signature