Daily package ownership changes?
kevin at scrye.com
Tue May 28 19:17:44 UTC 2013
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
> 1) review reports - was absent for a long time and is now being done
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel