4:30 a.m.
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
4:36 a.m.
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.
6:48 a.m.
On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser
<besser82(a)fedoraproject.org> 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...
--
真実はいつも一つ！/ Always, there's only one truth!
2:13 p.m.
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
<besser82(a)fedoraproject.org> 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
11:15 a.m.
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
> <besser82(a)fedoraproject.org> 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
11:26 a.m.
On Wed, Sep 6, 2017 at 12:15 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
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
>> <besser82(a)fedoraproject.org> 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
11:53 a.m.
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
12:02 p.m.
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
12:14 p.m.
On Wed, Sep 6, 2017 at 12:53 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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
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
12:49 p.m.
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
2:15 p.m.
On Wed, Sep 6, 2017 at 1:49 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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
2433
days inactive
2441
days old
10 comments
7 participants
participants (7)
-
Adam Williamson -
Björn 'besser82' Esser -
Josh Boyer -
Kevin Fenzi -
Neal Gompa -
Pierre-Yves Chibon -
Richard W.M. Jones