Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 07:02:05PM -0600, John Goerzen wrote:
> 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?
How often this works, however, is the problem. The source may not
build cleanly everywhere. Some dependency may be broken, or not
install properly in the build daemon, or so forth.
For security updates, using a separate pbuilder infrastructure instead
of the buildd infrastructure is an interesting idea. I am not sure
whether it would be workable. If someone wanted to try it, and
coordinate with the buildd admins and security team about it, we could
> 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
> 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.
This isn't a useful objection. The security team could add additional
members focusing on SCC; if there are a small number of responsible,
interested developers, then there is no reason not to. The current
members aren't magical.
> > >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
As I read it, they are allowed to release - but they have to do their
own release management.
I think what this is crying out for is a second testing setup, covering
the remaining architectures. Get a corporate sponsor for one of the
non-release architectures to provide adequately beefy hardware. Have a
team of interested people do release management on that second set of
testing, possibly "slaving" it to the main "testing" - I haven't
considered the technical details of that in depth, but I'd bet it could
be done. Then, *poof*, a Debian/etch/Ports release is made!