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

[james]

On 06/12/2016 01:10 AM, konsolebox wrote:
> 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.

Wrong and misleading. I am proposing but one pathway. Come to find out, 
others have already started a mailing list for that (proxy) pathway. 
Furthermore, iff a fantastic programmer from Debian was to contact the 
Gentoo staff, someone of known caliber and accomplishments, and wanted 
to become a Gentoo dev, that person would be fast tracked, very similar 
to a returning gentoo dev. Tom Gall, a very accomplish ARM coder, 
recently returned for a while. He was quickly re-established as a gentoo 
dev, and is a recognized ARM innovator. He has since gone silent and 
returned to a more formal position within Arm development. I can think 
of dozens more. Those are different pathways, I have no problem with 
that fact and I'm quite happy that gentoo has multiple pathways to 
dev-status.


Skills go a long way, particularly if you are established in the FOSS 
communities. So there are multiple pathways and new ones, such as your 
can be proposed and proven up. Just go do the work and stop whining.

Then there are the multitude of ordinary coders or coder-wannabes, that 
do need the user-->strong-user-->proxy--> dev pathway, well defined
and well documented. Nothing in what I have said excludes other 
pathways. Nothing.

I did point out that /usr/local/portage on your own system, or github do 
exist and provide yet another pathway to dev status, when one can 
produce a body of work and answer those quizzes... Be bold!


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

Wrong again. If you have such a brilliant idea, let it stand on it's own
merits, let it be a 'back door' for interlopers on your system. I have 
too many validated experiences with gentoo that cause me to keep a
conservative, trust the gentoo security devs, position  rather than to 
allow random ebuilds on my systems, be they core packages or application 
specific. But, this does not preclude you, and your pals, from building 
stuff outside the (gentoo) box and making those ebuilds available.

In fact the easiest thing for you to do is form a distro, and do things 
your way, whilst maintaining close to the portage tree function. We
already have a wonderful distro, called Pentoo, that does just that.
Things are quite wonderful between these distros.



> 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.

There is absolutely nothing in gentoo that prevents this. But, you 
should not expect 'a rank and file blessing from the gentoo devs', 
without 'due diligence'.


> 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?

Devs within Gentoo are on an aggressive pathway to purge codes (ebuild 
packages) that do not list an accountable dev or proxy, in case you have 
not been reading gentoo-dev for a while. Many of the purged codes still 
work and are fine, but no one accountable, so they hit the purge button.

I know, over the last year, I have at least 50 packages in my 
/usr/local/portage, that I intend to prioritize and then rescue. Granted 
many are C codes that I just like, or they have few dependencies, or 
they are small and simple focused codes. So, like you, I will be running 
my own github, outside of portage. I also intend to try, as a proxy, to 
keep many of them active in the tree, if it makes sense.

So I have multiple pathways to ebuild support, and it is working out, 
just fine. My one beef, and it is fixed, is a mail list for the 
proxy-maint, and not being forced to use irc. And that has been solved 
in other sub-threads of this discussion.

Then there is another pathway, to build embedded linux systems into a 
HPC cluster so the concept of discrete gentoo servers, is deprecated.
Mix in a bit of AI and poof, clusters for the masses. Years of work, 
many doubters, some key supporters who are not even gentoo enthusiasts.
If I even get close on this own, I'm quite some devs I know will me 
pushing strongly for me to become a gentoo dev. If I fail, I will still 
obtain gentoo-dev level knowledge. But I do not blame gentoo for not 
being successful (yet).

Many pathways, substantiate your dream.


>> 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.

I'll bet a percentage of those open pull requests, are do to a lack of 
knowledge, which is due to a lack of gentoo-github-centric documentation 
and examples. I know, I've farted all over myself a few times with 
git(hub).....


>>> 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.


Where is all of this (above) documented? I need to read up and follow a 
few examples of this.....

>
> 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.

OK great. Agreed. After you find just one dev, start a gentoo-project
and start coding your dream. But the proven pathways, should be left
intact and receive further documentation, as they are working great.
Stop blaming others or saying that the existing pathways are 
discouraging, because they are not. Go forth and code. A large ebuild 
base is your best alley. Just stop implying that other things have to 
change in your favor for your ideas to have a chance.  What currently 
exists is irrelevant to proving your ideas.



James