On Thu, Mar 17, 2005 at 08:22:04PM +0100, Goswin von Brederlow wrote: > Andreas Barth <aba@not.so.argh.org> writes: > > > * Mike Fedyk (mfedyk@matchmail.com) [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. A middle ground between both release approaches is not sensible as it will still make the ports dependent on a possibly suboptimal upstream tree without having the benefit of debian security updates. Ie. ports get all the disadvantages of a synchronized release without getting any of the advantages. That's just plain unfair. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature