Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008 at 05:51:00AM +0200, Joerg Jaspert wrote:
> > I feel I'm missing the full rationale for this change. What are the new
> > architectures in the pipe that space needs to be made for?
> There are multiple bugs in the ftp.debian.org pseudopackage about
> architectures wanting to get in.
> > For that matter, the current ftp-master disk is 81% full, and that's
> > with oldstable not yet purged from the pool, something which is now
> > long overdue; so why is any architecture clean-up currently needed at
> > all?
> Cos some architectures just eat space that can be used otherwise. And
> the current disk usage on ftpmaster isnt the only metric that counts.
You stipulated in your mail that this was to "free up space for new
[architectures]". What other metrics count for that?
> Debian is a distribution, and distributions want to release. If an
> architecture can't do that - its fine to have a port, but please dont
> take any resource that could be taken by an architecture thats actually
> able to release.
So the current architectures I see wishlist bugs for on ftp.d.o are s390x,
sh[34]{,eb}, netbsd-i386, and kfreebsd-{i386,amd64}.
Which of these are currently in a more releasable state than hurd-i386?
Doesn't s390x have the same problem as sparc64, where it's not actually
beneficial to build the whole system for this target?
> > If we aren't really running into resource constraints linked to the
> > architecture count, it's a poor use of people's time to have to
> > redeploy all of the ftp-master infrastructure on a separate host.
> We *DO* run into resource constraints more often than we like it.
Ah. What resources are the limiting factors?
Supposing that disk is the main limiting factor, would the porters whose
port is on the chopping block have the option of covering the expense of
adding more disk to ftp-master if they chose to? After all, hosting their
own port mirror is a proposition of essentially the same magnitude, but with
more duplication of effort on the admin side.
> > And it's my understanding that arm is already intended to be dropped
> > immediately post-lenny in favor of armel.
> Yes. arm, m68k and hurd-i386 are the current candidates, with arm
> (AFAIK) totally dying, for the other two I expect someone else to host
> an archive. And maybe, at some time later, one of them coming back. But
> thats future.
But, er, the stated criteria don't even call for arm's removal from
ftp-master until the release of lenny+2, so surely the proposed rules are
orthogonal to the reasons why arm will be removed?
> > Is this a unanimous decision of the ftp team? You say that discussions were
> > had at DebConf 8, but not all of the ftp team (or even all of the ftp
> > masters) are present there...
> I know that not all of us have been here. Where is the point?
I'm asking whether the members of the ftp team not present in Mar del Plata
were consulted in this decision, because that's not how you presented it in
your email.
> JFTR, this was passed via an m68k porter, release people, other ftp
> people, dpl and a dsa...
It was passed by an m68k porter, so presumably the m68k team is ok with it.
But surely if it's relevant to mention that an m68k porter was consulted, it
would have also been appropriate to consult a hurd porter if that port is
also on the chopping block?
The other groups on that list don't seem to have a vested interest in the
ports that are on death row; so it's fine that they're all ok with the plan,
but that doesn't automatically make it binding on the rest of the project,
and it's not a very consensual approach to the subject.
> >> If you disagree - please provide sane alternative suggestions.
> > In the absence of an explanation why this change is needed, I suggest "don't
> > change what's not broken" as a sane alternative.
> The fact that we currently have *no* guidelines at all is broken, so we
> fix it.
> Now, we get complaints if decisions are made on a case by case basis. We
> get complaints if we provide guidelines that are easy and clear. What do
> people want?
Based on past experience, I would say that one thing people want is to be
consulted instead of having decisions handed down from above.
I'm skeptical of these particular guidelines as stated, anyway, because:
- The bar for a dropped arch to get back in is to "prove it will be able to
make the next official release", but nowhere is it explained what the
burden of proof is. Meeting the release team's arch qualification
requirements at the time that reinclusion is requested does not *prove*
that the port will still be releasable at release time.
- There don't appear to be any stated requirements for including a /new/
architecture in the archive, so it's not clear to me how the determination
is to be made that a new port is more worthy of archive space than an
existing one.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: