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

Re: Upcoming changes to supported architectures

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

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

Reply to: