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

Discussion about tier-2 testing and how to achieve a release of tier-2 arches after all. (Re: Bits (Nybbles?) from the Vancouver release team meeting)

On Mon, Mar 14, 2005 at 11:23:48PM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 10:32:57AM +0100, Sven Luther wrote:
> > On Mon, Mar 14, 2005 at 12:23:12AM -0800, Steve Langasek wrote:
> > > On Sun, Mar 13, 2005 at 11:21:29PM -0800, Thomas Bushnell BSG wrote:
> > > > Steve Langasek <vorlon@debian.org> writes:
> > > > > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> > > > > > Steve Langasek <vorlon@debian.org> writes:
> > > > > > > The sh and hurd-i386 ports don't currently meet the SCC requirements, as
> > > > > > > neither has a running autobuilder or is keeping up with new packages.
> > > > > > It is impossible for any port under development to meet the SCC
> > > > > > requirements.  We need a place for such ports.  Where will it be?
> > > > > On the contrary, the amd64 port does, and is currently maintained
> > > > > completely outside official debian.org infrastructure.
> > > > The amd64 port did not always.  Ports under development take time; the
> > > > amb64 port is at a late state in its development.  I don't understand
> > > > why autobuilding is important to SCC; maybe if you could explain that
> > > > I would understand.
> > > The point is that the ftpmasters don't want to play host to various
> > > ports that *aren't* yet matured to the point of usability, where "being
> > > able to run a buildd" is regarded as a key element of usability in the
> > > port bootstrapping process.  The amd64 team have certainly shown that
> > > it's possible to get to that point without being distributed from the
> > > main debian.org mirror network.
> > I don't really understand that point though, since the plan is to drop mirror
> > support for all minor arches, what does it cost to have a 3 level archive
> > support : 
> >   1) tier 1 arches, fully mirrored and released.
> >   2) tier 2 arches, mostly those that we are dropping, maybe mirrored from
> >   scc.debian.org in a secondary mirror network. (why not ftp.debian.org/scc
> >   though ?).
> >   3) tier 3 arches, or in development arches, available on
> >   ftp.debian.org/in-devel or something.
> > I don't see how having the in-devel arches be hosted on alioth instead on the
> > official debian ftp server would cause a problem.
> > Also, i don't understand why scc.debian.org is better than ftp.debian.org/scc,
> > really, ideally we could have /debian, /debian-scc, and /debian-devel or
> > something such. Is it really a physical problem fro ftp-master to held all
> > these roles ? What is it exactly that ftp-masters want to drop all these
> > arches for ? 
> Nothing in the SCC plan implies a separate dak instance for
> scc.debian.org vs. ftp.debian.org.  On the contrary, since there are
> release architectures that would not be distributed via ftp.debian.org
> under this plan, it is a requirement that all of the architectures in
> question continue to use ftp-master.debian.org for uploads and the dak
> instance.

Ok. This clarification was missing from your original announcement though, and
there are still questions on how tier-2 arches will be able to setup their own
testing support. Taking snapshots from unstable is not a viable solution.

I understand that the testing scripts doesn't scale well, they run once for
each arch, don't they, but moving testing to per-arch archives as i proposed
in my 'build tier-2 arches from testing' proposal, asks the question of how
the communication between the per-arch testing setup and the tier-1 setup
communicate, and also where an arch porter uploads his arch-specific fixes to.

He can either upload to the tier-1 unstable, with the risk of seing the upload
hold by tier-1 testing-hold-up issues and not trickling down to the per-arch
testing setup, or upload to the per-arch unstable archive, with the risk of
the change getting lost when a new tier-1 upgrade comes.

Ideally the fix should be uploaded to both tier-1 unstable and
per-arch-unstable, and a mechanism setup for holding imports from tier-1
testing until the arch-fix is included in it.

Obviously this needs :

  1) cooperation from the tier-1 maintainers to apply the tier-2 arch fix, and
  suitable workarounds for if the maintainer doesn't do its job (NMU allowed
  after a given set of time or if a new upload was done without fixing the
  arch-specfic problem without a good reason).

  2) a way to workaround packages that are kept out of testing for non-tier-2
  related reasons.

  3) discipline on the porters part to do and follow two uploads, and maybe a
  third if 2) happens, thus imposing a higher workload on them than
  necessarily needed.

I don't know, maybe building from testing is not so good an idea after all,
and some building from tier-1 unstable, with a testing script whose additional
criteria would be for the package to be in tier-1 testing.

Altough building from tier-1 testing is the most natural idea if there is hope
of tier-2 stable point release to happening.

> There is no problem for ftp-master to continue filling this role; but it
> already doesn't act as ftp.debian.org -- that role is filled by other
> machines.  It seems likely that the scc.debian.org service will be on
> yet another machine, indeed for ease of mirroring.
> The minimum standards for SCC architectures exist so that the ftpmasters
> don't have to do a lot of setup work for a port that isn't going
> anywhere.  Ports that are "going somewhere" should be able to meet the
> stated requirements fairly quickly, AFAICT.

but cutting stable releases, testing and security updates just because we
don't really need such a wide mirror network is way overkill.


Sven Luther

Reply to: