On 05/15/2013 02:12 PM, Stanislav Ochotnicky wrote:
To play the devil's advocate a bit, if we automate it without requiring announce
we end up without any additional info about reasons why package was orphaned.
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
2) e-v-r problems - sporadic reports
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)
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
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.
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
7) spec file changelog vs git changelog could be automated and has been
discussed multiple times here and again done by multiple distributions
8) koji web ui needs to be improved significantly or dropped/replaced
with something that provides more functionality
9) reports highlighting unfixed security issues
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
11) automatic period rebuilds in rawhide to highlight FTBFS issues
aren't done as often anymore
12) file dependencies can be checked to make sure they are sane
I could go on but you get the general idea
Rahul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
