Re: Do not make gratuitous source uploads just to provoke the buildds!
On Thursday 17 March 2005 23:44, Peter 'p2' De Schrijver wrote:
> On Thu, Mar 17, 2005 at 08:22:04PM +0100, Goswin von Brederlow wrote:
> > Andreas Barth <email@example.com> writes:
> > > * Mike Fedyk (firstname.lastname@example.org) [050316 20:55]:
> > >> Andreas Barth wrote:
> > >> >If that happens for a too long period, we might consider such an
> > >> >architecture to be too slow to keep up, and will eventually discuss
> > >> >about kicking it out of the architectures we wait for testing
> > >> > migration at all, or even kicking it out of testing at all. Not
> > >> > waiting for such an arch has happened and might happen again.
> > >>
> > >> I think it makes sense to shorten the list of arches we wait upon for
> > >> testing migration, but I fail to see the usefulness of removing an
> > >> arch from testing.
> > >
> > > If we don't wait for an arch, it gets out-of-sync quite soon, and due
> > > to e.g. legal requirements, we can't release that arch. (In other
> > > words, if an arch is too long ignored for testing, we should remove it,
> > > as we can't release it in any case.)
> > Not if each arch has it's own source tracking. And you already need
> > that for snapshot fixes.
> > Non release archs should be released by the porters alone (no burden
> > to RMs) with a minimum of arch specific versions or patches. There
> > should be a strong encouragement to remove software instead of
> > patching it when it comes close to the actual release so when the port
> > does release (after the main release) it is based on stable source for
> Why would a port release after the main release ? Why, if debian doesn't
> care about the non-release archs, would the porters even bother to
> follow the release arch sources and not just release whenever they
> like ? They don't gain anything by following the main release.
> > everything but last minute flaws in essential packages. Maintaining
> > those patches in case of security updates or for the point releases
> > again should lie with the porters.
> > The reason why I favour this is that I have in mind that some archs
> > will be too slow, they won't be able to keep up every day. But given
> > an extra month they can compile the backlog or kick out out-of-sync
> > software and release seperately with a nearly identical source
> > tree. The remaining source changes can (and basically must for
> > legal reasons) be contained on the binary CD/DVD set and in a branch
> > of the scc.d.o tree.
> > Take for example m68k. It will always be at risk of lagging a few days
> > behind because some packages do build a few days. It is always
> > out-of-sync longer than the other archs but it is not getting worse,
> > it is just a step behind. That is totaly different than arm or s390
> > taking a deep dive getting some 300+ package backlog and having
> > packages stuck for a month.
> > If an arch has enough developers on it to keep stuff building, and
> > that means supplying patches to unstable fast and early enough to get
> > them into testing and ultimately stable I see no reason why the arch
> > shouldn't release. Make some rule to limit out-of-sync, say no more
> > than 1% sources differences to stable for the release.
> > Any problems with that?
> Yes. It doesn't make sense. Either debian releases with all archs, or
> every arch releases on its own. The latter is favoured by the current
> proposal and will diminish debian's value. The former is the way to go.
> Scalability problems need to be solved by improving infrastructure or
> procedures as appropriate.
Porters who have worked on getting an arch to REGUALR status are in a much
better position (demonstrated commitment, technical aptness and
experiencewise) to solve those problems than random-joe-developer.
Always remember that the main reason that it is easier for a porters team to
release within the (current) Debian framework than outside is that _others_
do work for them.
- 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