updates improvements/changes ideas
jlaska at redhat.com
Mon Nov 29 18:44:02 UTC 2010
On Mon, 2010-11-29 at 19:04 +0100, Michael Schwendt wrote:
> On Mon, 29 Nov 2010 12:40:25 -0500, James wrote:
> > > * updates that only modify the spec could have a lower requirement.
> > > (ie, to fix a packaging issue, no changes in the upstream software).
> > All %obsoletes, %requires, %provides, %files and %patch statements are
> > only recorded in the .spec file. Just because they are in the .spec
> > file doesn't mean they are any less disruptive.
> True, but (1) it is considerably easier for a project like autoqa to catch
> bad deps/conflicts/obsoletes than (2) to catch software bugs introduced in
> a version upgrade. Plus (3) you don't want to do baby-sitting for
> packagers who are expected to know what they're doing wrt packaging.
Certainly, and we intend for autoqa to catch packaging snafus (1).
However, my point was that nasty things can happen by small changes to
the spec file. A small .spec file change doesn't necessary mean it
requires less testing. The change could be adding/removing patches or
altering the %build %install logic.
> > > Non critpath/security:
> > >
> > > * reduce timeout for non critpath from 7 to 3 days.
> > >
> > > * change default autokarma to 2 or 1.
> > No immediate thoughts on these points.
> Bodhi ought to make it impossible that the update submitter spends +1 on
> her own update. It has been abused already.
> And there ought to be an _enforced_ minimum number of days in
> updates-testing for certain packages. They need time to be picked up by
> the mirror-system. And testers need more time to become aware of new test
> updates and then spend additional time on evalulating the updates.
> It is completely useless if some testers _skip_ or shorten the
> updates-testing period by giving +1 for koji builds or within 24 hours.
> That is what has happened for a "mesa" update that hasn't seen sufficient
> testing due to the short time it was offered as a test-update:
Re: time - I've seen maintainers request test feedback for updates, but
the update wasn't pushed to 'updates-testing' yet. While pulling down
the update from koji is an option, this shouldn't be used for testing as
it bypasses the normal update mechanism and depending on what packages
are downloaded from koji, may not install all multilib packages.
So there is a lag time for mirrors to receive updates. Does anyone know
what that average time for mirrors to update is?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20101129/f3b27661/attachment.bin
More information about the test