Fedora Extras packaging beta software into production repos, why?

[Nicolas Mailhot]

Le lundi 30 octobre 2006 à 23:26 +0100, Michael Schwendt a écrit :
> On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote:
> 
> > 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.
> 
> A couple of valid questions have been raised. And an upgrade to a beta
> release with an approval in less than 24 hours is something that is
> broken. In particular since with a rushed release of beta-level pieces you
> increase the risk of breaking even _compatible_ 3rd party repositories.

You'd be right if projects used strict versioning. Since the vast
majority doesn't you're wrong.

Also, this would not apply to devel

Also your proposal is not answering the beta question at all.

> And your hands are empty, so you cannot even recommend a downgrade or
> disabling the 3rd party repo.

You mean, you can't even do the kind of recommendation the same
3rd-party flamed about the week before this one ?

> All you can do is shake your head and say:
> "Sorry, Joe User, we're not ready yet.

All you can do is shake your head and say: "Sorry, Joe User, this is
being integrated in FE and your 3rd-party provider is not ready for the
partial migration yet"

> Instead of practising sane release habits in order to gain experience for
> something like EPEL, we move closer to the infamous dumping-ground.

Sane release habits include releasing beta versions, experimenting and
generally not waiting till everything is cooked (and stale) before
thinking about releasing.

This is why RHEL relies on FC
This is why FC relies on rawhide
THis is why rawhide relies on p.r.c. experiements

> > When you release twenty conflicting packages at once instead
> > of releasing them as they are approved you are maximizing pain.
> 
> No, because then your hands are not empty. You have an approved complete
> set of packages which is expected to "just work". This is much better than
> pushing out fragments.

This will just result as with clamav in "FE released a set of packages
using totally different conventions than me, it will never gracefully
upgrade users of my repo, I'll maintain my fork ad vitam eternam then"

> > > 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).
> 
> The same feedback that started this thread?

Yes. Thought it could have been more constructive

> If we really expect integration by 3rd party repositories, we ought not
> jump to beta releases so suddenly.
> 
> > > > 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.
> 
> Reviewers complain that many packages need a lot of work before they would
> be ready. And if packagers drop off that is because they don't show real
> interest in getting their packages right. Look at the many packages, which
> have no BuildRequires at all, because the packager does not know about
> this requirement. When all of a sudden the reviewer requests changes to a
> package, which seems to just build on the packager's system, guess how
> some people react.

So your magic bullet is allow anyone to freeze indefinitely a review by
declaring it's part of a bigger packageset.

> If everybody, who complains about the slowness of the review process,
> contributed a review occasionally, this would help.
> 
> Ask yourself, how long is it since your last review?

4 days actually

> > 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.
> 
> If you come up with such examples, the sad truth is that so far we fail
> miserably, because we break ABIs (and not just ABIs) way too often with
> all those library major version upgrades, where we don't offer
> compatibility packages.

So is it a yes or a no?

> Fact is: we still don't care about 3rd party packages or "unpackaged"
> end-user installations.

So what is the problem with releasing partial packagesets again ?

>  We only care where cooperation and collaboration has been agreed on _actively_.

Which is why I proposed to allow 3rd-paties interested in cooperation to
request a non-extendable grace period in the review. This requires them
to explicitely implicate themselves, instead of relying passively on the
glacial pace of FE

> And since you mention "months if not years", even packages, which are
> actively maintained and just wait for a review in bugzilla, 

I'm not talking about actively maintained packages waiting for a review
in bugzilla I'm talking about actively maintained packages which passed
the review and are in FE.

> > *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.
> 
>  From now on I will look for ways to veto when I plan to review parts of a
> dep-chain and when I have reason to believe a package approval is
> rushed. The only alternative is to stop reviewing.

-- 
Nicolas Mailhot