|
Home > Archive > Debian Developers > March 2005 > SCC proposal (was: Re: Questions for the DPL candidates)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SCC proposal (was: Re: Questions for the DPL candidates)
|
|
| Anthony Towns 2005-03-14, 8:48 pm |
| 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.
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2005-03-14, 8:48 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Goerzen 2005-03-14, 8:48 pm |
| On Tue, Mar 15, 2005 at 10:02:37AM +1000, Anthony Towns wrote:
>
> 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.
>
> 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.
>
> 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.
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Jacobowitz 2005-03-14, 8:48 pm |
| 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.
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Jacobowitz 2005-03-14, 8:48 pm |
| 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:
>
> 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 :-)
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Goerzen 2005-03-14, 8:48 pm |
| 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:
>
> 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.
>
> 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.
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-03-15, 7:49 am |
| 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:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Will Newton 2005-03-15, 5:59 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Schmitt 2005-03-15, 5:59 pm |
| 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.
>
> 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 advisor=
y=20
is not "stable" either.=20
Perhaps I am naive, but unless proven otherwise, I want to believe, that th=
e=20
security team will still run the patched packages through all of wanna-buil=
d=20
and release whatever was able to build it. I also want to believe that it=20
will be possible for a few dedicated porters to get into the vendor-sec=20
circle, but this is a highly sensitive area jeoparding Debians ability as a=
=20
whole to release prompt security updates.
Regards, David
=2D-=20
=2D hallo... wie gehts heute?
=2D *hust* gut *rotz* *keuch*
=2D gott sei dank kommunizieren wir =FCber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
| |
| Adrian Bunk 2005-03-15, 6:00 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|