Sponsor shortage

Stephen John Smoogen smooge at gmail.com
Sat Jul 11 17:45:13 UTC 2015


On 11 July 2015 at 04:56, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 10 Jul 2015 17:24:26 -0600, Stephen John Smoogen wrote:
>
>> This is a vicious cycle. A lot of sponsors are burnt out on trying to
>> deal with new people who don't seem to have a clue.
>
> Laziness, lack of activity, lack of interest, sloppy packaging,
> dumping-ground/fire'n'forget mentality, there are various factors.
>
> Sometimes it's cluelessness, yes. Paired with no interest in reading
> guidelines, since the self-made package builds. And lots of people think
> why create an RPM package, if compiling from scratch in trial-and-error
> fashion seems to produce something?
>
> Over the last years I've talked to quite some people. Some simply find
> the package review process "too embarrassing", because the tickets are
> world-readable. Once they learn that the package they offer is full of
> mistakes, they consider it "public shaming" and would like to delete
> the embarrassing ticket and restart from scratch. In some cases this
> has lead to doing early reviewing and guiding in private email, but
> with mixed results, such as people starting to argue about guidelines
> or how to do something.
>
> Sponsoring someone based on a single package only to find out the person
> leaves the project again before handling the first few bug reports is
> very disappointing for sponsors.
>

I think that a lot of that is just the price of being a long lived
project. I get peeved on seeing people leaving after putting in a
package done.. but then I look over the history of things and realize
it has always been that way and the perception that it wasn't was just
me making the past happier than it was.

>> And a lot of
>> potential new people feel burnt to the crisp by reviews and
>> expectations of being wed to a package for life when all they wanted
>> to do was help someone else use some software.
>
> That's painted in too dark colours. The review process turns up too many
> mispackaged pieces of software, where the packages have not been tested
> at all. Offering such packages would be a poor choice. You can hope for
> random volunteers to take care of thousands of packages in a dumping
> ground whenever they feel like spending time on arbitrary packages, but
> that won't work. It is doomed to fail.
>
> Once a package is included in "the distribution", there is much more work
> to do compared with the review process.
>
> And "wanting to help"? Lots of packages would benefit from better bug reports
> (more responsive reporters) and communication between upstream and downstream.
> A dumping ground won't help here. All you achieve by talking about lowering
> the hurdles it that the current new contributors prefer waiting for the
> Fedora Project to announce something, such as getting rid of the review process,
> a dumping repo for unreviewed packages, or automatic blanket-approval of new
> packagers.

I agree that lowering hurdles is not good and I don't want to lower
hurdles, I want to fix broken ones.

1) Parts of reviews come across as arbitrary nitpicks. You put a
package into 3 different reviewers.. you will get 3 different sets of
fixes that seem to need to be made.
2) Reviews and fixes against existing packages aren't done. So if I
base my package off of various high profile packages in Fedora already
I won't pass review.. and I will probably also find that those
packages have 'accepted' differentiation because no one wants to get
into a political fight over XYZ package ever again.
3) Reviews get lost in limbo for some percentage of people with no way
of getting them back on track. Then when someone searches for reviews
to get an idea of how to do them.. those are the open ones that show
up.
4) Teaching of how to do basic reviews is "RTFM" with a "Good Luck to
Find the Right FM" as an unspoken corollary on our mountain of dead
wiki pages.

I have seen more than enough IRC conversations of
A: "I would like to do something, what can I do?"
B:"Review a package."
A:"OK how do I review a package?"
B: "Read through these docs ... url1, url2, url3"
C: "Oh don't use those URLs they are out of date."
B: "Oh when did that happen...."
C: "Oh we decided to drop that part and went to this new system...
hmmm it says that is obsolete. Oh well someone will know."
A:.......
<two days later>
D: Why didn't anyone tell A to talk to me.
B,C: Who are you and why would we...

Or the person goes over to the SIG mailing list or irc group asks a
question and doesn't get a reply at any time.. then it is usually..
"Why do we even have this SIG if no one is working on things. Someone
should do something about that!"

So enough whinging. How can we fix this. How do we make it clear which
pages are to be used to learn how to review a package because Google
seems to show me different pages depending where I physically search
from versus the same list every time. How do we deal with our existing
mountain of packages to see if they are still in line with reviews?

-- 
Stephen J Smoogen.


More information about the devel mailing list