On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers <[email protected]> wrote: > Honestly, setting up a tracker and blocking it with bugs about packages > which someones-sub-SLOT-checking-script has vetted to be involved could > be done in less than a day (for the hundred or so packages that depend > on dev-libs/libgcrypt). It doesn't need some QA team to study in depth > -- it needs a couple of volunteers to do the checks and file the bug > reports.
Honestly, it would be best to coordinate this with QA. QA isn't just about taking away commit rights in punishment for your sins. Scripts to help make devs aware of potential improvements should be a part of QA as well. And that isn't saying that you have to be on the QA team in order to do this either. If this sort of thing interests anybody, just ping them. I know QA is interested in improving the use of slot operator dependencies, because they've said as much on their irc channel... My script for spotting opportunities to use slot op deps is still out there. Of course, I wouldn't just "fix" any ebuild that comes up as there are situations where it isn't appropriate. What would probably make sense is for QA to define a var for ebuilds to set when they've been screened and found to be false positives, and then suppress them from the output. I'm all for nudging maintainers to add slot op deps when they make sense, or allowing others to do the work for them as long as they exercise reasonable care. Ebuilds don't belong to maintainers, but we should work with them whenever possible so that they're in a position to spot issues and deal with them. Rich
