Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

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.

And your hands are empty, so you cannot even recommend a downgrade or
disabling the 3rd party repo. All you can do is shake your head and say:
"Sorry, Joe User, we're not ready yet. You need to disable Fedora Extras
and check back as soon as the remaining packages are ready. When that is,
we don't know."

Oh man, if you think you are in "a foul mood", I'm surprised that these
days I find myself argueing *for* 3rd party repositories instead of
defending FE's right to include and publish whatever we want. And that is
only because I dislike the way fragments are pushed out to stable trees
without being finished with the complete package-set.

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

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

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

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.

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?

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

Fact is: we still don't care about 3rd party packages or "unpackaged"
end-user installations. We only care where cooperation and collaboration
has been agreed on _actively_. Which is something which works with _every_
3rd party repository out there, provided we are willing to do it and not
slam the door right into someone's face.

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

Please take into account the very small number of contributors which
processed hundreds of reviews and simply could not be everywhere.

Several different concepts of getting more packagers to do reviews have
been tried. Packagers have been encouraged to exchange reviews, packagers
have been asked to collect feedback from interested users, so a single
reviewer would not need to everything alone and could sign off the
technical packaging and be done.

And since you mention "months if not years", even packages, which are
actively maintained and just wait for a review in bugzilla, often contain
serious defects or pitfalls, simply because not even the packager attempts
at reviewing his own package.

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