On Wed, Sep 6, 2017 at 1:49 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 2017-09-06 at 13:14 -0400, Josh Boyer wrote: >> Taking your follow up of "folks doing the SCM requests" into account, >> I don't think that's what they signed up for? That's the job of a >> sponsor. >> >> However, you're just making cases for the easy to catch things and >> didn't address my point of 0 after-the-fact, on-going reviews taking >> place. If we are SO concerned with this up front, why are we >> completely unconcerned with it once a package is in? > > I wouldn't say we are, I'd just say we haven't figured out a good > process for it yet. But it's not fair to say 'completely unconcerned'; > for instance, a while ago someone ran a script checking for Flash > executables in packages and filed a bug on every package that contained > one which wasn't built from source. When major guideline changes > happen, there's sometimes a process to bring existing packages into > line (e.g. the ongoing effort to rename Python binary packages). It > *does* happen. We don't have a great, comprehensive process, but > 'completely unconcerned' is an overreach. We've been doing Fedora packaging in the current setup, with reviews and such, for many many years. We haven't even tried to address these problems systematically. At best we have someone doing a one-off script. If the Fedora project hasn't prioritized it and come up with a plan to solve it in all of these years, I do not think it is overreach to say the project is unconcerned. If you don't like that word, you could say it's low priority which is just a manager-y way of saying it is not a concern (speaking as a manager). > I'd also suggest that the two situations aren't really equivalent. > There's a higher chance of something being legally unsuitable for > Fedora *at the time it goes in* than it suddenly *becoming* legally > unsuitable later, with no-one noticing. The chance of the latter isn't > zero, but I'd say it's lower. I agree the chance lower, but I think it is much worse in severity. Much much worse. > I mean, if I slightly unfairly reduce it aggressively, your argument > seems to be "we're bad at doing stuff at point Y, so why not stop doing > it at point X too?" That seems an...odd way to 'solve' the problem. No, my point is "we're creating artificial bottlenecks and using up valuable human contributor time because our other processes are lacking, and that's preventing automating something that should already be accounted for by our review process". It's not exactly technical debt, but it's similar to it. It's process debt or something, and requiring SCM admins (of which there are few) to do that work is silly. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
