Partial release idea for a given arch (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tuesday 15 March 2005 20:10, Greg Folkert wrote:
> On Tue, 2005-03-15 at 00:58 -0800, Steve Langasek wrote:
> > This isn't being used to measure the use of the architecture; it's being
> > used to measure the *download frequency* for the architecture, which is
> > precisely the criterion that should be used in deciding how to structure
> > the mirror network.
>
> Okay, I have to comment here, seeing that I personally have at two
> separate locations, two complete mirrors, that I use nearly everyday.
> They only update when a change in the archive is detected. That means
> *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will
> mean nothing. I do my own mirror(s) so as to reduce the load on the
> Debian network. I actually scaled back what I use, now only having 5
> arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and
> x86(Intel and otherwise). I dropped IA64 a while ago and will pickup
> X86_AMD64 when it become part of Sid Proper.
Therefore you are no reason keep those architectures on the primary mirror
network. Since global mirroring via the current ftp.d.o structure is to be
disentangled from release status, this shouldn't worry you.
[...]
> Me, too. How about we have a CORE of Debian mirror infrastructure or
> Base Install only for Stable, Testing, Unstable.
>
> Then either on the same machine(s) or not, a separate mirror
> infrastructure for anything beyond that. IOW, any packages that are not
> included in the Base install. Including main, contrib and non-free for
> Stable, Testing, Unstable and Experimental. Where as the Experimental is
> only on the secondaries mainly for major changes testing anyhow.
>
> This is a very feasible, well thought out and scalable option. Heck, we
> could release "Base-Install" and let the Buildd(s) for all the arches on
> the secondaries catch up.
The idea has its merits, but I don't think the architectures major should have
to be constrained in a way that the minor still have to play catch-up.
Let's see if this runs:
$arch sorts the packages by usage and importance on $arch. This can be done
via popcon or via input from the porters or via informal surveys on
debian-$arch@lists or whatever.
Find a cutoff point for "must-have", "should-have" and "nice-to-have"
packages.
Now $arch should be in a position where it could tell, whether it is feasible
to support a significant portion of "should-have" and better packages in a
"stable-core" release. If this is feasible and the responsibles feel this is
a service to our users, perhaps someone would find the interest in hacking
britney to support testing for subsets of packages and architectures. e.g.
testing propagation could then hinge on fulfilling strict criteria on all
"must-have" packages leading to a releasable state for the core.
Of course this should be tested beforehand in a separate (britney) instance,
where it can be proven (or found why not) the system doesn't stall the arches
major.
Bonus points for having a webpage pillorying those maintainers whose packages
from "should-have" and better are not in sync between the testing major and
this instance.
Of course the list can be optimises by sharing "must-have" and probably also
parts of "should-have" across more arches.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Reply to: