2:32 a.m.
I had the talk [1] about Fedora Sponsorship process at Flock. And we had
very interesting follow-up discussion.
We come up with several improvements, which should be easy to implement
and may improve the process a lot. I am posting it here so more people
can see that and join the discussion.
a) Sponsoree (who apply for package maintainer status) is required to
create Copr project and maintain the package there until he get the
package into Fedora. This should show his endurance to sponsors. It will
improve the morale of the sponsoree as the package is immediately ready
for other users. And it is not wiped after 14 days as scratch builds in
Koji.
b) fedora-review is run automatically by some bot/script just after
review have been submitted.
c) Create wiki page with list of sponsors willing to accept new
sponsoree. And list area of expertise of sponsors (e.g. java, python,
IoT...). This will make for sponsoree easier to find right sponsor.
Because we have some sponsors, who are active but are not willing to
accept new sponsoree right now.
d) When sponsors is not active for 2 years [*] - that means not just in
sponsoring work, but there is no activity in BZ, koji, wiki and any
other Fedora service at all (guessed by reading log of fedmsg), then his
sponsor status is removed. We will assume that the sponsor is gone for good.
e) When the package review is still not assigned to anybody after 3
months [*], then 3 [*] random sponsors are added to CC and asked to
proceed with the review despite the fact that it likely doesn't belong
to their area of expertise. This should helps us to get rid of stalled
review, which are waiting for ages to get some sponsor.
Those are the ideas which came up at Flock. Please comment this. And if
we come to some conclusion, I can pass it to FeSCo for approval.
[1] http://miroslav.suchy.cz/presentations/flock2016/sponsors/#/
Please note that the data in this presentation is based only on
data I was able to gather and I am aware the it does not reflect 100%
the reality. But it approximately gives us the order of magnitude of the
reality and approximately ratio.
[*] I just made up this number. Feel free to discuss appropriate interval.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
2:53 a.m.
Dne 5.8.2016 v 09:32 Miroslav Suchý napsal(a):
I had the talk [1] about Fedora Sponsorship process at Flock. And we
had very interesting follow-up discussion.
We come up with several improvements, which should be easy to
implement and may improve the process a lot. I am posting it here so
more people can see that and join the discussion.
a) Sponsoree (who apply for package maintainer status) is required to
create Copr project and maintain the package there until he get the
package into Fedora. This should show his endurance to sponsors. It
will improve the morale of the sponsoree as the package is immediately
ready for other users. And it is not wiped after 14 days as scratch
builds in Koji.
You have not noted it here and probably not thought about it, but the
advantage of Copr is that it actually provides hosting for SRPMs and it
provides dist-git as well, so one could send a link to .spec file
referring to dist git. That would be actually quite nice benefit, since
newcomers typically struggles with such questions as "where to put my
SRPM/.spec file".
Vít
3:31 a.m.
Hi,
On Fri, Aug 5, 2016 at 1:02 PM, Miroslav Suchý <msuchy(a)redhat.com> wrote:
I had the talk [1] about Fedora Sponsorship process at Flock. And we
had
very interesting follow-up discussion.
We come up with several improvements, which should be easy to implement and
may improve the process a lot. I am posting it here so more people can see
that and join the discussion.
a) Sponsoree (who apply for package maintainer status) is required to create
Copr project and maintain the package there until he get the package into
Fedora. This should show his endurance to sponsors. It will improve the
morale of the sponsoree as the package is immediately ready for other users.
And it is not wiped after 14 days as scratch builds in Koji.
Few package submitter are using this currently, it will be good
improvement for new contributors to use Copr.
b) fedora-review is run automatically by some bot/script just after review
have been submitted.
Can a new utility be written for this as I don't think that long
fedora-review output is helpful? Most checks have no markings in them.
How can it be helpful to package submitter?
c) Create wiki page with list of sponsors willing to accept new
sponsoree.
And list area of expertise of sponsors (e.g. java, python, IoT...). This
will make for sponsoree easier to find right sponsor. Because we have some
sponsors, who are active but are not willing to accept new sponsoree right
now.
This can be in addition to above, Why not run a script frequently and
check bugzilla and based on common naming CC the related SIG group?
e.g. if a package review is submitted whose name contains python then
add cc python SIG group that will notify actual group people and
someone can find interest and review the package. I know this is in
general suggestion but I suppose every SIG is also having some
Sponsors who can sponsor new contributor packages.
d) When sponsors is not active for 2 years [*] - that means not just in
sponsoring work, but there is no activity in BZ, koji, wiki and any other
Fedora service at all (guessed by reading log of fedmsg), then his sponsor
status is removed. We will assume that the sponsor is gone for good.
Well good information for other people or FESCo to take action and
orphan their packages as well ;-)
e) When the package review is still not assigned to anybody after 3 months
[*], then 3 [*] random sponsors are added to CC and asked to proceed with
the review despite the fact that it likely doesn't belong to their area of
expertise. This should helps us to get rid of stalled review, which are
waiting for ages to get some sponsor.
Was there any discussion on what to do with existing stalled package
reviews? I think we should go and close stalled reviews where there is
no update from package review submitter for last six months at least.
Those where reviewer is not progressing, just remove the assignee and
any fedora-review? flag. The review queue I am considering here is
FE-NEEDSPONSOR queue and "tickets under review" queue.
Those are the ideas which came up at Flock. Please comment this. And
if we
come to some conclusion, I can pass it to FeSCo for approval.
[1] http://miroslav.suchy.cz/presentations/flock2016/sponsors/#/
Please note that the data in this presentation is based only on data I
was able to gather and I am aware the it does not reflect 100% the reality.
But it approximately gives us the order of magnitude of the reality and
approximately ratio.
[*] I just made up this number. Feel free to discuss appropriate interval.
Regards,
Parag.
3:19 p.m.
On 08/05/2016 10:31 AM, Parag Nemade wrote:
> b) fedora-review is run automatically by some bot/script just
after review
> have been submitted.
Can a new utility be written for this as I don't think that long
fedora-review output is helpful? Most checks have no markings in them.
How can it be helpful to package submitter?
You can configure which fedora-review checks are ran, for example
exclude any non-automated checks.
> c) Create wiki page with list of sponsors willing to accept new
sponsoree.
> And list area of expertise of sponsors (e.g. java, python, IoT...). This
> will make for sponsoree easier to find right sponsor. Because we have some
> sponsors, who are active but are not willing to accept new sponsoree right
> now.
This can be in addition to above, Why not run a script frequently and
check bugzilla and based on common naming CC the related SIG group?
e.g. if a package review is submitted whose name contains python then
add cc python SIG group that will notify actual group people and
someone can find interest and review the package. I know this is in
general suggestion but I suppose every SIG is also having some
Sponsors who can sponsor new contributor packages.
This won't work for all SIGs. For example, Java packages don't have any
common naming scheme. If you just search for "Java" in review requests,
almost all results will be false-positives (eg. from "JavaScript") and
you won't find most of relevant reviews this way.
I think that wiki page could work for this purpose.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
11:24 p.m.
Hi,
On Sat, Aug 6, 2016 at 1:49 AM, Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
On 08/05/2016 10:31 AM, Parag Nemade wrote:
>> b) fedora-review is run automatically by some bot/script just after review
>> have been submitted.
>
> Can a new utility be written for this as I don't think that long
> fedora-review output is helpful? Most checks have no markings in them.
> How can it be helpful to package submitter?
You can configure which fedora-review checks are ran, for example
exclude any non-automated checks.
I suppose then Generic group checks are sufficient here.
>> c) Create wiki page with list of sponsors willing to accept new sponsoree.
>> And list area of expertise of sponsors (e.g. java, python, IoT...). This
>> will make for sponsoree easier to find right sponsor. Because we have some
>> sponsors, who are active but are not willing to accept new sponsoree right
>> now.
>
> This can be in addition to above, Why not run a script frequently and
> check bugzilla and based on common naming CC the related SIG group?
> e.g. if a package review is submitted whose name contains python then
> add cc python SIG group that will notify actual group people and
> someone can find interest and review the package. I know this is in
> general suggestion but I suppose every SIG is also having some
> Sponsors who can sponsor new contributor packages.
This won't work for all SIGs. For example, Java packages don't have any
common naming scheme. If you just search for "Java" in review requests,
almost all results will be false-positives (eg. from "JavaScript") and
you won't find most of relevant reviews this way.
I think that wiki page could work for this purpose.
Right not for all SIGs but at least for those where its possible. Just
see there are many such common pattern named packages are waiting in
queue for their package review. I can think of some patterns like
perl, python, golang, nodejs, ruby, ghc, mingw, php etc.
Regards,
Parag.
11:47 p.m.
On Sun, Aug 7, 2016 at 12:24 AM, Parag Nemade <panemade(a)gmail.com> wrote:
Right not for all SIGs but at least for those where its possible.
Just
see there are many such common pattern named packages are waiting in
queue for their package review. I can think of some patterns like
perl, python, golang, nodejs, ruby, ghc, mingw, php etc.
Regards,
Parag.
--
You could maybe also search the summaries of packages for certain keywords
for some other SIGs that don't have common naming schemes? For example, I
just went through the review queue looking for packages with the word
"game" somewhere in the summary to build a list of unreviewed packages for
the Games SIG.
Admittedly, I'm struggling to think of another group of packages this sort
of pattern would be as easily applicable to, and you won't be as accurate
as you would be with getting, say, Python or NodeJS packages, but it might
help if we want to automatically catalog the queue.
Ben Rosser
9:04 a.m.
Miroslav Suchý wrote:
I had the talk [1] about Fedora Sponsorship process at Flock. And we
had
very interesting follow-up discussion.
We come up with several improvements, which should be easy to implement
and may improve the process a lot. I am posting it here so more people
can see that and join the discussion.
a) Sponsoree (who apply for package maintainer status) is required to
create Copr project
*required*? No, strongly encouraged maybe.
As an aside, Copr doesn't require CLA+1 ?
(If not, isn't that just asking to be abused/spammed, like the we've seen
elsewhere?)
-- Rex
8:50 a.m.
Dne 5.8.2016 v 16:04 Rex Dieter napsal(a):
As an aside, Copr doesn't require CLA+1 ?
Nope, it does not require it.
(If not, isn't that just asking to be abused/spammed, like the
we've seen
elsewhere?)
This does not happened yet (and Copr is here for quite long of time). I do not want to put
a bar high prematurely.
If this ever happen we will do something.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
9:35 a.m.
On Fri, Aug 5, 2016 at 3:32 AM, Miroslav Suchý <msuchy(a)redhat.com> wrote:
I had the talk [1] about Fedora Sponsorship process at Flock. And we
had
very interesting follow-up discussion.
We come up with several improvements, which should be easy to implement and
may improve the process a lot. I am posting it here so more people can see
that and join the discussion.
Overall, I think the biggest problem with our Fedora contributor
on-boarding process is that it's not so easy to discover people to
help people get started. One thing I think Mageia (the other
distribution I'm primarily involved in) does better is the discovery
bit. As part of the on-boarding process[1], new contributors are
encouraged to jump into a dedicated IRC channel (#mageia-mentoring)
where they can meet people to help them through the process. Something
like this might make it easier for people to find sponsors and find a
mentor to teach them about how to make packages and be a Fedora packager.
Perhaps having a mailing list and an IRC channel for this in Fedora
might help make this process smoother.
[1]: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
--
真実はいつも一つ！/ Always, there's only one truth!
11:59 p.m.
On Fri, Aug 5, 2016 at 10:35 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Fri, Aug 5, 2016 at 3:32 AM, Miroslav Suchý
<msuchy(a)redhat.com> wrote:
> I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> very interesting follow-up discussion.
>
> We come up with several improvements, which should be easy to implement
and
> may improve the process a lot. I am posting it here so more people can
see
> that and join the discussion.
>
Overall, I think the biggest problem with our Fedora contributor
on-boarding process is that it's not so easy to discover people to
help people get started. One thing I think Mageia (the other
distribution I'm primarily involved in) does better is the discovery
bit. As part of the on-boarding process[1], new contributors are
encouraged to jump into a dedicated IRC channel (#mageia-mentoring)
where they can meet people to help them through the process. Something
like this might make it easier for people to find sponsors and find a
mentor to teach them about how to make packages and be a Fedora packager.
Perhaps having a mailing list and an IRC channel for this in Fedora
might help make this process smoother.
[1]: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
Yeah, one thing that I remember when I was trying to become a packager is
that the instructions for how to get sponsored on the wiki contained (and
still contain) the phrase "When submitting a new package, usually a sponsor
finds you", which I think is a bit... overly optimistic in many situations.
Also at the time I was intimidated by the prospect of getting involved with
discussions on this list and IRC, which didn't help.
I looked at the Mageia how-to-become-a-packager process briefly a while ago
(my laptop dual-boots Fedora and Mageia, although I am primarily a Fedora
person), and I did notice how it seemed more hands on than ours. A
dedicated place for new contributors to go and meet potential sponsors or
other mentors, be that IRC or a mailing list, would probably be a good idea.
Ben Rosser
1:48 p.m.
On Fri, Aug 05, 2016 at 09:32:28AM +0200, Miroslav Suchý wrote:
I had the talk [1] about Fedora Sponsorship process at Flock. And we
had very interesting follow-up discussion.
So I kinda missed it, since for some reason, i tought this was
about financial sponsorship.
(Given that I forgot words in each title of my own talks, I can't
really complain much)
c) Create wiki page with list of sponsors willing to accept new
sponsoree. And list area of expertise of sponsors (e.g. java,
python, IoT...). This will make for sponsoree easier to find right
sponsor. Because we have some sponsors, who are active but are not
willing to accept new sponsoree right now.
I think that's a good idea, but wouldn't it risk getting out
of date after some time ?
Should someone be in charge of it ?
d) When sponsors is not active for 2 years [*] - that means not just
in sponsoring work, but there is no activity in BZ, koji, wiki and
any other Fedora service at all (guessed by reading log of fedmsg),
then his sponsor status is removed. We will assume that the sponsor
is gone for good.
what happen to the existing sponsored packagers ? (ie, do they get reassigned
to a new sponsor ?)
--
Michael Scherer
9:56 a.m.
I wanted to elaborate on one of the ideas I threw out during that
discussion.
We (need to|should|strive really hard to) treat new packagers more like
new volunteers for fedora infrastructure. Except that we should accept
that packaging is really, really hard when you don't know where to start
and offer more hand-holding. The infrastructure process seems to work
really well (for infrastructure, at least) and the new packager process
seems to _not_ work really well, so....
Note that I'm assuming here that we don't have that miraculous review
handling program (fresque). I know someone was working on it, and I
should probably see what state it's in, but I'm way behind after being
on vacation for a month. It wouldn't really alter the central point
anyway.
My random proposal for that is to:
1) Add more "front end" to the process (which, yeah, means more process
when we already have too much process). Packagers should send an
introduction and such, perhaps even before they have a package. They
may need help doing that, after all, and we should be providing that
help.
2) At some point, they should be assigned three (or some other
reasonable number) mentors, including (if possible) one from the same
region (from the ambassadors pool or one of the regional groups) just
to help with language issues in case they come up. These don't have
to be sponsors, but at least two should be packagers. Hopefully one
is familiar with and has interest in the "type" of software they
intend to package. (Python, Java, games, whatnot.)
3) They should also be assigned a sponsor from the sponsor pool, if one
is not part of the mentor group. This person will oversee the
process and actually give the permissions, though they don't
necessarily have to do the heavy lifting.
3) These mentors should be "on hand" to assist the packager, answer
questions, etc.
4) We should encourage that new packagers put their specs in pagure so
that people can file pull requests against them. Probably small
specs for easy packages don't need this. This conveniently gives
them a base to have copr pull from, assuming I understand that
functionality of copr. They'll still have to post updates to
bugzilla but we might be able to automate that.
5) A whole bunch more automation to get packages checked and people
pinged would of course be quite useful here.
- J<
2816
days inactive
2820
days old
11 comments
9 participants
participants (9)
-
Ben Rosser -
Jason L Tibbitts III -
Michael Scherer -
Mikolaj Izdebski -
Miroslav Suchý -
Neal Gompa -
Parag Nemade -
Rex Dieter -
Vít Ondruch