Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Tue, Mar 15, 2005 at 10:02:37AM +1000, Anthony Towns wrote:
> >And the result of this discussion is what leaves me with great concern.
> >Specifically, the proposal:
> > 1) Provides no way for an arch to produce a stable release after the
> > initial set of archs have produced theirs;
>
> Halting unstable autobuilding, fixing remaining bugs in an arch-specific
> freeze, then making a snapshot allows you to produce a release. It may
> or may not correspond with Debian stable.
Simply making a snapshot -- or posting a set of .debs -- does not make
Debian stable. See #2, for instance.
> > 2) Provides no way for such a stable release to be integrated into the
> > security build system;
>
> That's a feature, not a bug: the security team have had ongoing
> difficulties supporting all those architectures. If there are people
> willing to do security support for particular architectures, then I'm
> sure they'll have somewhere to upload to.
The most difficult ones I've heard of are the time it takes to build
on some archs, which seems rather silly; just release the announcement
when you have whatever set of main .debs ready and the others can
build from source if they don't want to wait.
Really, I don't really understand all the difficulty of running
apt-get -b source, or pbuilder, or some such for n+1 archs as opposed
to just n. With a little use of ssh keys, the whole thing should be
completely automated. And I thought that's basically what the
security team does, anyway. If we keep them with a useable machine
(which DOES make sense as a requirement), then where is the issue?
I am not even opposed to building security updates from source if I
must. However, the SCC idea seems to negate that, since their source
may no longer be the same as the official source due to per-arch
fixes.
Not to mention that the SCC archs will *always* have later security
updates under this proposal, because they don't have access to the
same early warning that the official security team does.
> > 4) Harms the efforts of porters to get their fixes into proper Debian
> > source packages by causing brokenness on those archs to no longer
> > be RC;
>
> Which is to say "We don't get to use the release team to make other
> people do our bidding". Big deal, just because something isn't RC
> doesn't mean it's not a bug and shouldn't be fixed.
I agree.
The unfortunate reality -- documented elsewhere in this thread, even
-- is that a disturbing set of maintainers simply don't invest time to
fix arch problems otherwise, even if patches are supplied.
Unless we broaden NMU powers to permit NMUing of packages for serious
per-arch bugs when the maintainers are unresponsive, I think this is
a problem we must deal with.
Perhaps it is worth time revisiting the maintainer-as-a-fiefdom model.
> >3) For the release problem: not requiring all archs to release at once
>
> Uh, that's what we're doing.
No, you're not permitting most archs to release at all.
That is different from allowing them to release, but at different
times.
-- John
Reply to: