Re: Bits (Nybbles?) from the Vancouver release team meeting
On Luan, 2005-03-14 at 16:16 +0100, David Schmitt wrote:
> On Monday 14 March 2005 12:05, Robert Lemmen wrote:
> > - there must be a way for a scc arch to get a stable release. why don't
> > we either keep testing for scc archs but not do releases, so the
> > porters can do their own stable releases of their arch or have
> > per-arch testing? (the latter might lead to a source package explosion
> > i think)
>
> 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.
> If on the other hand nobody can be found to recompile packages after DSAs are
> released for this arch, I believe the arch shouldn't be released for Debian
> as stable.
This is the important part. The point of a release is that
(1) it works
(2) A promise that it _will be maintained_ ; that there will be security
fixes, and eventually an upgrade path.
For people to use a Debian port as a distribution they must have a
degree of faith that there will be people willing and capable of doing
timely security fixes for its lifetime: the size of the Debian Project
promises that. While an individual would probably be able to take a
working etch release and do the necessary fixes for e.g. s390 to
release, more is required for people to place their trust in it as a
server distribution.
Then, what happens at End of Life? We must demonstrate that we also have
a plan to transition from etch to what comes next for SCCs as well as
i386; that s390 etch upgrades to s390 etch+1.
In essence I agree with your proposition, though: I think we could
release e.g. four architectures as Tier-1, with other architectures
following later: these would involve some version skew, but kept
minimal, so that 's390 etch' is etch+only necessary fixes. The degree of
version skew would be reasonable and such that the s390 port team could
keep s390 Debian maintained with security fixes.
The challenge, however, is to do this _within Debian_, so that
maintainers will apply patches to their packages that are required for
minor ports, and keep version skew and hence complexity to a minimum.
Hence we should do what we can to keep minor ports _within_ debian, even
mostly symbolic gestures such as keeping Debian SCC ports in
ftp.debian.org/ports rather than 'offsite' in scc.debian.org, etc.
(Note: I agree that mirrors should be capable of doing partial mirrors,
rather than having to mirror the whole of ftp.debian.org, though).
Regards
Alastair McKinstry
Reply to: