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 find out. > 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. 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 > times. 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! -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
