Re: SCC proposal (was: Re: Questions for the DPL candidates)
Op ma, 14-03-2005 te 20:54 -0500, schreef Daniel Jacobowitz: On Mon, Mar 14, 2005 at 07:51:05PM -0600, John Goerzen wrote: Perhaps, but then why not just use the existing testing setup? Because, as has been explained several times, it doesn't scale. What are the exact problems? My main gripe with the proposal, as it currently stands, is that it provides a solution for problems that haven't been discussed in detail, without much space for improvements. Rather than suggesting a drastic step without much explanation and assuming the project would agree with that, it might have been a better idea to just list up the problems that exist with the current setup, and have people suggest fixes to them. We have all etch's release cycle to do that, which should be plenty (I sincerely hope we won't suddenly jump to a 9 month release cycle) This allows the sub-testing to be coordinated separately. Managed separately. Run on a separate archive even. Useless duplication of effort, in my view. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Tuesday 15 March 2005 12:59, Wouter Verhelst wrote: My main gripe with the proposal, as it currently stands, is that it provides a solution for problems that haven't been discussed in detail, without much space for improvements. I agree. I think there is a spectrum of measures that could be taken to lessen the impact of a particular architecture on the release process. This proposal seems to be a rather nuclear option and I can't support it in it's current form. If we get a concrete list of problems then we can move incrementally towards fixing them rather than alienating a large proportion of the project - while the users of these arches may be few, we should not forget that a quite large percentage of Debian developers are with the project because it supports their pet architecture. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Tuesday 15 March 2005 02:02, John Goerzen wrote: Simply making a snapshot -- or posting a set of .debs -- does not make Debian stable. See #2, for instance. See below, please. 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. That is the point. Receiving a security update somewhen after the advisory is not stable either. Perhaps I am naive, but unless proven otherwise, I want to believe, that the security team will still run the patched packages through all of wanna-build and release whatever was able to build it. I also want to believe that it will be possible for a few dedicated porters to get into the vendor-sec circle, but this is a highly sensitive area jeoparding Debians ability as a whole to release prompt security updates. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 04:06:35PM -0800, Thomas Bushnell BSG wrote: I am of the opinion that the testing distribution has been a great help in releasing. ... Is this just a personal opinion or backed by any objective evaluation? I'm asking because as I've already expressed my impression is that if testing was completely dumped, many of the issues leading to this dropping of several architectures wouldn't exist. Thomas cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SCC proposal (was: Re: Questions for the DPL candidates)
John Goerzen wrote: -vote dropped from Cc's, subject changed. Please, can we take some care over these things? 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. 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. 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. 5) Harms the overall usefulness on Debian on the archs that are still supported by making their stable environment no longer available on other archs in the same organization. On the other hand, the current situation harms what seems to be 95% of Debian users who're working on i386 machines. 3) For the release problem: not requiring all archs to release at once Uh, that's what we're doing. que sera sera. And given the plan is to give porters fairly complete control over their architecture in unstable, rather than necessarily expecting it to be synced with i386; and to provide a snapshot facility I think losing sync in unstable is a bad thing, and not desirable. Note that I do not view any arch as being synced with i386; all archs should be synced with each other, and not everyone uses i386 as their development platform. *shrug* The next closest arch is powerpc, at under a tenth of the i386 uploads, and the next closest to that are mipsel, sparc, alpha and ia64 at about a fifth of /that/. Anyway, i386 in the above should really be read as the release candidate architectures. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
Anthony Towns aj@azure.humbug.org.au writes: 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. I am of the opinion that the testing distribution has been a great help in releasing. So can we have the same arrangement for scc ports? If it's good for the goose, it's good for the gander, seems to me. ;) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
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]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 07:51:05PM -0600, John Goerzen wrote: 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? Things evolve. It may have built against an earlier version, for instance. OK. Assuming that they are open to that. I have no reason to assume either way, I guess. I think I can safely assure you that we are :-) 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? Because, as has been explained several times, it doesn't scale. This allows the sub-testing to be coordinated separately. Managed separately. Run on a separate archive even. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
