On Mon, Mar 14, 2005 at 08:14:47PM -0500, Daniel Jacobowitz wrote: > 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.
Is not this supposed to be fixed before a package ever enters testing, let alone stable? > 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 think it would be easier in some ways, since it is easier to make this scriptable -- that is, do x with the .debs when they're building, or y if they fail. > > 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. OK. Assuming that they are open to that. I have no reason to assume either way, I guess. > > 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. Well, the proposal as given is for snapshots of unstable, making no provision for stable (or frozen)... > I think what this is crying out for is a second testing setup, covering Perhaps, but then why not just use the existing testing setup? By this time, we are basically down to the same setup as we have now, with simply different release times and security procedures per archive. Wouldn't it be easier to make those policy changes, along with not requiring mirrors to carry all archs, than to do this whole SCC thing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
