On Tue, 28 May 2013 14:58:35 -0400 Rahul Sundaram <metherid@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
