Re: Architecture removal and social contract
On Tue, Apr 05, 2011 at 02:12:09PM +0200, Stefano Zacchiroli wrote:
> On Tue, Apr 05, 2011 at 12:27:22PM +0200, Thibaut VARENE wrote:
> > Only one of the points I was making. Allow me to restate them here:
> >
> > 1) what's the cost of letting the unstable buildds run on a "don't
> > care" basis? (question which I asked before and which remained
> > unanswered)
>
> I don't thinks this one is for me to answer (and anyhow I don't know the
> answer).
>
> > 2) what's to become of the hppa hardware currently in "Debian's
> > hands"? (autobuilders, porter boxes): if the port is gone, maybe they
> > can be put to better use elsewhere?
>
> I don't consider the HPPA port "gone". It has simply failed, for quite a
> while now, to reach the quality level needed to be part of Debian and,
> as a consequence, it will no longer be hosted on ftp-master
> infrastructure. It will be hosted on debian-ports and can keep improving
> there, once it will be consider in a almost releasable state it will
> probably be re-approved by the release team and hosted back on
> ftp-master infrastructure.
>
> Regarding hardware, if you (or someone else) claim ownership on it, then
> I would need to reconstruct the donation history of it. Nonetheless
> please keep in mind that the fact that if it were donated to Debian for
> hppa, it doesn't mean that it would have been donated to others for
> hppa, as Debian name usually plays an important role in donations. I'm
> sure you see how unpleasant the discussion could become ... Hence, I'd
> surely welcome solutions in which the hardware remain in "Debian's
> hands" but is accessed by hppa porters, if feasible.
>
> To comment more on this, I would need more precise details about which
> hardware you're talking about, where it is, when/how it was donated to
> Debian, etc.
The three machines currently serving as buildds & porter boxes are
maintained and hosted by HP. I expect these buildds will continue
operating for debian to provide updates to lenny, and also serve as
buildds for debian-ports should hppa move there.
We never did any paperwork to donate these systems to Debian - and I'm
not sure I see the point in doing so while HP continues to host
them. Such a policy would only add beaurocracy when we need to swap
out a dying box, etc.
-dann
> > 3) is it acceptable that such a decision, which has a clear impact on
> > our users (and thus "breaches" social contract #4) be made by
> > delegation, and not by voting?
> <snip>
> > Sure, you have a point. Yet it seems rather strange that in view of
> > SC#4, a "transition" from a Debian-sponsored infrastructure to an
> > independent-maintained one be considered "fine" ...
>
> I think you're over inflating the SC#4 argument here. I'm sure we can
> agree that SC#4 is vague enough to be subject to interpretation. I've
> already tried to argue that any package removal harm the users as well,
> but we do not vote on each package removal for instance.
>
> > Where I'm getting at is the fact that it seems only a few people make
> > these rules and that doesn't look very "democratic" to me, especially
> > if (as seems to be the case) there is no prior framework for such
> > decisions...
>
> More generally, Debian is not a democracy *by default*: we do not vote
> on all decisions. Rather we have teams and individuals with specific
> responsibilities that by default can take and apply decisions. When you
> mix that with the principle of least privileges, you unfortunately get
> into situations where some teams might be seen as evil overlords.
>
> Luckily, the Constitution offer several defenses to that though (CTTE
> and GRs). Personally, I don't think that ftp-masters are breaching SC#4
> here, I think they are just trying to put at the best possible use their
> resources (hardware and manpower). Given that SC#4 is subject to
> interpretation, I understand that others might have different opinions.
>
> If you feel strongly about it, I encourage you to consider appealing to
> the CTTE or preparing a GR. Honestly though, I believe that for the
> well-being of the hppa port it would be much better to put into other
> use the energies that doing so will consume. For instance, I'm sure that
> the day hppa will be near to a releasable state again, the release team
> will look into it and ftp-master will get it back timely on their
> infrastructure. Hopefully, reaching that point will be easy enough once
> hppa lands in debian-ports.
>
> > There were numerous discussions regarding not releasing Debian 6.0 for
> > hppa, and also some talks about removing hppa from testing (I think it
> > was to avoid blocking packages migration on other archs), but it was
> > (again, AFAICT) _never stated_ that this would imply a definitive
> > removal of hppa from the archive. Many users are fine with just
> > running unstable (hence question #1 above).
> <snip>
> > Where are those "rules" written? I'm aware of discussions leading to a
> > set of decisions (such as not releasing 6.0 for hppa). I'm not aware
> > of any Debian document on www.debian.org/doc/ or www.debian.org/devel/
> > (Policy, or others) that say something about when an architecture must
> > be removed.
>
> Fair enough, I agree that a times the documentation of some of ours
> internal processes is not as good as it can be. I'm sorry for not having
> the time to look into this right now myself, but it would be nice to
> take this occasion to improve it. I remember to have read before of
> ftp-master intentions to remove architectures which haven't been in a
> releasable state for a while (maybe it was on -project as part of their
> recent announcements about ftp-master sprint?). It would be very useful
> to look for them and/or talk with ftp-master, so that those procedures
> get documented properly, e.g. on the ftp-master team page.
>
> > > ... and unfortunately the DPL is *not* one such venue. According to
> > > Constitution indeed, the DPL cannot override a delegated decision. The
> > Thanks for clarifying that point. As a side note I find it interesting
> > that the *elected* DPL cannot override a *designated* delegate's
> > decision. That could pave the way for some interesting problems in the
> > future...
>
> Well, I'm not old enough to have written the constitution, but I do see
> the rationale for that choice. If that constraint were not there, one
> might imagine the DPL delegating a decision to someone only if that
> someone takes decision to the liking of the DPL.
>
> > > I've hence talked with both FTP masters and Aurelien (as part of the
> > > ongoing discussion about the status of debian-ports which has already
> > > been mentioned on this list). With Aurelien, and thanks to the help of
> > > Stephane Glondu, we believe we can add the needed missing space to
> > > debian-ports quickly, let's say in a week or two. FTP masters have
> > > agreed to postpone the removal in the meantime. But please:
> >
> > Thanks, this sounds already more reasonable.
>
> Let's try to do our best on that front. Please ping me again if you hear
> nothing in a week or so.
>
> > That prompts the question of why is this an unofficial commodity, but
> > I suppose this is another debate.
>
> Indeed it is and I agree with you that it would be better for it to be
> an official commodity, but that won't magically increase the volunteer
> manpower that keeps debian-ports running ...
>
> Cheers.
Reply to: