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

Re: Bits (Nybbles?) from the Vancouver release team meeting

This one time, at band camp, Stephen Frost said:
> * Stephen Gran (sgran@debian.org) wrote:
> > This one time, at band camp, Henning Makholm said:
> > > The point is still that some architectures are going to be left
> > > out in the dark. That's the purpose of the whole plan.
> > 
> > Only if those architectures don't have sufficient community support.
> > I really cannot see the problem with that - you want to release
> > architectures that aren't well supported as 'Debian stable'?  I
> > don't.  Under the terms of the proposal as laid out, all 11
> > architectures shipping with sarge _could_ ship with etch (although
> > they might not be mirrored so widely).  It is just up to the porters
> > to make sure this happens.
> I don't believe this is accurate, and is in fact a big problem that I
> have with this proposal.  Things like "N may not be more than 2" and
> "architecture must be available for purchase new" are not things which
> the Debian community is likely to be able to fix.  Supplying more than
> 2 machines, and the manpower to admin them, is something the community
> could do and if that happens and someone offers to join the security,
> RM, etc teams to handle post-release support I think the arch should
> be released as stable.

There was a later clarification (from Andreas Barth? - I can't remember,
it's something like 1000 messages ago now :) that addressed those
statements in a better way.  There were concerns that they were
attempting to address, namely - the inability of the buildd setup to
continue should a machine fail, and the long time it takes important
fixes to be built from source on some architectures.

The clarification made it fairly clear to me that if this is achieved by
the porter team running clusters with distcc and magic smoke, and has a
back bedroom full of spare parts, that should satisfy the criteria.  The
point was that Debian's core infrastructure shouldn't be responsible for
limping along a dead architecture that is essentially unavailable, and
that security fixes and the like have to be done in a more timely

I see no reason why a team of interested individuals can't make this
happen - magic smoke is cheap, after all :)

Take care,
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |

Attachment: pgpCX9tsbsLk6.pgp
Description: PGP signature

Reply to: