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

Re: Vancouver hierarchy - proposed terminology

Scripsit Sven Luther <sven.luther@wanadoo.fr>
> On Tue, Mar 15, 2005 at 09:56:03PM +0000, Henning Makholm wrote:

>>    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.

Perhaps, but I was trying to find suitable terms for the distinctions
in the Vancouver plan, not to invent my own.

(And personally I hope that the eventual outcome of this discussion
will be a set of rules that will allow every architecture with
sufficiently dedicated porters to become REGULAR, such that the only
IRREGULAR architectures will be those where the porters themselves do
not think that the port is ready for a stable release yet).

> 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,

I understand that one of the (perceived) problems is not just lack of
manpower in the release team, but the fact that migration to REGULAR
testing is unacceptably slow if it has to wait for architectures that
do not satisfy REGULAR criteria (whatever these might end up being
after discussion).

> 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).

My proposal does not give terms for security status, because no such
distinction exists in the Vancouver plan as published.  If a plan that
does involve different security states gets constructed, I'll be happy
to attempt to coin words for them.

However, the later posting from Martin Schulze seems to indicate that
the only thing the security team really wants to have is a stable
autobuilder system and REGULARity of the released source base. This
implies to me that it probably won't be necessary to invent further
categories for security support.

Henning Makholm          "Gå ud i solen eller regnen, smil, køb en ny trøje,
                   slå en sludder af med købmanden, puds dine støvler. Lev!"

Reply to: