FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 06:01 PM
Luke Macken
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 01:48:42PM -0500, Jon Masters wrote:
> On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote:
>
> > I think a much better solution would be to require similar critical path
> > policies, across *all* releases, not just pending ones, while still
> > allowing non-critpath packages to go directly to stable.
>
> That is an acceptable fallback. But just for the record, I consider the
> critical path on my desktop to include not just kernel/udev/modules/etc.
> but also GNOME, cups, and other things I use each day.

Right, the critical path package list does contain the GNOME stack, cups-libs,
etc.

http://kojipkgs.fedoraproject.org/mash/rawhide-20100309/logs/critpath.txt

luke
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:02 PM
Adam Williamson
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 13:48 -0500, Jon Masters wrote:
> On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote:
>
> > I think a much better solution would be to require similar critical path
> > policies, across *all* releases, not just pending ones, while still
> > allowing non-critpath packages to go directly to stable.
>
> That is an acceptable fallback. But just for the record, I consider the
> critical path on my desktop to include not just kernel/udev/modules/etc.
> but also GNOME, cups, and other things I use each day. I don't
> personally care if KDE is updated 20 times a week, or about other
> packages that aren't installed by default being rebased often.

The current critical path does include most of that. You can see the
current critpath list at:

http://kojipkgs.fedoraproject.org/mash/rawhide-20100309/logs/critpath.txt

It's generated daily, it's not a static list. It does currently include
most of the important bits of GNOME, and cups-libs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:02 PM
Jesse Keating
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 13:48 -0500, Jon Masters wrote:
>
> That is an acceptable fallback. But just for the record, I consider
> the
> critical path on my desktop to include not just
> kernel/udev/modules/etc.
> but also GNOME, cups, and other things I use each day. I don't
> personally care if KDE is updated 20 times a week, or about other
> packages that aren't installed by default being rebased often.
>
>

http://kojipkgs.fedoraproject.org/mash/branched-20100308/logs/critpath.txt is the current critpath.

--
Jesse Keating
Fedora -- Freedom is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:07 PM
Josh Boyer
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 01:48:42PM -0500, Jon Masters wrote:
>On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote:
>
>> I think a much better solution would be to require similar critical path
>> policies, across *all* releases, not just pending ones, while still
>> allowing non-critpath packages to go directly to stable.
>
>That is an acceptable fallback. But just for the record, I consider the
>critical path on my desktop to include not just kernel/udev/modules/etc.
>but also GNOME, cups, and other things I use each day. I don't
>personally care if KDE is updated 20 times a week, or about other
>packages that aren't installed by default being rebased often.

http://koji.fedoraproject.org/mash/rawhide-20100309/logs/critpath.txt

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:10 PM
Bill Nottingham
 
Default Proposed udpates policy change

Matthew Garrett (mjg59@srcf.ucam.org) 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).

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:34 PM
Doug Ledford
 
Default Proposed udpates policy change

On 03/09/2010 02:10 PM, Bill Nottingham wrote:
> Matthew Garrett (mjg59@srcf.ucam.org) 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@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:40 PM
Adam Williamson
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 14:10 -0500, Bill Nottingham wrote:

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

I agree with the idea, but it should be better phrased. It's not the way
the test is implemented that matters, but what's being tested. The fact
that the test is done by AutoQA is really neither here nor there.

It would be safer to explicitly define the types of tests we want all
updates to pass: set out exactly what the 'obvious' hurdles every
package pushed should get over are (i.e. dependencies should be sane).
*How* we choose to test that is really just an implementation detail.

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

This feels broadly correct to me at present, and that's what I'll say at
the meeting if input from non-FESCo members is okay. I think Matt's
proposal is far too much of a leap at present; it may be true that we
can drive much more feedback in Bodhi than we currently get, but we
should prove that *before* we push a policy that relies on it happening,
not after. I know there's a potential chicken/egg problem there, but we
haven't even really tried very hard yet.

It also has other issues that have already been discussed, that are
mainly shortcomings in the current Bodhi process. As many have pointed
out (and QA has basically accepted), relying on a simple overall Bodhi
'score' is pretty unreliable at present, because we have no really good
process for defining what positive and negative Bodhi votes actually
mean. It's just not a robust enough process to make all updates depend
on getting a hard-defined overall Bodhi score at present. It can go
wrong in both directions; updates that shouldn't get pushed can get +3
(the obvious example being a kernel that boots fine for 7 people and
breaks for 3 would score +4), and updates that should get pushed might
not get +3.

Right now we should limit reliance on Bodhi to only critpath packages at
most, and even for that we do need to tighten up Bodhi procedures quite
urgently. And it shouldn't rely on an arbitrary combined
positive/negative score.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:43 PM
Matthew Garrett
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 02:10:04PM -0500, Bill Nottingham wrote:

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

How about every package that's installed by default in the primary
spins?

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

This seems pretty sane.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:43 PM
Jon Masters
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 14:01 -0500, Luke Macken wrote:
> On Tue, Mar 09, 2010 at 01:48:42PM -0500, Jon Masters wrote:
> > On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote:
> >
> > > I think a much better solution would be to require similar critical path
> > > policies, across *all* releases, not just pending ones, while still
> > > allowing non-critpath packages to go directly to stable.
> >
> > That is an acceptable fallback. But just for the record, I consider the
> > critical path on my desktop to include not just kernel/udev/modules/etc.
> > but also GNOME, cups, and other things I use each day.
>
> Right, the critical path package list does contain the GNOME stack, cups-libs,
> etc.
>
> http://kojipkgs.fedoraproject.org/mash/rawhide-20100309/logs/critpath.txt

So then great. I thought a lot of that was on there already, but didn't
have the link handy (bookmarked). Well then, to me, at least having a
very high bar on those would probably be sufficient for now at least.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:49 PM
Dan Horák
 
Default Proposed udpates policy change

Bill Nottingham p*še v Út 09. 03. 2010 v 14:10 -0500:
> Matthew Garrett (mjg59@srcf.ucam.org) 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).

Thanks Bill, this proposal is very similar to my "dump of ideas" posted
earlier today. The only thing I would like to improve (probably in
PackageKit) is the presentation of the content in updates-testing to the
users, to make it more visible and to encourage the testing. Something
like subscription to selected subset of packages that I want to be
notified about.


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:08 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org