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

Re: Vancouver hierarchy - proposed terminology

On Tue, Mar 15, 2005 at 09:56:03PM +0000, Henning Makholm wrote:
> The debate is being hard to follow, with tiers, classes of citizenship
> and several other distinctions being tossed about, and not always
> clearly mapped to a particular one of the two divisions in the plan.
> I propose the following terminology (also paraphrasing the outline of
> the plan according to my understanding):
> 1. A MEMBER architecture is one that the upload queue scripts knows
>    what to do about. The criteria for being a MEMBER are
>      - must provide basic Unix functionality
>      - must have a working buildd
>      - must have X users, Y of which must be DDs
>      - (et cetera)
> 2. MEMBER architectures are divided into IRREGULAR and REGULAR
>    architectures. REGULAR architectures make stable releases in
>    lock-step; thus problems on one REGULAR architecture can block
>    the release of all others. The release process for REGULAR
>    architectures is controlled by the DPL-appointed release team,
>    currently using the "testing" suite as a common staging area.
>    The criteria for being REGULAR are
>      - must be a MEMBER
>      - must have a working installer
>      - must have redundant buildd capacity
>      - (et cetera)
>    An IRREGULAR architecture either does not make releases, or release
>    according to a schedule that does not match the REGULAR one. (One
>    possible instance of this is "we'll try to parallel the REGULAR
>    release, but they are not going to wait for us if we blow a tyre
>    along the way"). The porters must provide their own release
>    management and staging area (management).

I think it would make sense to distinguish between IRREGULAR and INDEVELOPMENT
architectures here. The IRREGULAR ones being those that want to do a release,
but the release team doesn't care to handle for whatever reason, and the
INDEVELOPMENT ones being those that the porters feel is not ready for a

That said, i just wonder if the solution to this would not simply be for the
release team to simply have one or more assistant in charge of the IRREGULAR
architectures, instead of insisting the porters do the release on their own,
after all these port release management guys are prime candidate to be
promoted to full release manager assistants or whatever later on, as they
already have the right credential for it.

Your proposal also ignores security team's requirement which may be orthogonal
to the release team requirements, as their timeline is fully different
(post-release vs pre-release).


Sven Luther

Reply to: