Fedora Extras packaging beta software into production repos, why?

[Nicolas Mailhot]

Le lundi 30 octobre 2006 à 20:02 +0100, Michael Schwendt a écrit :
> On Mon, 30 Oct 2006 19:00:46 +0100, Nicolas Mailhot wrote:
> 
> > Le lundi 30 octobre 2006 à 16:18 +0100, Michael Schwendt a écrit :
> > 
> > > There is a simple solution: --> All or nothing. <--
> > > 
> > > [...]
> > > 
> > > Don't build pieces of a package-set just because they are approved
> > > already. Keep all dependencies in FE-ACCEPT state until the other packages
> > > in FE-REVIEW are approved, too.
> > 
> > It's simple but stupid.
> 
> Great choice of language here. Either you have misunderstood me or you are
> out on a mission to insult other people. Or both.

I'll admit to being in a foul mood, part of which being caused by yet
another message trying to 'fix' the non-broken part of last week's
conflict, and that after a lot of people tried very hard not to feed the
flames by keeping quiet.

> > 1. The dependencies won't conflict less when released later, you're only
> > maximizing the pain by releasing packages which never had exposure
> > separately.
> 
> No, far from it. And there is nothing like "maximizing pain". You only try
> to play with words.

No I don't. When you release twenty conflicting packages at once instead
of releasing them as they are approved you are maximizing pain. There's
a reason for the "release early, release often" rule. After a certain
amount of changes forks just become entrenched because it's so many
things to change at once before merging with mainline.

> Actually, in the majority of cases it is impossible to review individual
> pieces of a dependency-chain without taking a look at the entire set of
> packages.

Integration is good but package sanity is more tricky. If pieces of
something are released separately that does mean maybe 80 to 90% of the
packaging can be reviewed separately. Also the best test for integration
is to release parts of a dependency chains and get feedback on how these
parts are integrated by other entities (end-users, 3rd-party
repositories, etc).

> > 2. You're needlessly maximising bureaucratic inertia.
> 
> Where?

Packagers already complain the process takes too long.
Have packagers wait for the last of a dependency set to be approved
before releasing means we'll have even more dropouts before the review
ends.

> > Dependencies often
> > have worth by themselves, either for other FE packages or for people
> > running unpackaged stuff in the wild.
> 
> You say "stupid", I say "nonsense".

1. Take any system running an unpackaged app (don't pretend no such
thing exists)
2. Strip it of all the packaged components the app uses and force its
admin to install them separately (no problem since you maintain the
packaged deps have no value to the sysadmin)
3. If the sysadmin let you live, come back to report.

> > For example a few years ago I
> > packaged most amavisd-new deps which certainly helped when amavisd-new
> > was packaged by someone else. Your rule would have forced the
> > amavisd-new packager to start from scratch.
> 
> No. Please re-read and try again.

Please look at the amavisd-new ecosystem release timeline and come back.
The full process took months if not years. I would *not* be maintaining
part of the amavisd dependencies today if I had been forced to wait for
amavisd-new approval before release.

> > 3. You're rewarding the people who don't get their packages reviewed and
> > penalise people who follow the appropriate process.
> 
> No. This comment is beyond my comprehension. Sounds like FUD.
> Try again.

Any time you make the FE release process longer and more difficult you
just prove right the people who insist it's too hard and you can't blame
them for setting their own 3rd-party repositories. Approved is approved.
*IF* you're reviewing all the packages in a packageset *AND* you feel
you need the big picture you should not approve them separately. Now if
a reviewer feels he can OK one bit of a packageset separately, one
should not invoke "packageset veto" to block him.

-- 
Nicolas Mailhot