On 03/09/2010 02:10 PM, Bill Nottingham wrote:
> Matthew Garrett (mjg59@xxxxxxxxxxxxx) said:
>> Introduction
>> ------------
>>
>> We assume the following axioms:
>>
>> 1) Updates to stable that result in any reduction of functionality to
>> the user are unacceptable.
>>
>> 2) It is impossible to ensure that functionality will not be reduced
>> without sufficient testing.
>>
>> 3) Sufficient testing of software inherently requires manual
>> intervention by more than one individual.
>
> I agree with the sentiments here.
>
>> Proposal
>> --------
>>
>> The ability for maintainers to flag an update directly into the updates
>> repository will be disabled. Before being added to updates, the package
>> must receive a net karma of +3 in Bodhi.
>
> However, I do wonder about some of the concerns about this being
> a requirement for all packages. So, here's a counter-proposal/expansion.
> If need be, each of these policies could be considered separately, although
> they do stack on each other.
>
> ....
>
> Proposal
> --------
>
> For a package to be pushed to the stable updates repository, it must
> meet the following criteria.
>
> 1) All updates (even security) must pass AutoQA tests.
>
> Rationale: If a package breaks dependencies, does not install, or
> fails other obvious tests, it should not be pushed. Period. Obviously,
> this proposal would not be enacted until AutoQA is live.
>
> 2) Updates that constitute a part of the 'important' package set (defined
> below) must follow the rules as defined for critical path packages for
> pending releases, meaning that they require positive karma from releng
> and/or QA before they go stable. This also includes security updates for
> these packages.
>
> The 'important' package set is defined as the following:
> - The current critical path package set
> - All major desktop environments' core functionality (GNOME, KDE, XFCE,
> LXDE)
> - Package updating frameworks (gnome-packagekit, kpackagekit)
> - Major desktop productivity apps. An initial list would be firefox,
> kdebase (konqueror), thunderbird, evolution, kdepim (kmail).
>
> Rationale: These are the sets of packages where regressions most affect
> users, and would most prevent them from Getting Their Work Done.
> Furthermore, while I can accept that there may be some packages in Fedora that
> cannot find a significant enough testing base for all potential updates, I
> reject the notion that any desktop widely used enough that we deploy a
> image or spin for it would fit into that category. I accept that this places a
> larger burden on QA, and would expect them to be able to contribute testing
> to this initiative.
>
> 3) All other non-security updates must either:
>
> a) reach their specified bodhi karma threshold
> b) spend some minimum amount of time in updates-testing, with a tracked
> number of downloads.
>
> Proposed time would be one week, but is open to negotiation.
>
> Rationale: We do want additional eyes on updates wherever possible. We do
> have one Fedora mirror that Fedora infrastructure controls; we should
> be able to mine this server for data on updates-testing downloads.
>
> Any update that wants to bypass these procedures would need majority
> approval from FESCo.
>
> ....
>
> Comments, questions, reasoned arguments? Part of me wonders if this should be
> expanded with a sliding scale for update types (enhancements, for example, get
> more stringent treatment than bugfix/security).
If it's not critpath, and it passes AutoQA, then let it go straight to
stable. There are those updates that don't need a bunch of testing.
But, by defining the critpath set, and requiring positive feedback on
critpath packages, you have covered our users asses on the really
important packages. By having autoqa in place, you've covered the vast
majority of brown paper bag problems on all packages, not just critpath.
For non critpath packages, the brown paper bag stuff is all we really
need to mandate I think.
As an example, I pushed an update direct to stable a couple weeks ago.
It was to fix a bug in an init script where my use of:
udevtrigger
udevsettle
resulted in just some deprecation warnings from udev. I replaced those
calls to calls of udevadm trigger and udevadm settle and then tested
that A) the noise was gone and B) they still worked. I tested this on
all releases before building. And that was the *only* change that I
made. This update did not deserve to go through testing, it was
pretested. I would have appreciated an autoqa check to verify that
nothing in the build system broken the new package (maybe a dep change
or something), but really the changes of even that were extremely remote
at best. So, I can see where some changes simply don't warrant a bunch
of strict rules. We can have these changes even in critpath packages,
but the whole point of critpath is that we've isolated a set of packages
that are so important that it's worth it to take a little extra time
just to make sure things are right.
So, I like the policy in as much as I like AutoQA and critpath requires
testing. But since you have both of those things, I think loosening up
and letting non-critpath packages do with just AutoQA is sufficient.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
