Don't put new packages through updates-testing

[Jesse Keating]

On Friday 01 June 2007 10:49:39 Hans de Goede wrote:
> But going through updates testing for each and every bugfix / update is
> just adding unnecessary burden and delays. Why can't this just be left to
> the packagers discretion? I think I've done enough for Fedora to deserve
> some discretion.

This is a broader issue, but I don't think it's set in stone anywhere that 
every single update (or new package) has to go through updates-testing.  We 
strongly encourage it and start throwing daggers if you don't do it and 
introduce issues on a stable platform, but I don't think there is anything 
physically stopping you from going straight to updates.

> >> I'm very much against this, as it adds one more step to already long
> >> process of getting new packages in, the current wiki page describing the
> >> process divides it into 14 steps and it is lacking the add to comps step
> >> (and in my case the update SIG wiki pag, twice once to add it to the
> >> list of packages undergoing review, once more to remove).
>
> Please respond to this very imporant point!

Um ok, yeah , adding software is a process.  That sucks.  Throwing out crap 
builds to users untested sucks too.

> >> It removes much of the satisfaction of after completing the review
> >> having the package into the hands of the end users, the ones for which I
> >> do this. As it adds yet another delay.
> >
> > You can still get your new package into rawhide immediately (or rather
> > with the next rawhide push).  There is instant satisfaction there.
> >  Bringing a brand new package to a supposedly stable released platform
> > should be done with some caution and thought, and with letting a wider
> > audience poke at it first in updates-testing before letting it loose upon
> > the masses.
>
> 1) There will be no wide audience, even if they have updates-testing
> enabled they will not automatically install the new packages let alone use
> it, the only way to get a wide audience is to put it in updates and in
> comps, so that people can install it through "add/remove software". For the
> majority of users, if it isn't in comps it doesn't exist, since
> updates-testing has no comps *, the package doesn't exist and thus will not
> get tested.

That's just a simple matter of using the comps-f7.xml comps file when 
generating repodata for the Fedora 7 updates.  Then suddenly you have entries 
in add/remove software for things in updates-testing.

> * and if it will, that means yet more work to get a package out

You should be adding the package to comps if it makes sense to have it in 
comps anyway, for each platform you'll build it for.

> >> The arguments made in favor of this is that it will be good for QA,
> >> however relatively few users will have updates testing enabled
> >
> > And your data set is where?  Perhaps we should query Mike McGraths
> > statistics stuff to see how many unique IPs are hitting the mirror list
> > for updates-testing.  It may be small, it may be large, but I'm not going
> > to just pull an observation out of my posterior.
>
> I said relatively small, as compared to the total of Fedora users. You
> still do not seem to be getting the point, that the problem is that even if
> the new package is in updates-testing, it won't get installed let alone
> used all of a sudden. For all but the top 100 popular new packages, being
> in updates-testing thus adss no additional testing as no-one will install
> it.

That's simply a matter of gathering up a team of people or organizing 'new 
package frenzy' days to get sets of people to target NEW packages to existing 
releases for testing.

> >> and new packages
> >> will not automatically get installed let alone used by those users.
> >
> > There is no reason why a QA team couldn't specifically target new
> > packages to the distribution as seen through updates-testing to ensure
> > proper functionality on a disparate set of hardware/software
> > configurations.  To just blanket claim that it won't happen is laughable.
> >  We've never done this for Extras, and in Core it was very very difficult
> > to get approval to introduce a new package.  Lets give it a try and see
> > what our growing QA team can come up with to make it worth while.
>
> Repeating myself, then first get such a QA time organized up and running
> and then, and only then, make updates-testing mandatory, if I get usefull
> feedback from this, you've won me over. But formulations like: "There is no
> reason why ...." to me actually read like: "today this serves no purpose
> other then to hinder you, but maybe in a future far away this will be
> actually usefull"
>
> Which results in me saying, fine, then when that future is upon us, do
> thinks like that, but not now.

What do you think Will Woods is trying to do with his QA team?  Only he's 
being met with vehement abuse and refusal to participate.

>
> > That is if you even care about trying to maintain a stable release for
> > users.   I know I do.
>
> There is no reason to suggest that I do not promote stability, see my many
> attempts to start a bug fixing squad (not triaging but actual fixing) and
> my many offers of help with bugs.
>
> > *cough* The review is for rawhide, where the platform could be
> > drastically different than that of a stable tree.  Just saying something
> > worked on rawhide and expecting it to work on previous release, or
> > previous release -1 is obtuse.
>
> Not true many reviewers review on the latest stable, it says nowhere that a
> review should be done on rawhide.

Yet the only place the package is allowed to go by default is rawhide, so it 
most certainly should be tested on rawhide.


> > So you're using one corner case package set with a limited user base to
> > throw out the entire idea of getting some larger audience testing on new
> > packages to a stable release.  Sounds like a great argument to me...
>
> A niche package which requires specific domain knowledge to test is not a
> corner case, there are many many niche packages in Fedora and more being
> added every day. Also there is this thing called libraries, which cannot be
> tested without apps using them, but which very well can be packaged and
> published without apps, be it for future use by planned apps, or for use by
> some non Fedora distributabe apps.

If you have a stack, the entire stack could be issued as an update at once (as 
soon as Luke gets that feature into Bodhi) so the entire stack can be tested 
at once.

And there are going to be reasonable exceptions to the rule, I completely see 
this.  However exceptions are not a reason to completely ignore the rule for 
every single package.

> ---
>
> All I'm asking for is to leaving this to the packagers discretion, isn't
> Fedora supposed to be all about freedom? Then why put me in a straight
> jacket.

Perhaps we have a communication issue.  Can you show me where it is stated 
that every single new package absolutely must without any question go through 
updates-testing first, without exception?

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070601/9fed6996/attachment.sig>