Daily package ownership changes?

Adam Williamson awilliam at redhat.com
Wed May 29 02:12:04 UTC 2013


On Tue, 2013-05-28 at 13:17 -0600, Kevin Fenzi wrote:

> > 2) e-v-r problems  - sporadic reports
> 
> Should also add this, although, it actually could be a check done in
> the new wonderful QA setup. 

We already in fact do an 'upgradepath' check in AutoQA. It frequently
fails. Maintainers can sign themselves up for notifications of this test
failing on their builds.

http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=upgradepath

it tests that the build does not break the upgrade path from previous
releases or to later releases.

> > 3) reports on source url which don't work - havent been done in a
> > llong time afaik and needs to be automated and way to silence them in
> > known cases in a per package way (by checking in a file into the git
> > repo for that package for instance)
> 
> I've not done these in a long time yeah... again this could be
> something for a QA check when a spec file changes. 

You'd want to run it periodically even when the spec file doesn't
change, because upstream sites die or change.

> > 4) rpmlint reports could be collected in a central location and per 
> > package way to silence irrelevant warnings/errors could be added.
> > refer to debian lintian site for some examples
> 
> QA check on spec change. 

We already do it:

http://autoqa.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=rpmlint

> > 5) update to new upstream versions in Rawhide - a tool could do bump
> > the spec,  do scratch builds automatically of newer versions, if that
> > works ask the maintainer to apply a diff after reviewing the changes.
> 
> I suppose. It doesn't seem like it's that hard for a maintainer to
> notice this and do that if thats all thats involved. 

We already have the upstream release monitoring system (mentioned below)
for checking for new upstream versions and notifying maintainers; again
you have to sign yourself up for this for your own packages. There are
also helper scripts for doing a simple version bump and rebuild
available and commonly used (though personally I always do it
manually...I like to stay in touch with my specs :>)

> > 11) automatic period rebuilds in rawhide to highlight FTBFS issues 
> > aren't done as often anymore
> 
> Can you expand on this? Not sure what you mean?

IIRC, Matt Domsch used to run such tests semi-regularly. These days we
usually do one mass rebuild per release.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the devel mailing list