Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[konsolebox]

On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny <mgorny@g.o> wrote:
> On Sat, 11 Jun 2016 11:09:39 +0800
> konsolebox <konsolebox@×××××.com> wrote:
>
>> On Wed, Jun 8, 2016 at 11:53 PM, james <garftd@×××××××.net> wrote:
>> > The grandiose-ness you propose should only come upon graduating from proxy school, imho.
>> > user-->strong-users-->proxy-->dev pathway.
>>
>> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
>> Too conservative.
>>
>> What matters is the contribution, and the result.  If you don't like
>> how a user makes a contribution, don't accept the pull request, or
>> don't merge his package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> You're contradicting yourself. How can improving/review of pull request
> be non-mandatory, if otherwise we are to reject it? Of course, it all
> depends on how you define 'mandatory'. It's not like anybody forces you
> to do something, you know.

No, you just misinterpret. You can review pull requests.  You can
reject stuff, but don't reject them just because some laid-out steps
in the documentation has not been followed.  Some may not be
completely necessary.  I'm implying that these "academic" steps may
not be completely helpful at all times, and making us follow these
things only make making a contribution stiff and restrictive.

I'm mainly referring to the strict user-->strong-users-->proxy-->dev
pathway that James is encouraging, where it seems like you have to
become a proxy developer first (or maybe, prove yourself first; gain
first some trust), before you are acknowledged to be able to
contribute in a manner that Alexander Berntsen has been suggesting.

These stuff imply unnecessary old-fashioned restrictions that aren't
"necessarily" helpful to security.  It doesn't help encourage users to
become active.

To make it clear, I'm mostly talking about users who would want to
contribute, but doesn't necessarily take pledge on the responsibility
of maintaining a package.  And isn't that what we are mostly talking
about?  If we also talk about maintenance-ship, don't we already have
the proxy maintainer for that position?

> Sure, it may seem like we expect people to fix all the tiny issues with
> pull requests but that's just a default profile we're assuming. Many of
> the people actually *want* to do that. If you don't, you can tell us
> straight ahead and we won't waste our time asking you to.
>
> I'm also unhappy when a pull request is left open for two weeks because
> we asked user to do a simple change, and he doesn't reply. I could've
> fixed it myself faster but then the user would lose his chance to do
> it. And the worst thing, I don't even know if he wants to!

There's nothing I say against that.

>> We do already allow people to send pull requests to
>> Gentoo portage's repo in Github, but it seems like they generally only
>> allow patches that fix current packages, not new features or new
>> packages.
>
> That's not true. The rules for pull requests are pretty much the same
> as for bugs.

That's great if that's really the case, but a more transparent, less
restrictive, and more dynamic system that could attract casual
contributors would be better.   Something like a web service where
their work would be officially indexed so everyone could easily find
it, not just the current developers of the current tree snapshot
they're trying to push their work to, who may reject it, if it was
intended to be pushed.  I gave the details about this in my other
e-mail.

-- 
konsolebox