On 06/12/2016 01:10 AM, konsolebox wrote:
On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny <mgo...@gentoo.org> wrote:
On Sat, 11 Jun 2016 11:09:39 +0800
konsolebox <konsole...@gmail.com> wrote:
On Wed, Jun 8, 2016 at 11:53 PM, james <gar...@verizon.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
