Dear archive admins, we have so far not received a reply or statement from you regarding the below post, or to the post by Steve Langasek with the message-id of 20080815052538.GW6019@dario.dodds.net. If we missed a reply, please let us know and repost it. for the Debian GNU/Hurd porters, Michael Banck On Sun, Oct 05, 2008 at 06:30:59PM +0200, Michael Banck wrote: > 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