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, 07:13 PM
Al Dunsmuir
 
Default Proposed udpates policy change

On Tuesday, March 9, 2010, 2:10:04 PM, Bill Nottingham wrote:
> 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.

This is a sane approach.

One problem with immediate implementation would be that all packages,
no matter how insignificant would need to have tests that could be
run. Some packages in categories such as firmware or cross-compilation
tools would require specialized hardware to test fully as part of the
build or subsequent AutoQA testing.

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

Also sane.

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

Again, sanity.

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

I think you need to separate enhancements/etc to core components from
those for lower risk packages.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:13 PM
Al Dunsmuir
 
Default Proposed udpates policy change

On Tuesday, March 9, 2010, 2:49:00 PM, Dan Horák wrote:
> 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

I liked the visual presentation of download stats that Adam reference.
It may have been Ubuntu or Debian related.

I would like a tool that would present the list of installed packages,
and allow one to subscribe based on that. Also, bringing it up a
level to comps might reduce the user time. Perhaps basing the
testing of dependent package testing based on the owning packages
would simplify things too.

Al

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

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

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

I've thrown together an extremely quick-n-dirty combination of Bill's
proposal and Kamil's here:

https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy

the wording is very rough, but I hope it's good enough to form a basis
for discussion.
--
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, 07:20 PM
Adam Williamson
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 15:13 -0500, Al Dunsmuir wrote:

> > 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.
>
> This is a sane approach.
>
> One problem with immediate implementation would be that all packages,
> no matter how insignificant would need to have tests that could be
> run. Some packages in categories such as firmware or cross-compilation
> tools would require specialized hardware to test fully as part of the
> build or subsequent AutoQA testing.

What Bill's talking about when he refers to 'autoqa tests' are generic
tests which are concerned with package quality, not really the software
in the package: stuff like do the dependencies work, are there any clear
errors in the file lists. They can be run on any RPM package, the
software in the package doesn't really matter.
--
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, 07:28 PM
Al Dunsmuir
 
Default Proposed udpates policy change

On Tuesday, March 9, 2010, 3:20:25 PM, Adam Willamson wrote:

> On Tue, 2010-03-09 at 15:13 -0500, Al Dunsmuir wrote:

>> > 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.
>>
>> This is a sane approach.
>>
>> One problem with immediate implementation would be that all packages,
>> no matter how insignificant would need to have tests that could be
>> run. Some packages in categories such as firmware or cross-compilation
>> tools would require specialized hardware to test fully as part of the
>> build or subsequent AutoQA testing.

> What Bill's talking about when he refers to 'autoqa tests' are generic
> tests which are concerned with package quality, not really the software
> in the package: stuff like do the dependencies work, are there any clear
> errors in the file lists. They can be run on any RPM package, the
> software in the package doesn't really matter.
> --
> Adam Williamson

That makes sense.

How about things like rpmlint? Perhaps that would have caught the
bind/dnssec problems where user configs were directly rewritten
without backup to rpmnew files.

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

On Tue, 2010-03-09 at 15:28 -0500, Al Dunsmuir wrote:

> > What Bill's talking about when he refers to 'autoqa tests' are generic
> > tests which are concerned with package quality, not really the software
> > in the package: stuff like do the dependencies work, are there any clear
> > errors in the file lists. They can be run on any RPM package, the
> > software in the package doesn't really matter.

> That makes sense.
>
> How about things like rpmlint? Perhaps that would have caught the
> bind/dnssec problems where user configs were directly rewritten
> without backup to rpmnew files.

We have a tool called 'rpmguard' which is more or less a cousin of
rpmlint that looks at the differences between two versions of a package
and flags up critical changes. That's what will be implemented in AutoQA
and used at this 'test point'. See
https://fedorahosted.org/autoqa/wiki/rpmguard .
--
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, 07:36 PM
Krzysztof Halasa
 
Default Proposed udpates policy change

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> 2) It is impossible to ensure that functionality will not be reduced
> without sufficient testing.

True.

> 3) Sufficient testing of software inherently requires manual
> intervention by more than one individual.

Definitely. IOW, the testing is never sufficient.

> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.

That means any and all updates are unacceptable.
--
Krzysztof Halasa
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:48 PM
Al Dunsmuir
 
Default Proposed udpates policy change

Hello Krzysztof,

Tuesday, March 9, 2010, 3:36:43 PM, you wrote:

> Matthew Garrett <mjg59@srcf.ucam.org> writes:

>> 2) It is impossible to ensure that functionality will not be reduced
>> without sufficient testing.

> True.

The whole point of an update may be the deliberate removal of
features/functionality. This includes removal of elements whose
upstream is dead, removal of conflicts between packages, conversion of
static/copied libraries to the system provided library, removal of
features which are irretrievably broken, and those elements which do
not fit within Fedora's licence/mission (mp3 support, or patented
material).

>> 3) Sufficient testing of software inherently requires manual
>> intervention by more than one individual.

> Definitely. IOW, the testing is never sufficient.

Any nontrivial piece of software contains bugs until it reaches
end-of-life. This is a simple fact of life.

You can't test quality into a product like Fedora. You can only
attempt to assist developers in discovering issues that have escaped
their unit tests, so that through iterations of design/code/test the
package becomes stable and feature complete. It takes many iterations,
across many releases for some packages.

>> 1) Updates to stable that result in any reduction of functionality to
>> the user are unacceptable.

An absolute rule containing "any" ignores reality.

> That means any and all updates are unacceptable.
> --
> Krzysztof Halasa

The opposite of change is death. No updates as a hard and fast rule
would drive many users and packages away from Fedora.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:50 PM
Krzysztof Halasa
 
Default Proposed udpates policy change

Ralf Corsepius <rc040203@freenet.de> writes:

> => All you're going to see is further bureaucracy and bureaucratic
> overhead, but you'r not going to see better package quality.

Precisely. Who knows the package best? The packagers. If so why there
is someone else to decide (karma, the system, whoever)? This is insane.
The one with most info shall decide, simple. It's like voting that the
Sun rise twice a day.

If the maintainter makes mistake after mistake, esp. with an important
package, and everyone suffer, well just make him pay. Not all of the
maintainers.
--
Krzysztof Halasa
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 11:07 PM
Kevin Fenzi
 
Default Proposed udpates policy change

On Tue, 9 Mar 2010 10:04:22 +0100
Thomas Janssen <thomasj@fedoraproject.org> wrote:

...snip...

> By the way, is there some
> documentation on how to vote out particular FESCo members and who can
> do it? Just in case one thinks that a particular member of FESCo is
> wrongly voted in. Or is that like with politicians, once elcected you
> lost.
> Same question for Board members.

FESCo talked about this at todays meeting.

See right around:
http://meetbot.fedoraproject.org/fedora-meeting/2010-03-09/fesco.2010-03-09-20.00.log.html#l-800

and also see the Board policy:

https://fedoraproject.org/wiki/Board/SuccessionPlanning

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

Thread Tools




All times are GMT. The time now is 06:54 AM.

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