Re: FREEZE RESCHEDULED
On Mon, 8 Nov 1999, Ben Collins wrote:
> On Mon, Nov 08, 1999 at 11:05:55AM +0000, Mike Goldman wrote:
> > Kevin Dalley wrote:
> >
> > > When frozen is created, we always have frozen and unstable in
> > > parallel. In fact, we must always have them in parallel, if we allow
> > > new uploads. Having two branches allows people to either fix bugs or
> > > release new unstable releases, according to their preferences. A
> > > person with no bugs shouldn't be prohibited from uploading new
> > > releases.
> >
> > I do not believe that this was the case with hamm and slink. I believe it
> > *should* be the case, but IIRC there were no unstable uploads allowed
> > during the freeze, only release critical bug fixes to packages in frozen
> > were permitted until the release.
>
> Actually there is always an unstable after the freeze branch is put in
> place. The only restriction on uploads is the ones to frozen. And I am of
> the opionion that this is the problem. Too many people ignore frozen once
> it's created, since they can only do the "neat" uploads to unstable. Thus
> they don't want to handle two set's of packages and keep the differences
> merged, so they continue to upload only to unstable.
>
> But, I have had my rants about this in the past, and it seems people are
> more concerned with having new and exciting packages, than making
> frozen a complete and bug free release (just think what would happen if at
> freeze, every maintainer fixed all the bugs in their own packages, barring
> wishlist items, wouldn't that be neat). The ones who didn't have bugs
> could a) help with documentation or boot disks if they desired, or b)
> start working locally with new packages and new versions, taking the time
> to test new things, or c) do nothing and relish the bug freeness of their
> packages, and enjoy the time off they deserve.
Well, we've had this discussion before. I daresay we'll have a variation
on it every release. I'll try to put up the other side of the argument:
1) We can't and shouldn't hope to force maintainers to do what we want.
2) People who want to help with documentation and boot disks will do so on
a polite request from the release manager. They're no more likely to do
so just because they've been forbidden to upload new packages.
3) There is no advantage to working locally over uploading to unstable.
If you work locally, no one else tries your packages, so it's harder, not
easier, to debug them. And why should all debian unstable users be denied
my new packages? I'll probably end up creating a private distribution in
www.debian.org/~me, and waste more bandwidth (by bypassing our mirror
network).
4) Developers take time off whenever they want to, and work when they want
to. It's counter-productive to say 'you can't help us now, go away'.
Please, let's keep this discussion neat and productive. Think very
carefully about what I've said, and what Ben's said, and only contribute
if you think you're genuinely going to help debian solve this problem :)
If you just want to flame either of us, do so in private email :)
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: