Auto-assign packager sponsors to tickets?

[Jakub Kadlčík]

Hello,

I've set myself a goal to improve the package review process. My first
step was creating https://docs.pagure.org/fedora-sponsors , I am
currently working on https://github.com/FrostyX/fedora-review-service
and contribute to the `fedora-review` tool. I have some ideas about
what to do next, and now I'd like to discuss one of them.

Currently, we have 31 people waiting to be sponsored
https://fedoraproject.org/PackageReviewStatus/needsponsor.html
many of them waiting for months. To get to the point of waiting to be
sponsored, all of these people invested their time to learn the basics
of RPM packaging and went through the tedious process of a package
review without quitting. It's not very nice of us to let them wait for
an indefinite amount of time without a reply after all of this.

I believe there is a technical solution to this problem, so I'd like
to write a script that would:

- Be run weekly
- Take a small number of active sponsors (say 5 of them, or maybe 10%
  of them) and give each of them one of the waiting tickets
- Technically, it would be done by setting NEEDINFO on the ticket
- If a sponsor was already given one ticket, he wouldn't get another
- It could prioritize sponsors who didn't get tickets for the longest
  time
- It could consider sponsors' interests
  https://docs.pagure.org/fedora-sponsors/interests

Additionally:

- If a sponsor is not able or willing to work on a ticket, they could
  either set NEEDINFO on another sponsor or just drop themselves. The
  ticket would then get a new sponsor next week
- After a month without a response to a NEEDINFO, another sponsor
  would be assigned

We currently have 37 active sponsors and 31 tickets waiting to be
sponsored, so the whole queue should get processed within a couple of
weeks and every sponsor should get only one ticket. After that I have
no idea how often will every sponsor be bothered. Maybe once a year?

What do you think? Would you be okay with a system like this?
Please forward to sponsors that you know, if there is no strong
disagreement, I'll proceed with the implementation.

Jakub

[Jakub Kadlcik]

Oh, and I forgot one important thing. Any sponsor that would disagree
with being assigned tickets this way would be able to opt out by
adding something like `auto_assign: false` to their sponsor.yaml
https://github.com/FrostyX/fedora-sponsors#b-your-personal-config-on-fedo...

Jakub

On Sat, Apr 1, 2023 at 11:17 PM Jakub Kadlčík <jkadlcik(a)redhat.com&gt; wrote:
>  Hello,
>
>  I've set myself a goal to improve the package review process. My first
>  step was creating https://docs.pagure.org/fedora-sponsors , I am
>  currently working on https://github.com/FrostyX/fedora-review-service
>  and contribute to the `fedora-review` tool. I have some ideas about
>  what to do next, and now I'd like to discuss one of them.
>
>  Currently, we have 31 people waiting to be sponsored
>  https://fedoraproject.org/PackageReviewStatus/needsponsor.html
>  many of them waiting for months. To get to the point of waiting to be
>  sponsored, all of these people invested their time to learn the basics
>  of RPM packaging and went through the tedious process of a package
>  review without quitting. It's not very nice of us to let them wait for
>  an indefinite amount of time without a reply after all of this.
>
>  I believe there is a technical solution to this problem, so I'd like
>  to write a script that would:
>
>  - Be run weekly
>  - Take a small number of active sponsors (say 5 of them, or maybe 10%
>    of them) and give each of them one of the waiting tickets
>  - Technically, it would be done by setting NEEDINFO on the ticket
>  - If a sponsor was already given one ticket, he wouldn't get another
>  - It could prioritize sponsors who didn't get tickets for the longest
>    time
>  - It could consider sponsors' interests
>    https://docs.pagure.org/fedora-sponsors/interests
>
>  Additionally:
>
>  - If a sponsor is not able or willing to work on a ticket, they could
>    either set NEEDINFO on another sponsor or just drop themselves. The
>    ticket would then get a new sponsor next week
>  - After a month without a response to a NEEDINFO, another sponsor
>    would be assigned
>
>  We currently have 37 active sponsors and 31 tickets waiting to be
>  sponsored, so the whole queue should get processed within a couple of
>  weeks and every sponsor should get only one ticket. After that I have
>  no idea how often will every sponsor be bothered. Maybe once a year?
>
>  What do you think? Would you be okay with a system like this?
>  Please forward to sponsors that you know, if there is no strong
>  disagreement, I'll proceed with the implementation.
>
>  Jakub

[Fabio Valentini]

On Sun, Apr 2, 2023 at 1:09 AM Jakub Kadlcik <jkadlcik(a)redhat.com&gt; wrote:
>  Oh, and I forgot one important thing. Any sponsor that would disagree
>  with being assigned tickets this way would be able to opt out by
>  adding something like `auto_assign: false` to their sponsor.yaml
>  https://github.com/FrostyX/fedora-sponsors#b-your-personal-config-on-fedo...
I'm not sure a "technical" solution is the best idea here.
Sponsoring someone into the "packager" group comes with a set of
responsibilities, and requires at least some amount of time to be
allocated to mentoring.
I don't think it's fair to expect that all sponsors are available to
do this at any time.

Fabio

[Vitaly Zaitsev]

On 01/04/2023 23:14, Jakub Kadlčík wrote:
>  Currently, we have 31 people waiting to be sponsored
>  https://fedoraproject.org/PackageReviewStatus/needsponsor.html
>  many of them waiting for months. 
If they wait for months, I think they don't want to be sponsored. I 
sponsored everyone who emailed me or asked in #fedora-devel.

>  I believe there is a technical solution to this problem 
I doubt.

>  What do you think? Would you be okay with a system like this? 
Please exclude me from such spam. I'm always willing to review and 
sponsor new maintainers, but they need to show explicit consent by 
posting on IRC/Matrix/ML or direct email.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miroslav Suchý]

Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>  I'm always willing to review and sponsor new maintainers, but
> they need to show explicit consent by posting on 
>  IRC/Matrix/ML or direct email.  
Let me check the history of

https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...

Right now we tell users to:

>  Usually, a sponsor finds you through your sponsorship request in
> Bugzilla or the packager sponsors pagure instance. In 
>  case you are waiting to be sponsored for longer than desirable, take a look at Sponsors
> page 
>  <https://docs.pagure.org/fedora-sponsors/>;. It will help you find the right sponsor
> for you based on programming 
>  language preference, domains of interest, native language, and other criteria. 
This
is not there for long time. Actually since 2021 when Jakub wrote that "Sponsor
page". Previously there was:

>  If you are submitting a new package for review in Bugzilla,
>  you can make the review request block the
>  https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] tracking bug.
>
>  Otherwise, you can file a ticket in the
>  https://pagure.io/packager-sponsors/[sponsors ticketing system]. 
So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR and wait. And
only if they wait too long 
(whatever it means) to start looking for sponsors directly.

