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

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



Sven Luther <sven.luther@wanadoo.fr> wrote:

> No, you didn't understand. let's tell the plan again : 
>
[...]
> This would have the benefit of :
>
>   - Not having slower arches hold up testing. 
>   - not overloading the testing scripts.
>   - allow the tier 2 arches to have the benefit of testing, that is an archive
>     with packages suffering from RC bugs and breakage-of-the-day, as if they
>     build from unstable.
>   - diminish the workload for the tier 2 autobuilders, since they only have to
>     build proven good packages, and not random stuff going in unstable.
>   - still allow the tier 2 arches to be part of debian, and hope for a sarge
>     release, which yields to :
>
>   5) Once a stable release is done, the above can be repeated by the tier 2
>   arches, until they obtain the release quality and maybe be part of a future
>   stable point release.
>
> Now, given this full description, does my proposal seem more reasonable ? 

Yes, this seems very reasonable to me.  I'm not sure what the exact
plans for "after-sarge" are, therefore I don't know whether the
decisions need to be made before sarge is out, or not.  But I definitely
think that the people involved in the Vancouver meeting should be asked
about this, and should comment.

And somebody should start coding, of course...

>> Obviously britney/dak is available from cvs.d.o and meanwhile also as debian 
>> package. So the question for me (administrating two sparc boxes) is why _we_ 
>> don't setup our own testing when obviously the ftp-masters and core release 
>> masters are not willing to do the work for us? 
>
> I guess this is also the message i get from them. The same happens for NEW
> processing, and the solution is to setup our own unofficial archive, thus
> leading to the split and maybe future fork of debian.

I think it would be cool if people could actually show, let's say for
one arch, autobuilders that implement the scheme you described.  But
finally it should definitely be brought back into Debian proper.

>> > You are really just saying that the testing scipts don't scale well, and
>> > instead of finding a solution to this, you say let's drop a bunch of
>> > architecture, and make it another-one's problem.
>> 
>> I think you have hit the point of this reorganisation head on: the people who 
>> did the work until now, feel that they cannot do the work with the expected 
>> quality _and_ the current number of arches. Thus they make the hard decision 
>
> They don't scale well, and have passed the past couple of year insisting that
> there is no problem apart from the waste majority of DDs likeing to complain
> and flame overmuch.

I do not think that such an accusation is justified, at least not with
respect to most teams and individuals involved in the meeting.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: