Daily package ownership changes?

[Kevin Fenzi]

On Tue, 28 May 2013 14:58:35 -0400
Rahul Sundaram <metherid at gmail.com> wrote:

> This is a easily solvable problem.  pkgdb can just require the 
> maintainer to specify the reason for orphaning and the report can 
> collect that info and post it here There are lots of things we could 
> improve by just making reports more widely available automatically
> and some requires more tooling and we are doing a fairly poor job
> currently.
>
> 1) review reports - was absent for a long time and is now being done 
> manually

This can/will be added as a cron job. 

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

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

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

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

> 6) abi bumps could trigger rebuilds as needed automatically by the 
> buildsystem. Several distributions including Mageia, Mandriva,
> openSUSE has been doing this for ages already

This would take some work as it needs to have ability to do official
builds and checkins and such. 

> 7) spec file changelog vs git changelog could be automated and has
> been discussed multiple times here and again done by multiple
> distributions 

Sure, I don't think it's really a big deal either way personally. 

> 8) koji web ui needs to be improved significantly or
> dropped/replaced with something that provides more functionality

Feel free to help koji upstream out. 
What items do you see needing in the web ui?

> 9) reports highlighting unfixed security issues

This is a good one, we should do now if there are interested folks. 
Generate a list of all unfixed CVE bugs. 

> 10) https://fedoraproject.org/wiki/Upstream_release_monitoring should 
> ideally be done for *all* packages and maintainers should be able to
> opt in for notification or see it in a web UI as per their choice

Sure, although it won't work for those places that no longer offer
release downloads (github, etc)

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

> 12) file dependencies can be checked to make sure they are sane

You mean, just that the file exists in repodata? Or?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130528/e7156f9f/attachment.sig>