| 1 |
On Sat, 11 Jun 2016 11:09:39 +0800 |
| 2 |
konsolebox <konsolebox@×××××.com> wrote: |
| 3 |
|
| 4 |
> On Wed, Jun 8, 2016 at 11:53 PM, james <garftd@×××××××.net> wrote: |
| 5 |
> > The grandiose-ness you propose should only come upon graduating from proxy school, imho. |
| 6 |
> > user-->strong-users-->proxy-->dev pathway. |
| 7 |
> |
| 8 |
> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive. |
| 9 |
> Too conservative. |
| 10 |
> |
| 11 |
> What matters is the contribution, and the result. If you don't like |
| 12 |
> how a user makes a contribution, don't accept the pull request, or |
| 13 |
> don't merge his package. Simple. If you think that could turn out to |
| 14 |
> be just a waste of time for them, help them correct their issues; add |
| 15 |
> some documentations to enlighten them and give warnings about wrong |
| 16 |
> practices so they don't blame anyone, and so they can decide whether |
| 17 |
> they would want to contribute or not given the rules presented; but, |
| 18 |
> _don't_ make the steps mandatory. Don't make contributions |
| 19 |
> restrictive. |
| 20 |
|
| 21 |
You're contradicting yourself. How can improving/review of pull request |
| 22 |
be non-mandatory, if otherwise we are to reject it? Of course, it all |
| 23 |
depends on how you define 'mandatory'. It's not like anybody forces you |
| 24 |
to do something, you know. |
| 25 |
|
| 26 |
Sure, it may seem like we expect people to fix all the tiny issues with |
| 27 |
pull requests but that's just a default profile we're assuming. Many of |
| 28 |
the people actually *want* to do that. If you don't, you can tell us |
| 29 |
straight ahead and we won't waste our time asking you to. |
| 30 |
|
| 31 |
I'm also unhappy when a pull request is left open for two weeks because |
| 32 |
we asked user to do a simple change, and he doesn't reply. I could've |
| 33 |
fixed it myself faster but then the user would lose his chance to do |
| 34 |
it. And the worst thing, I don't even know if he wants to! |
| 35 |
|
| 36 |
> We do already allow people to send pull requests to |
| 37 |
> Gentoo portage's repo in Github, but it seems like they generally only |
| 38 |
> allow patches that fix current packages, not new features or new |
| 39 |
> packages. |
| 40 |
|
| 41 |
That's not true. The rules for pull requests are pretty much the same |
| 42 |
as for bugs. |
| 43 |
|
| 44 |
If a fix or enhancement makes sense, the maintainer can approve it or |
| 45 |
not. Don't expect that people are going to agree with you, or consider |
| 46 |
your contribution more correct just because you provided a patch |
| 47 |
or a pull request. And don't expect the developer to take long-term |
| 48 |
responsibility for changes he doesn't understand, use or approve. |
| 49 |
|
| 50 |
As for new packages, the rules are simple -- someone has to maintain |
| 51 |
them. Gentoo is not the kind of zero-maintenance distro where an ebuild |
| 52 |
written once is good forever. With the very limited manpower Gentoo |
| 53 |
has, don't expect people to just take some random package you use |
| 54 |
and maintain it for you if they don't even have any clue what it does. |
| 55 |
|
| 56 |
If you are not going to maintain your contribution, we can't guarantee |
| 57 |
it will be accepted. I'm certainly not interested in having to worry |
| 58 |
about 20 more maintainer-needed packages next month because someone |
| 59 |
contributed an ebuild that seemed good enough. |
| 60 |
|
| 61 |
In this case, less is better than more. A really bad thing is to |
| 62 |
provide something new just to have it removed (or became useless) |
| 63 |
in a month or so. |
| 64 |
|
| 65 |
-- |
| 66 |
Best regards, |
| 67 |
Michał Górny |
| 68 |
<http://dev.gentoo.org/~mgorny/> |
Archives