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.
> 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.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature