Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

On Tue, 31 Oct 2006 07:46:04 +0100, Nicolas Mailhot wrote:

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

Said beta releases have been put into "stable", i.e. FC-5 and FC-6,
immediately.

Hence the stuff has NOT been given a chance to mature in devel, not even a
few days, for observers to take notice of their addition to FE.

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

What is it? That any community observers, who may have followed the status
of the asterisk+deps reviews, all of a sudden needed to be unbelievably
fast because after a long time of reviewing stable releases, there is a
jump to a beta release which is approved in less than 24 hours.

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

?? Not yet? The 3rd party package provider has had a complete set of rpms
for this software.

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

Cheap talk, Nicolas, considering that none of this has given a chance
to be post-reviewed in devel.

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

No problem. Different package design can be a valid justification for
somebody to offer alternative packages. This is not the same than offering
only fragments, beta even. Beta fragments aim at increasing barriers.
 
> So your magic bullet is allow anyone to freeze indefinitely a review by
> declaring it's part of a bigger packageset.

Freeze = good. Freeze = no moving target. Freeze = beneficial for the
reviewer, who does more than suggesting tabs-to-spaces fixes.

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

Which email address is that? FE-ACCEPT points to a single approval only.

If you think this thread could be more constructive, simply jumping on the
bandwagon of those, who complain about the slowness of the review process,
is not constructive at all. Because it doesn't propose what should be done
with all the pending packages, which are in serious need of fixes, and
what could be done to lower hurdles for stock contributors (we've talked
about it a long time ago, but have found that at least some items must be
reviewed, so we cannot get rid of reviewing for long-time contributors or
something like that).

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

It's an irrelevant example. Said sysadmin will be very annoyed by sudden
upgrades to beta releases.

Twisting words doesn't lead to anything at all. *If* we offer a library
package, in good hope that some of our users creates a dependency on it
(through software which is not in FE), we ought to cover this scenario in
the packaging guidelines.

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

Either you're interested in improving the situation or not. In case you're
not, don't enter a loop.

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

Ah, a proposal. Now we come to something. ;)

I'm not fond of the idea that arbitray people could request such a
grace-period, as in fact anybody can add a comment in bugzilla already and
express concerns or point out problems, provided that the chance is given
(aka no blitz-reviews after sudden upgrades to beta releases!).

It would be different if it were fellow FE contributors who could demand a
grace-period.

Earlier in this thread I've asked whether FESCo has looked at this
conflict.

My suggestion is that upgrades to beta releases must be explained in
both the review ticket and within FE in spec %changelog.