On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote:
> > On Mon, Mar 14, 2005 at 07:59:43PM +0000, Alastair McKinstry wrote:
> > > > AFAI can tell, anybody can host an archive of packages built from stable
> > > > sources for a scc or unofficial port. And - if I read the conditions on
> > > > becoming a fully supported Debian arch right - then having security support
> > > > for an external pool of this arch is a good indicator that it should be a
> > > > fully supported stable release (amongst other things).
> > > The plan as proposed is that the Debian scc ports are purely builds of
> > > unstable. Hence this build out of the last release (e.g. etch) becomes a
> > > subproject of a second-class project of Debian. It effectively has
> > > little credibility.
> > Well, the release team are not the only Debian developers with credibility,
> > surely? Not everything needs to go through us; if the project has the will
> > to do stable releases of these architectures, in spite of the release team
> > being unwilling to delay other architectures while waiting for them, then
> > it should be very possible to provide full stable releases for these
> > architectures.
> >...
> Which delays are expected for etch, that are not only imposed by the
> usage of testing for release purposes? [1]
> I do still doubt that testing actually is an improvement compared to the
> former method of freezing unstable, and even more do I doubt it's worth
> sacrificing 8 architectures.
If the proposal already gives porters the option to freeze ("snapshot")
unstable to do their own releases, in what sense is this "sacrificing"
architectures? It sounds to me like it's exactly what you've always wanted,
to eliminate testing from the release process...
> [1] The installer might be a point, but since all sarge architectures
> will have a working installer and I hope there's not another
> installer rewrite planned for etch this shouldn't be a big issue.
Getting the installer into a releasable state across all 11 architectures
simultaneously *is* an ongoing issue, whether it involves a rewrite or not.
So is getting a releasable toolchain, and a releasable kernel; so is getting
buildds on all architectures to attempt to build packages soon enough after
upload to give maintainers timely feedback about brokenness in their
packages. None of this seems to be imposed by the usage of testing.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature