Re: Results of the meeting in Helsinki about the Vancouver proposal
On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote:
> On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
> > 1. The requirement that 'an architecture must be publically available to
> > buy new'.
> >
> > It was explained that this requirement was not made to be applied
> > retroactively to already existing ports; rather, it was designed to
> > avoid new hardware which, as of yet, is only available under NDA, or
> > to avoid things such as a Vax port of Debian. Older ports, such as
> > m68k and arm, are expected to reach a natural end-of-life to a point
> > where it no longer is possible for Debian and the port's porters to
> > support it, at which point the port would then, of course, be
> > dropped.
>
> Where's the definition of "natural end of life"? Who defines when this state
> is reached? The porters (how many of them then?)? What is meant with "no
> longer possible ... to support it"?
What that phrase is trying to say is that nobody will force any of those
older ports out of the archive -- at least that's what the release team
and DSA members present at the meeting told me. It's expected that, at
some point in the future, it will be technically or practically
impossible for porters to continue to support those ports; that's when
they'll be dropped.
[...]
> > In that light, we agreed on a procedure for dropping a port which is
> > designed to avoid abuse, by making it as open as possible: if any of
> > the aforementioned teams wants to use their veto power, they have to
> > post a full rationale to the debian-devel-announce mailinglist, with
> > an explanation of the problems and reasons for their decision.
>
> I would like to see a detailed rationale under what circumstances such as
> veto might be raised *beforehand* anyone can veto something. It should be
> clear what requirements must be fulfilled so that a team can veto something.
> Otherwise you'll end always with discussions where the vetoing team says
> this and the other team (like porters) say that. And what if someone has
> objections against that veto? What procedure will handle this situation
> then?
There are already procedures in place in Debian to overrule a delegate's
decision, if necessary. It's pointless to duplicate that.
> > 4. The requirement that any port has to have 5 developers support it,
> > and be able to demonstrate that there are (at least) 50 users.
>
> How should this demonstration should be achieved? What is the procedure for
> this? When I grep my /etc/passwd I have 28 users for m68k on my own, but
> that machine just counts as one user on popcon.d.o.
>
> > Some people feared that this could kill off a port such as s390,
> > which typically has little installations, but many users on a single
> > installation. It was confirmed that the important number here is the
> > number of users, rather than the number of installations; so any port
> > should be able to reach that number.
>
> ... and this paragraph makes clear, that you just can't use popcon for that
> issue. So, how shall those users be counted?
This is not specified, and deliberately so. Any way you can come up with
that demonstrates 50 users should do (although it may require _active_
users; the idea is to avoid ports that are only being used by the build
daemons)
> > None of the participants had a problem with any of the other
> > requirements. Note that the separate mirror network is fully distinct of
> > the rest of the original proposal (although there was a significant
> > amount of confusion over that fact). The ability to be part of a
> > stable release (or not) would be fully distinct of the separate mirror
> > network; indeed, the implementation of both items will now be discussed
> > and implemented fully separate, to avoid further confusion.
>
> During the original vancouver proposal discussion the mirror network problem
> was said to be the reason for the vancouver proposal. So, I expected a more
> detailed info about this issue and how it would be solved (and when).
> When the reason for the vancouver proposal is "just" mirror space on "some"
> mirrors, why should this be addressed by a potential drop of archs anyway?
It shouldn't, and this was confirmed at the meeting. That's where the
confusion lies.
> Why don't let the mirrors just mirror what they want? Nobody forces a mirror
> admin that he *has* to be a primary mirror, right?
> I have absolutely no problems with mirrors that don't carry all archs as
> long as there are several mirrors that do.
Ditto.
> > - binary packages must be built from unmodified Debian source
>
> Uhm? When there is a new arch upcoming, they need to modifiy the Debian
> source, at least sometimes, right?
Yes, and this happens. I've already had requests to modify my
Architecture: line in my nbd packages for new ports, such as amd64 and
ppc64, even before they're part of the archive.
It's not hard to do this, and if there's a valid patch, people usually
apply it.
> > - binaries must have been built and signed by official Debian
> > Developers
>
> This has been always the case, right?
Yes.
> > In addition to those points, we also agreed on the following:
> > * The m68k porters (i.e., myself) would test out a buildd running with
> > distcc so that a cost/benefit analysis of such a setup could be made.
> > A full explanation of why such an analysis is required would take us
> > too far; suffice to say that it isn't entirely guaranteed that there
> > would be a noticeable performance increase, while the cost to maintain
> > such a setup (as opposed to a regular buildd setup) is nontrivial.
>
> Oh well, the current distcc on m68k simply doesn't work. Been there, done
> that...
Oh? I didn't know. Please send me details in private mail.
[...]
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: