Re: Do not make gratuitous source uploads just to provoke the buildds!
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
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?
> Cheers,
> Andi
> --
> http://home.arcor.de/andreas-barth/
> PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
MfG
Goswin
Reply to: