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:
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 <email@example.com> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. firstname.lastname@example.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation