Andrew McGlashan <andrew.mcglas...@affinityvision.com.au> wrote: > I would rather it be done right [release...], than be done by an > otherwise /not/ necessary arbitrary date for a freeze.
I'd like to remind you that not having a pre-set freeze date didn't go so well in the past. Getting Sarge out for example took ages, because there was no communicated date set by the release team and the contributing DDs were in the dark as what to do until which date. Then the freeze came and lasted for over 1 year which made everybody angry and in the end, Sarge release with very outdated packages, because of the uncoordinated freeze peroid. You _have_ to set a freeze date and you have to set it really really early so that every DD, DM and contributor knows what is comming when and to plan the packaging schedule for that date. You don't want to be in the middle of planning the upload of a new upstream release which results in a library transition or the need of binNMUs for dependant packages when, *plop*, suddenly the release team drops the freeze on you. Without an early set freeze date you will never get every package maintainer (of over 38.000 packages) coordinated on a single date to stop developing the next version and to just fix bugs. No early set freeze date may have worked in the days of Woody with just 8.000 packages but in the current state, this will never work. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0b4o4l27k...@mids.svenhartge.de