I personally think that Jakub's proposal is great and I welcome it. Not everyone is
brave to initiate a conversation and 
asks for being sponsored. We have to realize it often means that junior developer has to
reach senior developer and 
juniors often hesitate to do this step. This proposal remove one road blocks for juniors.

If other people does not find it useful, then I propose to at least alter our
documentation and tell users to start 
looking for sponsor immediately after blocking FE-NEEDSPONSOR.

Miroslav

[Jakub Kadlcik]

>  If they wait for months, I think they don't want to be sponsored.
I respectfully disagree here, IMHO we communicate a message that a
sponsor will find the contributor, not the other way around. Just so I
don't repeat the same message in my own words, everything that
Miroslav said, sounds true to me.

>  Please exclude me from such spam. 
Sure, no problem with me. As I said in my initial proposal, I'd
provide an easy way to opt out (probably multiple ways, so it is
convenient for everybody).

>  I don't think it's fair to expect that all sponsors are
> available to do this at any time. 
Well sure, I agree. Mentoring somebody is a time commitment and nobody
has sponsoring people as the #1 priority. But as I said in the
proposal "If a sponsor is not able or willing to work on a ticket,
they could either set NEEDINFO on another sponsor or just drop
themselves. The ticket would then get a new sponsor next week" - to me
this sounds very reasonable.

Jakub

On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>
>  I'm always willing to review and sponsor new maintainers, but they need to show
> explicit consent by posting on IRC/Matrix/ML or direct email.
>
>  Let me check the history of
>
>   
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...
>
>  Right now we tell users to:
>
>  Usually, a sponsor finds you through your sponsorship request in Bugzilla or the packager
> sponsors pagure instance. In case you are waiting to be sponsored for longer than
> desirable, take a look at Sponsors page. It will help you find the right sponsor for you
> based on programming language preference, domains of interest, native language, and other
> criteria.
>
>  This is not there for long time. Actually since 2021 when Jakub wrote that "Sponsor
> page". Previously there was:
>
>  If you are submitting a new package for review in Bugzilla,
>  you can make the review request block the
>  https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] tracking bug.
>
>  Otherwise, you can file a ticket in the
>  https://pagure.io/packager-sponsors/[sponsors ticketing system].
>
>  So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR and wait. And
> only if they wait too long (whatever it means) to start looking for sponsors directly.
>
>  I personally think that Jakub's proposal is great and I welcome it. Not everyone is
> brave to initiate a conversation and asks for being sponsored. We have to realize it often
> means that junior developer has to reach senior developer and juniors often hesitate to do
> this step. This proposal remove one road blocks for juniors.
>
>  If other people does not find it useful, then I propose to at least alter our
> documentation and tell users to start looking for sponsor immediately after blocking
> FE-NEEDSPONSOR.
>
>  Miroslav
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jakub Kadlcik]

I tried to get some numbers to see how many packagers we sponsor each
year but FAS tells me only group members but not when they joined the
group. Do any of you at least have a rough estimate of what number are
we talking about? I wouldn't propose any auto-assign system for
package reviews because there is thousand of them each year. That
would be insane. But how many new contributors that need to be
sponsored do we have each year? My guess is that not even every
sponsor would get a ticket within the year.

Jakub

On Sun, Apr 2, 2023 at 5:07 PM Jakub Kadlcik <jkadlcik(a)redhat.com&gt; wrote:
>  > If they wait for months, I think they don't want to be sponsored.
>
>  I respectfully disagree here, IMHO we communicate a message that a
>  sponsor will find the contributor, not the other way around. Just so I
>  don't repeat the same message in my own words, everything that
>  Miroslav said, sounds true to me.
>
>  > Please exclude me from such spam.
>
>  Sure, no problem with me. As I said in my initial proposal, I'd
>  provide an easy way to opt out (probably multiple ways, so it is
>  convenient for everybody).
>
>  > I don't think it's fair to expect that all sponsors are available to do this
> at any time.
>
>  Well sure, I agree. Mentoring somebody is a time commitment and nobody
>  has sponsoring people as the #1 priority. But as I said in the
>  proposal "If a sponsor is not able or willing to work on a ticket,
>  they could either set NEEDINFO on another sponsor or just drop
>  themselves. The ticket would then get a new sponsor next week" - to me
>  this sounds very reasonable.
>
>  Jakub
>
>  On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  >
>  > Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>  >
>  > I'm always willing to review and sponsor new maintainers, but they need to show
> explicit consent by posting on IRC/Matrix/ML or direct email.
>  >
>  > Let me check the history of
>  >
>  >  
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...
>  >
>  > Right now we tell users to:
>  >
>  > Usually, a sponsor finds you through your sponsorship request in Bugzilla or the
> packager sponsors pagure instance. In case you are waiting to be sponsored for longer than
> desirable, take a look at Sponsors page. It will help you find the right sponsor for you
> based on programming language preference, domains of interest, native language, and other
> criteria.
>  >
>  > This is not there for long time. Actually since 2021 when Jakub wrote that
> "Sponsor page". Previously there was:
>  >
>  > If you are submitting a new package for review in Bugzilla,
>  > you can make the review request block the
>  > https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] tracking
> bug.
>  >
>  > Otherwise, you can file a ticket in the
>  > https://pagure.io/packager-sponsors/[sponsors ticketing system].
>  >
>  > So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR and
> wait. And only if they wait too long (whatever it means) to start looking for sponsors
> directly.
>  >
>  > I personally think that Jakub's proposal is great and I welcome it. Not everyone
> is brave to initiate a conversation and asks for being sponsored. We have to realize it
> often means that junior developer has to reach senior developer and juniors often hesitate
> to do this step. This proposal remove one road blocks for juniors.
>  >
>  > If other people does not find it useful, then I propose to at least alter our
> documentation and tell users to start looking for sponsor immediately after blocking
> FE-NEEDSPONSOR.
>  >
>  > Miroslav
>  >
>  >
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

Personally I'd not really like this solution.  For some sponsors which have
tons of time and can always take on people to mentor it will be great for
those folks.  For people who get "assigned" to sponsors that don't
necessarily have time and don't update their status to unavailable or
whatever at a given time it will be a bad experience for those seeking
sponsorship.

What about a mailing list for people seeking sponsorship to email into that
would go to all sponsors and the person seeking sponsorship could introduce
themselves, etc. and then available sponsors could perhaps chat back and
forth a bit in that list to find out if it might be a good fit for them.

As was mentioned, sponsorship requires a time commitment but it also needs
to be a good fit between two people for it to be fruitful when they work
together.

On Sun, Apr 2, 2023 at 10:34 AM Jakub Kadlcik <jkadlcik(a)redhat.com&gt; wrote:

>  I tried to get some numbers to see how many packagers we sponsor
> each
>  year but FAS tells me only group members but not when they joined the
>  group. Do any of you at least have a rough estimate of what number are
>  we talking about? I wouldn't propose any auto-assign system for
>  package reviews because there is thousand of them each year. That
>  would be insane. But how many new contributors that need to be
>  sponsored do we have each year? My guess is that not even every
>  sponsor would get a ticket within the year.
>
>  Jakub
>
>  On Sun, Apr 2, 2023 at 5:07 PM Jakub Kadlcik <jkadlcik(a)redhat.com&gt; wrote:
>  >
>  > > If they wait for months, I think they don't want to be sponsored.
>  >
>  > I respectfully disagree here, IMHO we communicate a message that a
>  > sponsor will find the contributor, not the other way around. Just so I
>  > don't repeat the same message in my own words, everything that
>  > Miroslav said, sounds true to me.
>  >
>  > > Please exclude me from such spam.
>  >
>  > Sure, no problem with me. As I said in my initial proposal, I'd
>  > provide an easy way to opt out (probably multiple ways, so it is
>  > convenient for everybody).
>  >
>  > > I don't think it's fair to expect that all sponsors are available to
>  do this at any time.
>  >
>  > Well sure, I agree. Mentoring somebody is a time commitment and nobody
>  > has sponsoring people as the #1 priority. But as I said in the
>  > proposal "If a sponsor is not able or willing to work on a ticket,
>  > they could either set NEEDINFO on another sponsor or just drop
>  > themselves. The ticket would then get a new sponsor next week" - to me
>  > this sounds very reasonable.
>  >
>  > Jakub
>  >
>  > On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  > >
>  > > Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>  > >
>  > > I'm always willing to review and sponsor new maintainers, but they
>  need to show explicit consent by posting on IRC/Matrix/ML or direct email.
>  > >
>  > > Let me check the history of
>  > >
>  > >
>
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...
>  > >
>  > > Right now we tell users to:
>  > >
>  > > Usually, a sponsor finds you through your sponsorship request in
>  Bugzilla or the packager sponsors pagure instance. In case you are waiting
>  to be sponsored for longer than desirable, take a look at Sponsors page. It
>  will help you find the right sponsor for you based on programming language
>  preference, domains of interest, native language, and other criteria.
>  > >
>  > > This is not there for long time. Actually since 2021 when Jakub wrote
>  that "Sponsor page". Previously there was:
>  > >
>  > > If you are submitting a new package for review in Bugzilla,
>  > > you can make the review request block the
>  > >
>  https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR]
>  tracking bug.
>  > >
>  > > Otherwise, you can file a ticket in the
>  > > https://pagure.io/packager-sponsors/[sponsors ticketing system].
>  > >
>  > > So previously - and even now - we tell newcomers to to block
>  FE-NEEDSPONSOR and wait. And only if they wait too long (whatever it means)
>  to start looking for sponsors directly.
>  > >
>  > > I personally think that Jakub's proposal is great and I welcome it.
>  Not everyone is brave to initiate a conversation and asks for being
>  sponsored. We have to realize it often means that junior developer has to
>  reach senior developer and juniors often hesitate to do this step. This
>  proposal remove one road blocks for juniors.
>  > >
>  > > If other people does not find it useful, then I propose to at least
>  alter our documentation and tell users to start looking for sponsor
>  immediately after blocking FE-NEEDSPONSOR.
>  > >
>  > > Miroslav
>  > >
>  > >
>  > > _______________________________________________
>  > > devel mailing list -- devel(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > > Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > > List Guidelines:
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > > List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  > > Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

[Jason Tibbitts]

> >>>> Jakub Kadlčík <jkadlcik(a)redhat.com&gt; writes:
>  Currently, we have 31 people waiting to be sponsored
>  https://fedoraproject.org/PackageReviewStatus/needsponsor.html many of
>  them waiting for months. To get to the point of waiting to be
>  sponsored, all of these people invested their time to learn the basics
>  of RPM packaging and went through the tedious process of a package
>  review without quitting. It's not very nice of us to let them wait for
>  an indefinite amount of time without a reply after all of this. 
I want state up front that I'm not a fan of this proposal, but I also
want to address what appears to me to be some misconception about the
process.  To wit: A sponsor doesn't have to do the package review, even
of tickets marked as NEEDSPONSOR.  That is just a flag in case sponsors
go specifically looking for people to sponsor.

If a package makes it through review but can't be imported because the
prospective maintainer isn't in the packager group, they should file a
ticket with the sponsors (https://pagure.io/packager-sponsors/) and they
will be taken care of.  I'm not aware of anyone in that state ever
needing to wait very long before being sponsored.  There are sponsors
who are willing to help with that part of things but who aren't able to
spend the time on package reviews.

So, really, the issue here is that the reviews in question aren't being
processed, not that sponsors aren't sponsoring.  Since any packager
can do those reviews, it seems that the proposal should instead be to
assign open package reviews to packagers, and I suspect that would not
be received particularly well for mostly the same reasons that sponsors
would object to the current proposal.

The bottom line is that package reviews can be quite time consuming.  I
don't think the issue is with sponsorship itself.

 - J<

[Miroslav Suchý]

Dne 03. 04. 23 v 18:24 Jason Tibbitts napsal(a):
>  If a package makes it through review but can't be imported
> because the
>  prospective maintainer isn't in the packager group, they should file a
>  ticket with the sponsors (https://pagure.io/packager-sponsors/) and they
>  will be taken care of. 
Again. This is not what we are telling them.

https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...

>    I'm not aware of anyone in that state ever
>  needing to wait very long before being sponsored. 
Is two years long enough?

https://bugzilla.redhat.com/show_bug.cgi?id=1958193

https://bugzilla.redhat.com/show_bug.cgi?id=1958190

And people are really confused / hesitant:

https://bugzilla.redhat.com/show_bug.cgi?id=2036288#c11

Miroslav

[Jason Tibbitts]

> >>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
>  Again. This is not what we are telling them. 
Again?  There's no need for that.

In any case, what I wrote was the procedure I documented it when I set
it up.  If all of that documentation was lost, then I don't know what to
say but that's not what was intended.

I drove the change that made this happen.  I made sure the documentation
(in the wiki at the time) referenced the procedure.  If that was lost
after the time when I was able to be very active in Fedora, then that's
a sad state of affairs and I don't know why that would happen, but it
would be really good if it could un-happen.  Did FESCo revert the policy
change or something?

> > I'm not aware of anyone in that state ever needing to wait
> very long
> > before being sponsored. 
>  Is two years long enough? 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1958193 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1958190 
You're saying that tickets were properly filed with the
packager-sponsors tracker and those were not addressed?  I checked the
open tickets before responding.  I didn't see anything.  If tickets got
closed without any action being taken, could you point out those
tickets?  That would be a rather odd state of affairs

>  And people are really confused / hesitant: 
>  https://bugzilla.redhat.com/show_bug.cgi?id=2036288#c11 
And how does this proposal help that?  Why not just propose to document
the actual process instead?

 - J<

[Miroslav Suchý]

Dne 03. 04. 23 v 19:09 Jason Tibbitts napsal(a):
>  > Again. This is not what we are telling them.
>  Again?  There's no need for that. 
I apologize. It was not my intention to sound harsh.


> > Is two years long enough?
> > https://bugzilla.redhat.com/show_bug.cgi?id=1958193
> > https://bugzilla.redhat.com/show_bug.cgi?id=1958190
>  You're saying that tickets were properly filed with the
>  packager-sponsors tracker and those were not addressed? 
No, I'm not saying
that. Somebody has enough courage to open the package review, discuss it, get to the point
that the 
package review was approved. But did not have the courage to reach sponsors. It was road
block for them. And it is quite 
common. We can study the road block, trying to describe the roadblock. Or we can simply
remove the road block and write 
the sponsors (me included) that here is an issue waiting for them.


>  And how does this proposal help that?  Why not just propose to
> document
>  the actual process instead? 
I filed https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/118#

But I think this is not outreachy enough.

Miroslav

[Jason Tibbitts]

> >>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
>  No, I'm not saying that. Somebody has enough courage to open the
>  package review, discuss it, get to the point that the package review
>  was approved. But did not have the courage to reach sponsors. It was
>  road block for them. 
That's an odd case, I suppose.  I have trouble understand how someone
could make it through all of that process and then not be able to ask
for one more thing, and I would tend to attribute most issues in that
area to process overload and lack of documentation.  But then, that
points out a possibility for automation: When the review flag gets set
to '+' on a NEEDSPONSOR bug, automatically alert the sponsors.  If this
can file the ticket at https://pagure.io/packager-sponsors/ then great;
otherwise there is a mailing list, though it's much easier to lose a
random list message.

I have no idea how to actually make that happen, unless bugzilla things
generate messages on the bus.

>  And it is quite common. 
I personally think it's far more common for someone to simply not be
available to do a package review; at least that's how it was when I was
actively doing reviews.  There are so many, and so much of the process
was placed on the reviewer that could easily be done by the submitter or
by automation.  (When I was doing it, a significant percentage of
package submissions wouldn't even build in mock.  Reviewing licenses and
eventually bundling took ages.)

>  Or we can simply remove the road block and write the sponsors (me
>  included) that here is an issue waiting for them. 
Sure, just plumb the end of the review process (accepted ticket) to feed
right into the sponsor process (let the sponsors know, preferably via
the tracker).  But I don't think that assigning unreviewed tickets to
random sponsors is the right way.  We (mostly) decoupled sponsorship
from the review process for a reason.  (We do still want sponsors to
have done at least a few reviews so we know that they are familiar.)

 - J<

[Kevin Fenzi]

On Mon, Apr 03, 2023 at 01:52:49PM -0500, Jason Tibbitts wrote:
>  >>>>> Miroslav Suchý <msuchy(a)redhat.com&gt;
> writes:
>  
>  > No, I'm not saying that. Somebody has enough courage to open the
>  > package review, discuss it, get to the point that the package review
>  > was approved. But did not have the courage to reach sponsors. It was
>  > road block for them.
>  
>  That's an odd case, I suppose.  I have trouble understand how someone
>  could make it through all of that process and then not be able to ask
>  for one more thing, and I would tend to attribute most issues in that
>  area to process overload and lack of documentation.  But then, that
>  points out a possibility for automation: When the review flag gets set
>  to '+' on a NEEDSPONSOR bug, automatically alert the sponsors.  If this
>  can file the ticket at https://pagure.io/packager-sponsors/ then great;
>  otherwise there is a mailing list, though it's much easier to lose a
>  random list message.
>  
>  I have no idea how to actually make that happen, unless bugzilla things
>  generate messages on the bus. 
It absoletely does. ;) 

https://apps.fedoraproject.org/datagrepper/raw?rows_per_pager=20&cate...

Someone could write a toddler that listens for those and acts on the
ones desired. Just like the current one that listens for scm requests.

kevin

[Jakub Kadlcik]

>  It absoletely does. ;) 
And it even allows us to retrospectively see how many packagers were
sponsored in the last month/year/...
https://gist.github.com/FrostyX/47defa18348fbb917e73d7b2e7660ca2

Fedora-messaging is awesome :-)

On Mon, Apr 3, 2023 at 10:33 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>
> On Mon, Apr 03, 2023 at 01:52:49PM -0500, Jason Tibbitts wrote:
> > >>>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
> >
> > > No, I'm not saying that. Somebody has enough courage to open the
> > > package review, discuss it, get to the point that the package review
> > > was approved. But did not have the courage to reach sponsors. It was
> > > road block for them.
> >
> > That's an odd case, I suppose.  I have trouble understand how someone
> > could make it through all of that process and then not be able to ask
> > for one more thing, and I would tend to attribute most issues in that
> > area to process overload and lack of documentation.  But then, that
> > points out a possibility for automation: When the review flag gets set
> > to '+' on a NEEDSPONSOR bug, automatically alert the sponsors.  If this
> > can file the ticket at https://pagure.io/packager-sponsors/ then great;
> > otherwise there is a mailing list, though it's much easier to lose a
> > random list message.
> >
> > I have no idea how to actually make that happen, unless bugzilla things
> > generate messages on the bus.
>
>  It absoletely does. ;) 
>
>
https://apps.fedoraproject.org/datagrepper/raw?rows_per_pager=20&cate...
>
> Someone could write a toddler that listens for those and acts on the
> ones desired. Just like the current one that listens for scm requests.
>
> kevin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Otto Liljalaakso]

Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:
> >>>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
>  
>  In any case, what I wrote was the procedure I documented it when I set
>  it up.  If all of that documentation was lost, then I don't know what to
>  say but that's not what was intended.
>  
>  I drove the change that made this happen.  I made sure the documentation
>  (in the wiki at the time) referenced the procedure.  If that was lost
>  after the time when I was able to be very active in Fedora, then that's
>  a sad state of affairs and I don't know why that would happen, but it
>  would be really good if it could un-happen.  Did FESCo revert the policy
>  change or something? 
Somewhat recently, the Packager sponsor policy [1] has been rewritten. 
The history is that moved content over from the wiki to the Package 
Maintainer Docs, then edited it to make things more clear. Later, I 
realized that what I edited was actually intended to be a FESCo-approved 
policy, just not clearly marked as such in the wiki and editable by 
anyone. So I went to FESCo to get the material officially approved - see 
the pull request [2].

The result of this is that it is currently a FESCo policy that for new 
packages, the sponsorship is requested by blocking the FE-NEEDSPONSOR 
Bugzilla, and for all other paths by filing a Pagure ticket. The reason 
why I wrote the pull request like that is that at that time, there was 
discussion about this on devel where I proposed using Pagure tickets for 
new packages also, but got negative feedback [3].

The gist of that negative feedback was "very few sponsors are looking at 
the Pagure tickets, we cannot process that many". From this thread I get 
the opposite impression, that Pagure tickets are processed quickly and 
FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy 
is updated to ask for a Pagure ticket in every case.

[1]: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
[2]: https://pagure.io/fesco/fesco-docs/pull-request/59
[3]: 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

[Jakub Kadlcik]

Thank you all for the feedback.

>  The bottom line is that package reviews can be quite time consuming. 
> I
>  don't think the issue is with sponsorship itself. 
Sorry Jason, I probably didn't communicate my idea as clearly as I
should. My intention wasn't to assign sponsors to review tickets and
make them do the actual review. I am trying to address the situation
where a ticket already has a fedora-review+ flag but it was given by a
reviewer who is not a sponsor.


>  You're saying that tickets were properly filed with the
>  packager-sponsors tracker and those were not addressed?  I checked the
>  open tickets before responding.  I didn't see anything.  If tickets got
>  closed without any action being taken, could you point out those
>  tickets?  That would be a rather odd state of affairs 
Not in the packager-sponsors tracker, I checked it out, and I must say
it is being processed flawlessly. Really good job there.
Reading the discussion, I think we discovered one of the main issues
elsewhere - We don't properly instruct new contributors to create a
ticket in the tracker.
This will be a big improvement:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/118

To point out the specific tickets that weren't addressed, they are here:
https://fedoraproject.org/PackageReviewStatus/needsponsor.html


>  But I think this is not outreachy enough. 
I agree, so my next step will be improving the fedora-review-service
to post a comment about how to find a sponsor, in case fedora-review+
flag was given by a non-sponsor. More info in this RFE:
https://github.com/FrostyX/fedora-review-service/issues/18


>  From this thread I get
>  the opposite impression, that Pagure tickets are processed quickly and
>  FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
>  is updated to ask for a Pagure ticket in every case. 
I get the same impression and I would agree with Otto's proposal to
get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
processed as effectively as the package-sponsor repo tickets, the
FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
the ticket doesn't need to be sponsored, the contributor does. That
becomes weird when the contributor has more tickets at the same time
and so on). But if I understand correctly, FESCo needs to be involved
and therefore this would be a long-term goal.


>  Please exclude me from such spam. 
I was finally able to find some numbers and it turns out, we
successfully sponsor ~100 people a year. That is much more than I
expected, so I now understand your point. We are also much more
effective than I thought (well you guys are).


>  Sure, just plumb the end of the review process (accepted ticket) to
> feed
>  right into the sponsor process (let the sponsors know, preferably via
>  the tracker).  But I don't think that assigning unreviewed tickets to
>  random sponsors is the right way. 
This can work and will be easy to implement as well. I like the idea,
we can try it :-)

Jakub



On Mon, Apr 3, 2023 at 11:57 PM Otto Liljalaakso
<otto.liljalaakso(a)iki.fi&gt; wrote:
>  Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:
>  >>>>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
>  >
>  > In any case, what I wrote was the procedure I documented it when I set
>  > it up.  If all of that documentation was lost, then I don't know what to
>  > say but that's not what was intended.
>  >
>  > I drove the change that made this happen.  I made sure the documentation
>  > (in the wiki at the time) referenced the procedure.  If that was lost
>  > after the time when I was able to be very active in Fedora, then that's
>  > a sad state of affairs and I don't know why that would happen, but it
>  > would be really good if it could un-happen.  Did FESCo revert the policy
>  > change or something?
>
>  Somewhat recently, the Packager sponsor policy [1] has been rewritten.
>  The history is that moved content over from the wiki to the Package
>  Maintainer Docs, then edited it to make things more clear. Later, I
>  realized that what I edited was actually intended to be a FESCo-approved
>  policy, just not clearly marked as such in the wiki and editable by
>  anyone. So I went to FESCo to get the material officially approved - see
>  the pull request [2].
>
>  The result of this is that it is currently a FESCo policy that for new
>  packages, the sponsorship is requested by blocking the FE-NEEDSPONSOR
>  Bugzilla, and for all other paths by filing a Pagure ticket. The reason
>  why I wrote the pull request like that is that at that time, there was
>  discussion about this on devel where I proposed using Pagure tickets for
>  new packages also, but got negative feedback [3].
>
>  The gist of that negative feedback was "very few sponsors are looking at
>  the Pagure tickets, we cannot process that many". From this thread I get
>  the opposite impression, that Pagure tickets are processed quickly and
>  FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
>  is updated to ask for a Pagure ticket in every case.
>
>  [1]: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
>  [2]: https://pagure.io/fesco/fesco-docs/pull-request/59
>  [3]:
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Benson Muite]

Thanks for this initiative Jakub. Automated builds on copr of packages
proposed for review has been very helpful.
On 4/4/23 03:59, Jakub Kadlcik wrote:
>  Thank you all for the feedback.
>  
> > The bottom line is that package reviews can be quite time consuming.  I
> > don't think the issue is with sponsorship itself.
>  
>  Sorry Jason, I probably didn't communicate my idea as clearly as I
>  should. My intention wasn't to assign sponsors to review tickets and
>  make them do the actual review. I am trying to address the situation
>  where a ticket already has a fedora-review+ flag but it was given by a
>  reviewer who is not a sponsor.
>  
>  
> > You're saying that tickets were properly filed with the
> > packager-sponsors tracker and those were not addressed?  I checked the
> > open tickets before responding.  I didn't see anything.  If tickets got
> > closed without any action being taken, could you point out those
> > tickets?  That would be a rather odd state of affairs
>  
>  Not in the packager-sponsors tracker, I checked it out, and I must say
>  it is being processed flawlessly. Really good job there.
>  Reading the discussion, I think we discovered one of the main issues
>  elsewhere - We don't properly instruct new contributors to create a
>  ticket in the tracker.
>  This will be a big improvement:
>  https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/118
>  
>  To point out the specific tickets that weren't addressed, they are here:
>  https://fedoraproject.org/PackageReviewStatus/needsponsor.html
>  
>  
> > But I think this is not outreachy enough.
>  
>  I agree, so my next step will be improving the fedora-review-service
>  to post a comment about how to find a sponsor, in case fedora-review+
>  flag was given by a non-sponsor. More info in this RFE:
>  https://github.com/FrostyX/fedora-review-service/issues/18
>   
The packager onboarding experience can be improved. Automation can help.
 If someone has submitted a new package review request and has not
