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

Re: Back to basic (was: Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

* Thijs Kinkhorst (kink@squirrelmail.org) wrote:
> Example minimal quality standards:
> - it should have a large part of the packages built
> - there should be enough buildds to keep up with security and new uploads
>   within reasonable time.
> - there should be some minimal team to support this architecture
> Any arch / porting team that satisfies our demands can be included.
> I honestly think that we (almost) all agree that putting these kind of
> demands in place is not too much to ask. What exactly the thresholds
> should be, that's a point of discussion. Let's first start to see whether
> we agree that putting these demands on an arch this is neccessary to
> remain our overall quality. we could then, if we do, start working on
> drafting up the exact demands and parameters.

These don't seem bad.  It doesn't solve some of the problems I believe
the proposal was intended to solve though:

The release team doesn't think it can handle any more than X archs where
X seems to be 4 or 5.  I also understand it to be the case that the
release team doesn't think additional people (or anything?) would help.
Personally I can understand this in some regards, toolchain problems,
d-i issues, etc that can't really be parallelized.  I'm not convinced
that this is the real driving factor with some of these requirements
though and that this would be impossible to improve.

As far as I can tell, without any actual word from them, I believe the
ftpmasters/DSA feel that there's a certain number of machines (including
things like buildds and whatnot) that they can support.  In this case it
doesn't seem like adding people could *not* help so I'm guessing the
concern there is that there aren't enough trusted people willing to join
ftpmasters/DSA to increase the number of machines capable of being
maintained much.

As I understand it, there wasn't anyone who's active on the security
team who was at the meeting to help draw up the proposal but I believe
it's been said that they also have an idea as to the max number of
architectures they can support.  It's not clear if that's got anything
to do w/ the number of people or just the general quality of buildds and
in some cases maintainers (kernel at least?).  Personally I tend to
think it's probably some of both- manpower and buildd infrastructure

There are some other technical issues having to do with the way
wanna-build works and that having testing for all architectures will
overload a very nice system with ssh connections.  There is work being
done to fix this already by using ssh connection cacheing.  I'd hope for
a more in-depth look and possible rewrite/rearchitecting of wanna-build,
this limitation is somewhat concerning.  Another technical issue is
mirror space but I think that's handled just fine by only mirroring
certain architectures, as I understand the plan is, and I think there
will still be some mirrors who will mirror everything so I think that'll
be alright in general.

These are just my speculations and guesses, I'd love for those involved
to step up and correct me.  If I'm right it'd be nice to get some


Attachment: signature.asc
Description: Digital signature

Reply to: