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

Re: Canonical and Debian

On Sun, Jun 05, 2005 at 07:15:49PM +0200, Josselin Mouette wrote:
> Le dimanche 05 juin 2005 à 19:00 +0200, Jeroen van Wolffelaar a écrit :
> > If you're going to complain about a cabal, please do try to get the
> > facts straight: The DPL team consists of only one Canonical employee,
> > who was even later, after the election, added (Benjamin "Mako" Hill),
> > and in Vancouver, again there was only one[1] single Canonical employee
> > present (James Troup). All the others involved with either of those two
> > groups are not involved in Canonical at all, and only one or two are
> > marginally involved in Ubuntu.
> Then how did these people end up choosing to support the same set of
> architectures as Ubuntu?

I know I've been screaming murder and hell about this, but in hindsight,
after having read the proposers' explanations (and the proposal itself
for a few more times), this certainly is not what they're proposing.

The whole thing is confusing, because the one nybbles mail talks about
multiple things, and it's easy to mix those up. But in reality, the
nybbles proposal suggests that we do the following:

* Split the architectures over two sets of mirror networks, so that
  mirror administrators don't need 100G just to mirror Debian anymore.
  This has nothing to do with what architectures can release a "stable"
  and what architectures cannot; only with mirror bandwidth and disk
  space usage. The popularity of an architecture will be a deciding
  factor in the decision of what archive mirror network will be used,
  but there's of course nothing wrong with that; architectures would be
  allowed to create a stable release on that "second-class" mirror
  network, and that's what counts.
* Create a set of rules that an architecture has to abide by in order to
  be allowed to release. This set of rules would be there to make sure
  that a port's porters, rather than the set of release managers, ftp
  masters and the like, do all the work in making the port work.
  Provided that set of rules is sensible (which I'm not entirely sure of
  right now, but that can be fixed), there's nothing wrong with such a

While it is indeed very likely that only amd64, i386, and (perhaps)
powerpc fall in the first thread, the same is very much not true for the
second set.

> I know this has been discussed to death, but I still fail to see which
> problems in Debian the Vancouver proposal can actually solve.

Then I suggest you go back and read the vancouver proposal one more
time, keeping the above in mind.


The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Attachment: signature.asc
Description: Digital signature

Reply to: