[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming changes to supported architectures


first of all, we are a bit unsure about the intended timeline.  Do you
plan to remove architectures which fail to release for the next two
releases (i.e. lenny and lenny+1), or will you impose this new policy
retro-actively for the etch and lenny releases, i.e. kill off the ports
on relatively short notice?

For the Debian GNU/Hurd port, this would be unfortunate - we have made
quite some progress (see also the "Bits from the Debian GNU/Hurd
porters" we sent out recently) over the last two releases to keep better
uptodate with the archive on the one side, and have improved general
archive coverage on the other side as well.  We think it is safe to say
that the GNU/Hurd port has not regressed over the lenny timeframe, but
(albeit quite slowly, admitted) advanced.  Actually, we were hoping to
engage the release team in a discussion about a possible hurd-i386
testing distribution after the lenny release.

One thing to keep in mind is that Debian GNU/Hurd is one of a kind - it
is the only GNU/Hurd distribution there is, we cannot just tell our
current or potential future users to go use Fedora or Ubuntu instead.
We are aware that the absolute figures do not look so great, but keeping
the Hurd port coasting along was quite some hard work by a couple of
people over the last years; new upstream releases of glibc or Xorg
routinely have to be fixed/ported; the work that has been needed was
probably bigger than for non-mainstream Linux ports.  

Like some other Debian Linux ports, the GNU/Hurd port is only worked on
by a couple of people - and it is unclear whether we would have the
energy to re-donate the port to Debian at a later time after having been
removed.  The nature of a non-Linux port makes rebuilding it much harder
- a lot of packages FTBFS due to the false assumption of being compiled
under GNU/Linux and sorting out dep-waits and build failures was a
tedious task we are not looking forward to doing again in the near or
middle-term future.

As for more specific comments:

On Fri, Aug 15, 2008 at 05:51:00AM +0200, Joerg Jaspert wrote:
> > 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.
> Debian is a distribution, and distributions want to release. 

This is a statement you seem to be doing in the name of the project that
we are not convinced is so clear as you put it.  It may be true that
distributions want to release in general (even though there are project
members who seem to think otherwise, and many people get along fine
running Debian testing or even unstable), but we do not think it follows
from this that the whole project should align to this goal completely.

In any case, the Debian GNU/Hurd port has made snapshot releases of some
sort which are used by its users - the more recent ones can be found at
http://ftp.debian-ports.org/debian-cd/ (the K* directories).  We already
wrote above that we would like to cooperate more to have a testing
distribution or an unofficial testing-like distribution to help our
users, as well as working towards official releases in the end. 

> 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.

As it seems that in the near future not a lot more new releasing
architectures might get included compared to those which might get
removed, is there really such a big pressure on resources?  

> > 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.

Can you please explain what these are, you seem to have not yet replied
to Steve's further questions from 20080815052538.GW6019@dario.dodds.net,
possibly the resource contstraints could be solved by a different
approach as well?  Maybe one way to cut down on resource use would be to
no longer mirror currently non-releasing arches on ftp.debian.org etc. -
but simply once e.g. on ports.debian.org, which might or might not
reside on the same machine as ftp.debian.org.

> > 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?
> JFTR, this was passed via an m68k porter, release people, other ftp
> people, dpl and a dsa...

On a personal note, it is still somewhat disappointing that such a plan
is presented to us without having asked for our feedback.  

> >> 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?

Hrm, what about
which got drafted at some point after the Vancouver meeting?

During the discussions that followed, wiki pages were setup for the
mentioned architectures for the ftp-masters to inspect, see e.g.
http://wiki.debian.org/ArchiveQualification/kfreebsd-i386 and
http://wiki.debian.org/ArchiveQualification/hurd-i386 .  We took quite
some effort over time to keep those updated etc. for you ftp-masters to
evaluate and always assumed we would be judged by this.  We understand
that aj is no longer an ftp-master, but some continuity in this would
have been nice.

To summarize, we would like to ask the ftp-masters to rethink their
intention to remove the hurd-i386 port from the Debian archive, and
engage in a discussion on how otherwise an improvement of the situation
can be reached.

the Debian GNU/Hurd porters,

Michael Banck
Samuel Thibault
Barry deFreese
Guillem Jover

Attachment: signature.asc
Description: Digital signature

Reply to: