[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.
Check.
> - not overloading the testing scripts.
Check.
> - 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)
Forking:
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
