[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DPLs : what do you think about ...



On Sun, Dec 13, 1998 at 04:38:36PM -0500, Elie Rosenblum wrote:
> And thus spake Ben Collins, on Sun, Dec 13, 1998 at 07:17:58PM -0500:
> > People should be concentrating on getting the frozen dist complete, not
> > making changes to packages for unstable. If we do it this way, it is
> > concievable that it wont be as long till deep freeze as it takes now. When
> > deep freeze comes along, then we fork an unstable. If you don't have
> > anything to do with your packages for frozen, take a break or pitch in
> > with the "Bug Group" or help other maintainers get their packages bug
> > free.
> 
> I would personally prefer the current system of longer freeze periods
> that do not hinder the more productive maintainers - and I don't think
> there's any evidence to suggest that holding off on creating unstable
> will speed up release management in any way besides having these people
> produce less and thus have less potential for bugs at the next release.

I would also like to point out that some ports that are trying to make
it into slink are having some (minor) problems with forking unstable as
soon as there is a freeze.

For example the sparc port is aiming at a slink freeze, but they are
currently linked in with unstable (potato). Because of this they are
compiling with slink versions of packages. Well guess what, the kbd
package (kbd = binary-arch, kbd-date = arch-indep) in slink is behind the
one in potato already. So we have the kbd package at 0.96a-10 while the
kbd-data package is at 0.96a-11 and it depends on that _exact_ version,
including the debian package version.

This could all be avoided:

slink/binary-i386
slink/binary-sparc

unstable/binary-sparc@ -> ../slink/binary-sparc
frozen/binary-i386@ -> ../slink/binary-i386

So now we, until deep freeze, i386 wont be forked, yet sparc has a chance
to catch up. 

Only one binary tree to work with still (slink). And the binary-all tree
will still be shared.

-- 
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation


Reply to: