Re: Confusing SCM package request
On Wed, Sep 6, 2017 at 1:49 PM, Adam Williamsonwrote: > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
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. 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 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Wed, Sep 6, 2017 at 12:53 PM, Adam Williamsonwrote: > On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote: >> What you're catching by doing this forced delay is >> rushed reviews or laziness on the part of two people. > > Also *ignorance*, in the case of legally-not-allowed things. And it We have guidelines covering that. I don't really find it acceptable for a packager to be ignorant of it, and definitely not the reviewer. Certainly not the sponsors of the packager and reviewers. If our guidelines are sufficiently long or confusing enough that we still have people ignorant of this, then it highlights a problem with our guidelines. > also allows the folks doing the package reviews to look for patterns > emerging (like a single packager continually submitting non-suitable > things, or a reviewer continually doing shoddy reviews) which can be > then be dealt with appropriately. 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? If we have problems with our guidelines, sponsor process, and continuation of both of those then lets fix those. Don't make SCM admins accountable for it. That doesn't make sense and I simply don't agree that forcing additional human delay here is worthwhile when it could be automated. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Wed, 2017-09-06 at 09:53 -0700, Adam Williamson wrote: > On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote: > > What you're catching by doing this forced delay is > > rushed reviews or laziness on the part of two people. > > Also *ignorance*, in the case of legally-not-allowed things. And it > also allows the folks doing the package reviews erf. I meant 'folks doing the SCM requests'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote: > What you're catching by doing this forced delay is > rushed reviews or laziness on the part of two people. Also *ignorance*, in the case of legally-not-allowed things. And it also allows the folks doing the package reviews to look for patterns emerging (like a single packager continually submitting non-suitable things, or a reviewer continually doing shoddy reviews) which can be then be dealt with appropriately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Wed, Sep 6, 2017 at 12:15 PM, Kevin Fenziwrote: > On 09/02/2017 07:09 AM, Pierre-Yves Chibon wrote: >> On Tue, Aug 29, 2017 at 07:48:47AM -0400, Neal Gompa wrote: >>> On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser >>> wrote: Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones: > > I'm trying to import this package into Fedora: > >https://bugzilla.redhat.com/show_bug.cgi?id=1174036 > > I went through the new process as far as I can tell and the tool just > filed a bug and printed out the URL of the bug: > >$ fedrepo-req -t 1174036 ocaml-re >https://pagure.io/releng/fedora-scm-requests/issue/596 > > Do I have to wait for that request to be handled now? The > documentation seems to suggest that the branch should actually have > been created, but it is not. > > Rich. fedrepo-req currently files issues against `fedora-scm-requests` on Pagure. You can see those issues as a kind of queue, which gets manually processed several times a day by limb (or other scm-admins). The process still is the same as it used to be, just the tooling and some technical implementations have changed. >>> >>> I don't get why this isn't automated yet... We seem to be stepping >>> closer to it without actually doing it... >> >> We are but so far releng asked that this is not fully automated, so we would >> have to bring it to them if we want to change this. > > We use this as a final check by a human. > > When I was doing all these requests a few years ago, I definitely caught > packages that were not legally allowed or had a shoddy review at this step. > > We can't catch everything of course, but having a trusted person check > on the two people adding a package (submittor/reviewer) is still well > worth the short delay IMHO. I don't. Your reasoning isn't wrong, but it falls down very quickly when you take into account that there is 0 on-going review on packages. All it takes for someone to do a decent enough job on the initial review to get a package in, and then they can muck about as much as they want. What you're catching by doing this forced delay is rushed reviews or laziness on the part of two people. That's not bad, but I'm not convinced it's worth not automating. You implicitly trust the reviewer and sponsors already anyway. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On 09/02/2017 07:09 AM, Pierre-Yves Chibon wrote: > On Tue, Aug 29, 2017 at 07:48:47AM -0400, Neal Gompa wrote: >> On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser >>wrote: >>> Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones: I'm trying to import this package into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1174036 I went through the new process as far as I can tell and the tool just filed a bug and printed out the URL of the bug: $ fedrepo-req -t 1174036 ocaml-re https://pagure.io/releng/fedora-scm-requests/issue/596 Do I have to wait for that request to be handled now? The documentation seems to suggest that the branch should actually have been created, but it is not. Rich. >>> >>> >>> fedrepo-req currently files issues against `fedora-scm-requests` on Pagure. >>> You can see those issues as a kind of queue, which gets manually processed >>> several times a day by limb (or other scm-admins). >>> >>> The process still is the same as it used to be, just the tooling and some >>> technical implementations have changed. >>> >> >> I don't get why this isn't automated yet... We seem to be stepping >> closer to it without actually doing it... > > We are but so far releng asked that this is not fully automated, so we would > have to bring it to them if we want to change this. We use this as a final check by a human. When I was doing all these requests a few years ago, I definitely caught packages that were not legally allowed or had a shoddy review at this step. We can't catch everything of course, but having a trusted person check on the two people adding a package (submittor/reviewer) is still well worth the short delay IMHO. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Tue, Aug 29, 2017 at 07:48:47AM -0400, Neal Gompa wrote: > On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser >wrote: > > Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones: > >> > >> I'm trying to import this package into Fedora: > >> > >>https://bugzilla.redhat.com/show_bug.cgi?id=1174036 > >> > >> I went through the new process as far as I can tell and the tool just > >> filed a bug and printed out the URL of the bug: > >> > >>$ fedrepo-req -t 1174036 ocaml-re > >>https://pagure.io/releng/fedora-scm-requests/issue/596 > >> > >> Do I have to wait for that request to be handled now? The > >> documentation seems to suggest that the branch should actually have > >> been created, but it is not. > >> > >> Rich. > > > > > > fedrepo-req currently files issues against `fedora-scm-requests` on Pagure. > > You can see those issues as a kind of queue, which gets manually processed > > several times a day by limb (or other scm-admins). > > > > The process still is the same as it used to be, just the tooling and some > > technical implementations have changed. > > > > I don't get why this isn't automated yet... We seem to be stepping > closer to it without actually doing it... We are but so far releng asked that this is not fully automated, so we would have to bring it to them if we want to change this. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esserwrote: > Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones: >> >> I'm trying to import this package into Fedora: >> >>https://bugzilla.redhat.com/show_bug.cgi?id=1174036 >> >> I went through the new process as far as I can tell and the tool just >> filed a bug and printed out the URL of the bug: >> >>$ fedrepo-req -t 1174036 ocaml-re >>https://pagure.io/releng/fedora-scm-requests/issue/596 >> >> Do I have to wait for that request to be handled now? The >> documentation seems to suggest that the branch should actually have >> been created, but it is not. >> >> Rich. > > > fedrepo-req currently files issues against `fedora-scm-requests` on Pagure. > You can see those issues as a kind of queue, which gets manually processed > several times a day by limb (or other scm-admins). > > The process still is the same as it used to be, just the tooling and some > technical implementations have changed. > I don't get why this isn't automated yet... We seem to be stepping closer to it without actually doing it... -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Confusing SCM package request
Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones: I'm trying to import this package into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1174036 I went through the new process as far as I can tell and the tool just filed a bug and printed out the URL of the bug: $ fedrepo-req -t 1174036 ocaml-re https://pagure.io/releng/fedora-scm-requests/issue/596 Do I have to wait for that request to be handled now? The documentation seems to suggest that the branch should actually have been created, but it is not. Rich. fedrepo-req currently files issues against `fedora-scm-requests` on Pagure. You can see those issues as a kind of queue, which gets manually processed several times a day by limb (or other scm-admins). The process still is the same as it used to be, just the tooling and some technical implementations have changed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Confusing SCM package request
I'm trying to import this package into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1174036 I went through the new process as far as I can tell and the tool just filed a bug and printed out the URL of the bug: $ fedrepo-req -t 1174036 ocaml-re https://pagure.io/releng/fedora-scm-requests/issue/596 Do I have to wait for that request to be handled now? The documentation seems to suggest that the branch should actually have been created, but it is not. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org