submitted a package review request before, a bot that welcomes the
person and announces this on the devel list would encourage others to
take a look at the ticket.  There is a Fedora ambassador group, maybe
this could also be used?  It is good to increase active participation in
the project.  Am not a sponsor, but have reviewed packages of people
that need sponsorship.
>  
> > From this thread I get
> > the opposite impression, that Pagure tickets are processed quickly and
> > FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
> > is updated to ask for a Pagure ticket in every case.
>  
>  I get the same impression and I would agree with Otto's proposal to
>  get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
>  processed as effectively as the package-sponsor repo tickets, the
>  FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
>  the ticket doesn't need to be sponsored, the contributor does. That
>  becomes weird when the contributor has more tickets at the same time
>  and so on). But if I understand correctly, FESCo needs to be involved
>  and therefore this would be a long-term goal.
>  
Automating FE-NEEDSPONSOR is helpful for reviewers as one would
typically make more suggestions than for a regular review. Creating a
Pagure ticket after successful package review can then also help.  May
also want to automatically track unofficial reviews by prospective
packagers, perhaps even requiring a certain number of unofficial reviews
for the sponsorship process to start.

>  
> > Please exclude me from such spam.
>  
>  I was finally able to find some numbers and it turns out, we
>  successfully sponsor ~100 people a year. That is much more than I
>  expected, so I now understand your point. We are also much more
>  effective than I thought (well you guys are).
>  
>  
> > Sure, just plumb the end of the review process (accepted ticket) to feed
> > right into the sponsor process (let the sponsors know, preferably via
> > the tracker).  But I don't think that assigning unreviewed tickets to
> > random sponsors is the right way.
>  
>  This can work and will be easy to implement as well. I like the idea,
>  we can try it :-)
>  
>  Jakub
>  
>  
>  
>  On Mon, Apr 3, 2023 at 11:57 PM Otto Liljalaakso
>  <otto.liljalaakso(a)iki.fi&gt; wrote:
> >
> > Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:
> >>>>>>> Miroslav Suchý <msuchy(a)redhat.com&gt; writes:
> >>
> >> In any case, what I wrote was the procedure I documented it when I set
> >> it up.  If all of that documentation was lost, then I don't know what to
> >> say but that's not what was intended.
> >>
> >> I drove the change that made this happen.  I made sure the documentation
> >> (in the wiki at the time) referenced the procedure.  If that was lost
> >> after the time when I was able to be very active in Fedora, then that's
> >> a sad state of affairs and I don't know why that would happen, but it
> >> would be really good if it could un-happen.  Did FESCo revert the policy
> >> change or something?
> >
> > Somewhat recently, the Packager sponsor policy [1] has been rewritten.
> > The history is that moved content over from the wiki to the Package
> > Maintainer Docs, then edited it to make things more clear. Later, I
> > realized that what I edited was actually intended to be a FESCo-approved
> > policy, just not clearly marked as such in the wiki and editable by
> > anyone. So I went to FESCo to get the material officially approved - see
> > the pull request [2].
> >
> > The result of this is that it is currently a FESCo policy that for new
> > packages, the sponsorship is requested by blocking the FE-NEEDSPONSOR
> > Bugzilla, and for all other paths by filing a Pagure ticket. The reason
> > why I wrote the pull request like that is that at that time, there was
> > discussion about this on devel where I proposed using Pagure tickets for
> > new packages also, but got negative feedback [3].
> >
> > The gist of that negative feedback was "very few sponsors are looking at
> > the Pagure tickets, we cannot process that many". From this thread I get
> > the opposite impression, that Pagure tickets are processed quickly and
> > FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
> > is updated to ask for a Pagure ticket in every case.
> >
> > [1]: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
> > [2]: https://pagure.io/fesco/fesco-docs/pull-request/59
> > [3]:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 7.02:
>  Thanks for this initiative Jakub. Automated builds on copr of
> packages
>  proposed for review has been very helpful. 
I completely agree. Great work!

Benson Muite kirjoitti 4.4.2023 klo 7.02:
>  On 4/4/23 03:59, Jakub Kadlcik wrote:
> >
> >>  From this thread I get
> >> the opposite impression, that Pagure tickets are processed quickly and
> >> FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
> >> is updated to ask for a Pagure ticket in every case.
> >
> > I get the same impression and I would agree with Otto's proposal to
> > get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
> > processed as effectively as the package-sponsor repo tickets, the
> > FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
> > the ticket doesn't need to be sponsored, the contributor does. That
> > becomes weird when the contributor has more tickets at the same time
> > and so on). But if I understand correctly, FESCo needs to be involved
> > and therefore this would be a long-term goal. 
Actually, updating a FESCo policy is not difficult at all. Once the 
conversation settles down and there is a consensus on how the policy 
should be updated, just make a pull request for fesco-docs for it and 
file a FESCo issue asking FESCo to consider it. I would be very 
surprised if FESCo rejects it when it has been discussed in devel and 
the sponsors themselves back it.

Actually, in my experience, updating FESCo policies is often *easier* 
updating a random Fedora Docs page. FESCo has a documented process for 
handling tickets, and FESCo members actually do respond to them. For 
other docs, proposals for improvement sometimes get not reply at all, or 
get some comments but are neither merged nor rejected.

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 7.02:
>  May
>  also want to automatically track unofficial reviews by prospective
>  packagers, perhaps even requiring a certain number of unofficial reviews
>  for the sponsorship process to start. 
Yes, I think that the sponsorship process should be made more rigid, 
with at least somewhat formally defined requirements. Maybe something 
along the lines "do N unofficial package reviews AND submit M pull 
requests to packages and get them merged AND convince a sponsor". The 
current approach where "convince a sponsor" is the only actual 
requirement creates unfortunate bias:

1. The easiest way to get in is to know somebody who is already in. This 
is basically the opposite of how I understand "open community".

2. Applicants who find it easy to engage with unknown people in higher 
community standing and have high confidence in their abilities navigate 
the (ill-defined, unclear) process much easier than more cautious types. 
Such character traits are of course very useful when participating in 
open source communities, but discriminating other kinds of personality 
leads to fewer contributors and lost talent. And it is, well, 
discriminatory, thus not very ethical in my opinion.

Another thing that can be improved here is to make it much less 
necessary to even get packager status. Working with pull requests should 
be the norm. Perhaps new package requests could more often be handled in 
a way where an existing packager assumes the maintainer position with 
the agreement that the submitter keeps the packager updated and in good 
condition, through pull requests. The packager status should be just an 
optional thing you can apply at some point in your Fedora contributor 
career, *if* a situation demanding that occurs - much like packager 
sponsor, provenpackager or even FESCo member status is, or how in 
upstream projects there often are prominent contributors that take part 
in the conversation and submit pull requests, without any commit access.

[Vitaly Zaitsev]

On 04/04/2023 07:52, Otto Liljalaakso wrote:
>  Perhaps new package requests could more often be handled in a way
> where 
>  an existing packager assumes the maintainer position with the agreement 
>  that the submitter keeps the packager updated and in good condition, 
>  through pull requests. 
We have a serious problem here: non-packages can't upload sources to 
Fedora SCM.

These pull requests require maintainers to do it manually in a separate 
commit that breaks %autorelease+%autochangelog.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Kalev Lember]

On Tue, Apr 4, 2023 at 9:22 AM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 04/04/2023 07:52, Otto Liljalaakso wrote:
>  > Perhaps new package requests could more often be handled in a way where
>  > an existing packager assumes the maintainer position with the agreement
>  > that the submitter keeps the packager updated and in good condition,
>  > through pull requests.
>
>  We have a serious problem here: non-packages can't upload sources to
>  Fedora SCM.
>
>  These pull requests require maintainers to do it manually in a separate
>  commit that breaks %autorelease+%autochangelog.
>  
That's not exactly true. Yes, non-packagers can't upload files to the
lookaside cache, but they can update the 'sources' and '.gitignore' files
in git.

The easiest way to do that is with 'fedpkg new-sources --offline' which
then only does the local modifications that can be committed to git (and
submitted as a PR), but doesn't upload the files to the lookaside cache
servers.

-- 
Kalev

[Vitaly Zaitsev]

On 04/04/2023 09:36, Kalev Lember wrote:
>  That's not exactly true. Yes, non-packagers can't upload
> files to the 
>  lookaside cache, but they can update the 'sources' and '.gitignore' 
>  files in git. 
GitHub has stated[1] that they no longer guarantee hash stability 
between archive downloads.

We discussed this issue at #devel:fedoraproject.org[2] and everyone 
agreed that tarball format is not reproducible.

Thus, when the maintainer downloads the tarball using spectool, the 
hashes will not match.

[1]: 
https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/
[2]: 
https://matrix.to/#/!lbPXqyjXDnvnfogGYA:matrix.org/$Flv-5iRWTWeG9XYbH3p0j...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Kevin Fenzi]

On Tue, Apr 04, 2023 at 10:00:20AM +0200, Vitaly Zaitsev via devel wrote:
>  On 04/04/2023 09:36, Kalev Lember wrote:
>  > That's not exactly true. Yes, non-packagers can't upload files to the
>  > lookaside cache, but they can update the 'sources' and '.gitignore'
>  > files in git.
>  
>  GitHub has stated[1] that they no longer guarantee hash stability between
>  archive downloads. 
But then after a outcry... "We are reverting this change for now. More
details to follow."

kevin

[Vitaly Zaitsev]

On 04/04/2023 23:42, Kevin Fenzi wrote:
>  But then after a outcry... "We are reverting this change for
> now. More
>  details to follow." 
Yes, after a lot of negative feedback they (temporary?) reverted this 
change. Even their own vcpkg (package manager by Microsoft) uses these 
hashes to verify downloaded files.

They said that after each download of the git tag archive, its contents 
are permanently stored on the content server, and all subsequent 
downloads will be performed by it. It consumes a lot of disk space.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Jakub Kadlcik]

I want to thank you all for the feedback.

Everything was already mentioned in the discussion so I am not going
to dig into details again. Just a quick summary for anyone who wants
TL;DR for this thread:

- I am not going to implement the original proposal or any variation of it
- Instead, I am going to automatically open an issue in the
package-sponsors tracker for new contributors after they receive
fedora-review+ on their first ticket. A link to this issue along with
some explanation will be automatically commented to their package
review Bugzilla ticket.
- You can follow the progress here
https://github.com/FrostyX/fedora-review-service/issues/18

Jakub

On Wed, Apr 5, 2023 at 8:51 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 04/04/2023 23:42, Kevin Fenzi wrote:
>  > But then after a outcry... "We are reverting this change for now. More
>  > details to follow."
>
>  Yes, after a lot of negative feedback they (temporary?) reverted this
>  change. Even their own vcpkg (package manager by Microsoft) uses these
>  hashes to verify downloaded files.
>
>  They said that after each download of the git tag archive, its contents
>  are permanently stored on the content server, and all subsequent
>  downloads will be performed by it. It consumes a lot of disk space.
>
>  --
>  Sincerely,
>     Vitaly Zaitsev (vitaly(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Vitaly Zaitsev]

On 17/04/2023 17:53, Jakub Kadlcik wrote:
>  - Instead, I am going to automatically open an issue in the
>  package-sponsors tracker for new contributors after they receive
>  fedora-review+ on their first ticket. 
LGTM now. Thank you for working on this.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Otto Liljalaakso]

Jakub Kadlcik kirjoitti 17.4.2023 klo 18.53:
>  I want to thank you all for the feedback.
>  
>  Everything was already mentioned in the discussion so I am not going
>  to dig into details again. Just a quick summary for anyone who wants
>  TL;DR for this thread:
>  
>  - I am not going to implement the original proposal or any variation of it
>  - Instead, I am going to automatically open an issue in the
>  package-sponsors tracker for new contributors after they receive
>  fedora-review+ on their first ticket. A link to this issue along with
>  some explanation will be automatically commented to their package
>  review Bugzilla ticket.
>  - You can follow the progress here
>  https://github.com/FrostyX/fedora-review-service/issues/18 
Sounds great, thank you for working on this!

[Dominik 'Rathann' Mierzejewski]

On Monday, 17 April 2023 at 17:53, Jakub Kadlcik wrote:
>  I want to thank you all for the feedback.
>  
>  Everything was already mentioned in the discussion so I am not going
>  to dig into details again. Just a quick summary for anyone who wants
>  TL;DR for this thread:
>  
>  - I am not going to implement the original proposal or any variation of it
>  - Instead, I am going to automatically open an issue in the
>  package-sponsors tracker for new contributors after they receive
>  fedora-review+ on their first ticket. A link to this issue along with
>  some explanation will be automatically commented to their package
>  review Bugzilla ticket.
>  - You can follow the progress here
>  https://github.com/FrostyX/fedora-review-service/issues/18 
That sounds excellent to me. Thanks for doing this!

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Otto Liljalaakso]

Kalev Lember kirjoitti 4.4.2023 klo 10.36:
>  On Tue, Apr 4, 2023 at 9:22 AM Vitaly Zaitsev via devel <
>  devel(a)lists.fedoraproject.org&gt; wrote:
>  
> > On 04/04/2023 07:52, Otto Liljalaakso wrote:
> >> Perhaps new package requests could more often be handled in a way where
> >> an existing packager assumes the maintainer position with the agreement
> >> that the submitter keeps the packager updated and in good condition,
> >> through pull requests.
> >
> > We have a serious problem here: non-packages can't upload sources to
> > Fedora SCM.
> >
> > These pull requests require maintainers to do it manually in a separate
> > commit that breaks %autorelease+%autochangelog.
> >
>  
>  That's not exactly true. Yes, non-packagers can't upload files to the
>  lookaside cache, but they can update the 'sources' and '.gitignore'
> files
>  in git.
>  
>  The easiest way to do that is with 'fedpkg new-sources --offline' which
>  then only does the local modifications that can be committed to git (and
>  submitted as a PR), but doesn't upload the files to the lookaside cache
>  servers. 
Yes, we have both problems that make working with pull requests clumsy, 
and slow progress like 'fedpkg sources --offline' that is making things 
easier.

In any case, I did not mean that we could just go all-in with pull 
requests now. I mean that we should try to improve things so that using 
them becomes more and more convenient and effective.

[Benson Muite]

On 4/4/23 08:52, Otto Liljalaakso wrote:
>  Benson Muite kirjoitti 4.4.2023 klo 7.02:
> > May
> > also want to automatically track unofficial reviews by prospective
> > packagers, perhaps even requiring a certain number of unofficial reviews
> > for the sponsorship process to start.
>  
>  Yes, I think that the sponsorship process should be made more rigid,
>  with at least somewhat formally defined requirements. Maybe something
>  along the lines "do N unofficial package reviews AND submit M pull
>  requests to packages and get them merged AND convince a sponsor". The
>  current approach where "convince a sponsor" is the only actual
>  requirement creates unfortunate bias:
>   
Pull requests are less easy to judge and vary significantly in
complexity.  It helps to judge, in particular since it is one way to
help maintain a package.  They can be used in assessing, but fixing a
number of these as a requirement is difficult. They may also take time
to merge.
>  1. The easiest way to get in is to know somebody who is already in.
> This
>  is basically the opposite of how I understand "open community".
>   
This is true.
>  2. Applicants who find it easy to engage with unknown people in
> higher
>  community standing and have high confidence in their abilities navigate
>  the (ill-defined, unclear) process much easier than more cautious types.
>  Such character traits are of course very useful when participating in
>  open source communities, but discriminating other kinds of personality
>  leads to fewer contributors and lost talent. And it is, well,
>  discriminatory, thus not very ethical in my opinion.
>  
>  Another thing that can be improved here is to make it much less
>  necessary to even get packager status. Working with pull requests should
>  be the norm. Perhaps new package requests could more often be handled in
>  a way where an existing packager assumes the maintainer position with
>  the agreement that the submitter keeps the packager updated and in good
>  condition, through pull requests. The packager status should be just an
>  optional thing you can apply at some point in your Fedora contributor
>  career, *if* a situation demanding that occurs - much like packager
>  sponsor, provenpackager or even FESCo member status is, or how in
>  upstream projects there often are prominent contributors that take part
>  in the conversation and submit pull requests, without any commit access.
>  
Response times to pull requests can vary.  Most people who want to be
packagers are submitting something new.  The above would work well for
SIGS which package related software.  In particular, if a package can be
adopted by a SIG, then the person submitting it need not be sponsored to
have the package in Fedora, as the SIG can adopt the package, and the
person submitting it make pull requests to make changes.

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 10.43:
>  Response times to pull requests can vary.  Most people who want to
> be
>  packagers are submitting something new.  The above would work well for
>  SIGS which package related software.  In particular, if a package can be
>  adopted by a SIG, then the person submitting it need not be sponsored to
>  have the package in Fedora, as the SIG can adopt the package, and the
>  person submitting it make pull requests to make changes. 
I am wondering that this notion that most of the time, new packagers 
want to submit a new package. Is that just a feeling or do we have some 
way to get actual data?

And how do we control for the fact that even currently, and even more in 
the past, the documentation for the process is assuming that to be the 
typical case. I assume that creates a bias by attracting potential 
contributors who have a new package, and repelling others who have 
something else in mind.

[Vitaly Zaitsev]

On 04/04/2023 02:59, Jakub Kadlcik wrote:
>  I get the same impression and I would agree with Otto's proposal
> to
>  get rid of the FE-NEEDSPONSOR entirely. 
Looks good for me too. Opening a new Pagure ticket would be better, IMO.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Benson Muite]

On 4/4/23 10:14, Vitaly Zaitsev via devel wrote:
>  On 04/04/2023 02:59, Jakub Kadlcik wrote:
> > I get the same impression and I would agree with Otto's proposal to
> > get rid of the FE-NEEDSPONSOR entirely.
>  
>  Looks good for me too. Opening a new Pagure ticket would be better, IMO.
>   
This is helpful when reviewing. It could be changed to NEW-SUBMITTER or
POTENTIAL-PACKAGER.  However, it should not be taken as an actionable
item for sponsorship for which a Pagure ticket could be opened when
required.

[Björn Persson]

Jakub Kadlcik wrote:
>  > From this thread I get
>  > the opposite impression, that Pagure tickets are processed quickly and
>  > FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
>  > is updated to ask for a Pagure ticket in every case.  
>  
>  I get the same impression and I would agree with Otto's proposal to
>  get rid of the FE-NEEDSPONSOR entirely. 
To a beginner (in any project) it's cumbersome to file two separate
requests in two different issue trackers for what feels like a single
task. It's less of a barrier to beginners if they only have to deal
with Bugzilla.

On the other hand it's important that there are ways to become a
packager without adding a new package, so a package review in Bugzilla
can't be the only way to get sponsored.

Therefore, if some automation can notify the sponsors in Pagure when a
review is completed and still blocks FE-NEEDSPONSOR, that sounds like a
better idea than getting rid of FE-NEEDSPONSOR. It would lower the
barrier to entry for those beginners who begin by making a new package.

>  Apart from it not being
>  processed as effectively as the package-sponsor repo tickets, the
>  FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
>  the ticket doesn't need to be sponsored, the contributor does. That
>  becomes weird when the contributor has more tickets at the same time
>  and so on). 
I would think most beginner packagers start with a single package. I had
three myself, but they depended on each other so one specific package
had to go first. A beginner with multiple independent packages, such
that they can be reviewed and imported in arbitrary order, is probably
an uncommon case.

Björn Persson

[Miro Hrončok]

On 01. 04. 23 23:14, Jakub Kadlčík wrote:
>  What do you think? Would you be okay with a system like this?
>  Please forward to sponsors that you know, if there is no strong
>  disagreement, I'll proceed with the implementation. 
I myself am very careful about who do I sponsor. For instance, I only pick 
folks that seem to have no trouble communicating. I realize it's not very 
inclusive, but my time is limited and sponsoring folks that have trouble 
communicating is very time consuming and frustrating. Hence, if this was 
implemented, I'd probably opt-out.



-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok