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

Package flow scenarios (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven, pPlease teach you and your mutt the use of reply-to-list]

On Monday 14 March 2005 14:06, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 01:02:34PM +0100, David Schmitt wrote:
> No, you didn't understand.

You are right.

> let's tell the plan again : 
>   1) people upload to unstable always. Only source are considered, and
> people not having tested them and upload unbuildable sources are utherly
> flamed for their lack of discern :).
>   2) the autobuilder build those packages for unstable for the tier 1
> arches.
>   3) after some time, the packages are moved to testig, as done by the
> testing script for the tier 1 arches.
>   4) the tier 2 arches build their stuff from testing. there are two
> results of this :
>     4.1) the package builds without problem, it is added to the tier 2
>     archive.
>     4.2) the package fails to build. This used to be a RC critical FTBFS,
> but is not so anymore. The porter are responsible for fixing the bug and
> uploading a fixed package to unstable, as they do now.

Wouldn't it be better: "The porter are responsible for fixing the bug and 
supplying a patch?" Of course, in the case of unresponsive maintainers, there 
is always the possibility of an NMU, but this shouldn't be the norm - not 
even with tier-2 arches.

>       4.2.1) the unstable built package passes testing rather quickly, and
> is then rebuild for the tier 2 arches, back to 4).
>       4.2.2) the unstable built package is held out of testing for whatever
>       not tier2 arch relevant issue. They can then be built in an
>       arch-specific way, and uploaded directly to the arch in question, or
>       maybe through a arch-specific-mini-testing-script.

Careful: this would touch on "binary packages must be built from the 
unmodified Debian source (required, among other reasons, for license 
compliance)" from the Nybbles proposal.

[benefits moved downwards for discussion]

> Now, given this full description, does my proposal seem more reasonable ?

Wow. I envy your ability to churn out such masses of mostly sane emails. Let 
me contrast this to my mind model of how Debian-flex will work in the case of 
a FTBFS on a tier-2 arch:

1) upload to unstable
2) autobuild for all tier-1 and 2 arches
   2.1) packages builds without problem: goto 4)
   2.2) FTBFS on tier-2 arch -> FTBFS bug+patch
        2.2.1) maintainer applies patch with high priority: goto 3)
        2.2.2) maintainer applies patch with low priority: goto 4)
        2.2.3) maintainer doesn't apply the patch: goto 6)

3) package is reuploaded with porters-fix: goto 1)

4) package propagates to testing without regard to tier-2 FTBFS
5) maintainer uploads next version with porters-fix: goto 1)

6) package probably needs a porter-NMU

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

All packages passing 2.1 and 4 would be eligible for a tier-2 testing. I have 
faith that the current discussion of the Nybbles proposal will lead to a 
structure allowing this.

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

The Nybbles proposal explicitly says: " They will be released with sarge, with 
all that implies (including security support until sarge is archived)"

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

If this can be archived properly (with fast security and stuff), then the arch 
could also reach tier-1 status (probably without ftp.d.o distribution)

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

"This is a dangerous time for you, when you will be tempted by the Dark Side 
of the Force."

Let's structure that again in a list. That helps me thinking.

1) tier-2 will have its own resources[1] and support/development team 
(currently porters).

NEW processing:
2) NEW processing will happen for Arch: all/any packages anyways
3) NEW Arch: tier-2-only packages can be judged by people from 1), because 
they have no impact on tier-1 (obviously)

4) forking a package would revoke its eligibility for tier-2 ("binary packages 
must be built from the unmodified Debian source") 
5) directly from 4) we can conclude that tier-2 port patches _have_ to be 
included in the main sources.

Which cases can we have when there is a porter-patch on hand?

MC) cooperative maintainer
ML) lazy maintainer
MU) uncooperative maintainer

MC obviously won't pose a problem, ML can be overridden via porter-NMUs and 
uncooperative maintainers can at least be overriden by the tech-ctte. Even 
the worst case: MU overridden by TC uploads new version without porters-fix 
after porter-NMU is covered, since this - in my eyes - constitutes "acting 
against the project" which _is_ unconstitutional. But let's hope that this 
won't be necessary ever.

I hope this makes my take on this matter clearer.

Regards, David

[1] I take that as given: If Debian cannot provide that (through donations or 
whatever) there is nothing to argue about.
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Reply to: