Improving our processes for new contributors.

Stephen John Smoogen smooge at
Wed Jul 15 18:22:09 UTC 2015

On 15 July 2015 at 11:26, Ralf Corsepius <rc040203 at> wrote:
> On 07/15/2015 07:03 PM, Przemek Klosowski wrote:
>> On 07/15/2015 12:05 PM, Michael Schwendt wrote:
>>> On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote:
>>>> I do understand where you're coming from: the Fedora workflow is quite
>>>> complicated
>>> What exactly do you find "quite complicated"?
>> I was responding to Les' comment about the tools that one needs to use
>> in order to package something: RPM, VCS, i18n, lib/autotool, COPR,
>> Bodhi, mock, etc.  Don't get me wrong---I am not saying that there's
>> anything wrong with the tools, just that they seem easy to those who
>> already mastered them, but may be intimidating to the uninitiated.
> Well, I consider knowledge about rpm, VCS, <programming language> to be
> elementary basic prerequistes to join as Fedora packager. Of course you
> don't need to be familiar with everything, but you should understand what
> you are doing - Assuring this is the aim of package-sponsors process.
> I agree with you that the Fedora specifics "koji", "bodhi", Fedora's git,
> Fedora's web sites leaves much to be desired. Getting into these is a steep
> entry hurdle.
> However, making new packagers familiar with this to an extend, which enables
> them to self-aid then, used to be the job of a new packager's *sponsor* (I
> prefer to call them "mentors").
> It seems to me as if this aspect has almost be forgotten and
> packager-sponsors become a passport rubber-stamping duty.

This complaint has been going on since at least 2007 by various
sponsors (I think my oldest time of you saying it is from around
then). The other complaint is that we have too high of barriers and
people aren't using Fedora because they can't find the packages they
need. Both sides seem to go into this tiff around post-release to
branching of the next release... and we just come to a muddled middle
ground where neither thinks they got their way, and just hopes the
other side didn't get anything either.  [At some point in these
threads someone from either side will bring up how Debian does it
better.. they have all the packages and all their packagers are real

>> This is my point, actually, that it's hard for a packaging pro to
>> appreciate the confusion of a newbie. Some kid-glove treatment, and ELI5
>> tutoring/mentoring might help.
> Well, I agree with you wrt tutoring/mentoring, but ... this has always been
> part of job of the "sponsor" - seriously, really.

I think the issue is that there are as many ways to 'mentor' someone
as there are in packaging up software. Everyone thinks what they are
doing is mentoring the next person even if all they did was write "Did
you read the wiki?" to "OK let's do this step by step review of what
you need to know. First off, do you actually know what this software
is? Can you fix problems in the software that people will find? If you
can't, how are you going to deal with bugzilla reports? etc etc. "

And trying to define what mentoring is gets into the same arguments
where X thinks you are disparaging their style or Y thinks that this
is extra bureaucracy for no benefit or Z thinks that this isn't
actually going far enough because there isn't a test to prove the
person isn't just answering yes to everything but doesn't know

In anycase I am tired of the fence sitting we have here and agree with
Ralf that changes need to be made. I would like to have a definition
of what a packager should know and how a sponsor should mentor so that
both have an idea if they are keeping up their end of the bargain. And
if it means I am not a packager from those definitions.. hey cool at
least I won't have impostor syndrome anymore.

> Ralf
> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

Stephen J Smoogen.

More information about the devel mailing list