Hi, 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 http://lists.debian.org/debian-devel-announce/2005/12/msg00014.html 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