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

[james]

On 06/08/2016 08:16 AM, Alexander Berntsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Friends,
>
> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
>
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.

Folks can already do this on their own with github. Are you suggesting
individual githubs, under the 'gentoo umbrella'?


> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.

In fact, users of gentoo learning to review ebuilds (from other users)
is a good idea, particularly more in the 'application' or 'area of 
interest' as opposed core or gentoo-centric packages.


> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.

Sorry, I'm not buying into the 'utopia' scheme. The current gentoo::
user-->proxy-->dev pathway needs to become stronger. I your proposal as
complimenting that pathway, like this:: user-->strong_user-->proxy....
However, if/when utopia is achieved, sure I'll guzzle the koolaid.


> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.

Too much power too quickly. I'd suggest a user, with an area of interest
that is under-served as to their package needs (java, clusters, science, 
etc) creates said github repo and starts cracking at packages. The 
grandiose-ness you propose should only come upon graduating from proxy 
school, imho. A dev actually can now get their own repo, via github, or 
a group of devs can work out of the same repo, as self-defined as to 
what works best.



> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.

Actually a different project, imho. Focus on strong-user-->proxy-->dev.


> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.

Now you have just joined my chorus. Gentooers, are pretty much 'flung 
against the git-wall'. There is a gentoo way, but nobody of sufficient 
knowledge depth cares to create such tools and docs. It's not easy. 
Examples == {null set}.

Some have been revising the devManual, just to bring it current with all 
the  changes. That is a challenging effort, because, the dev-manual is 
where the dev community must agree.  There needs to be a proxy manual 
and development materials (I personally hate IRC as it is often ADD-noise).

Proper docs take a while to develop and even more effort to maintain.

> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.


If you agree with loosing the more grandiose ideas (for now) from above, 
I'll work with you as a test-grunt on developing documents and pathway 
training, on a modular basis following  the
user-->strong-users-->proxy-->dev pathway.

I guess to sum it up, WE, work together via emails (create first draft
docs from emails), set up a github account, learn the necessary 
specifics of  github-gentoo-kungfu, create manuals (several revisions of 
these new docs) and such so I can successfully graduate (pass the ebuild 
and postmortemproxy quizes) and become a candidate for dev status, 
without ever using IRC.

Note:: does not imply that I will apply for dev-status, or any 
requirement to be accepted as a dev, but that I am recognized, via 
accomplishments to @dev-status.

DEAL?

This means I create the cookbooks, (format?) based on our email 
discourse, and you play editor/mentor until you think I'm ready for 
dev-status. I'll have my own github (something on my todo list anyway). 
I'd even like this document/pathway to seemlessly reference the new 
gentoo devManual, frequently. If we are successful it means there will
be a (cook)book for self paced study for user==>dev, without the noise
of irc.


ps, I already completed the ebuild quiz and most of  the end-o-mentoring
quiz. The things not finished are in flux due to changes. Still, I have
holes in both my 'big picture comprehension of gentoo-bike-shedding,
git/github and general need to become a stronger coder (python).

INTERESTED?
James


> What are your thoughts?
> - --
> Alexander
> bernalex@g.o
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJXWBrFAAoJENQqWdRUGk8BzvQP/iTrs1SedU3xrLoWwYb5LDBv
> JT2Com8GZX6BE2KlAoljeO+epZT5WPe8sd0DTDg7l/kgceHdHzKpv9lXcf8l2XyX
> d/WNTwGkzXl4it9b8FuDBfOHnhVIAr2kF3xs8N2C/aJAFAG4MuoQFmBdx0FTybqw
> ahJvVMzElhYe2Hv3NTpawluW5K7MF9HXmQfS1lHwNadklWtoOIXEoN2AAitdwdzH
> dr5bzPMnoc6HN4a4QEB93zDYMoJaGcMPRisQfSm7xr3J3XxZzmpTSEs9dNrJ7GmY
> 2yFQfZFGZTg7Wf04HI2JTBBS02CfLv5HAt7Z6V1RJvtzRD3mtrMP+fl8tTn0YZCR
> U8MarqRiaz1LIpZzkeNM+EHY4QkwIsYG3HHcQ+sCEaUf9H0812E0XFZXNwW3XhgJ
> UygKlG9pXwCsCCjGCWkTh8ppot3u6WAHhXifPsQ3ef0yTMohS9w5oudcF2VpeZj0
> V6l6Cv5KoxD1ZOUXq3GshLpxZL1yOSAEbzbtsUvMCj7xtWdF9gVR2+tYR++lCj4G
> 5o3AlNBXCGhy2KvH+kcXItwpV9VGP1UXgXGz4mA1H6XLp3B8rBqXyQeTZ22v3toz
> nCthV6KxYdRhOqqh0/TThJryW47c8Xz3GDSDDU1XhSTzqbfpPpBpVjEakODGu7Jy
> AwWFC9xoaV7iwnBbFq7F
> =zXlj
> -----END PGP SIGNATURE-----
>
>