On Tue, 28 May 2013 14:58:35 -0400
Rahul Sundaram <metherid(a)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