Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
> 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...
Because this means that all the job you do for testing has to be redone on a
per-arch basis without reason, and you perfectly know how much work that is.
And this means that the porter have less time to do their real job, which
means an additional push to the ports in question into an early grave.
Friendly,
Sven Luther
Reply to: