| 1 |
> > Even if we went to a review-based workflow, we would STILL need to vet |
| 2 |
> > new reviewers in some way, so we'd still have many of the same |
| 3 |
> > challenges. If anything the role of a reviewer is even more difficult |
| 4 |
> > to fill than a committer, since committers have the freedom to only |
| 5 |
> > work on the stuff they want to work on but if we want review to |
| 6 |
> > actually work we need reviewers to cover anything the committers want |
| 7 |
> > to work on. |
| 8 |
> |
| 9 |
> Nah. You don't assign someone to review EVERYTHING for a single person. |
| 10 |
> Why would you do that? It doesn't work. |
| 11 |
> |
| 12 |
> The point is... that the line between regular contributor and "gentoo |
| 13 |
> dev" doesn't matter much for many people and that means they are not |
| 14 |
> really interested in taking much effort to overcome that line. |
| 15 |
|
| 16 |
OK I'll be really happy once we have git working properly and I can merge pull |
| 17 |
requests, since I know several people who are going to submit good code that |
| 18 |
way. |
| 19 |
|
| 20 |
That said... |
| 21 |
|
| 22 |
Doing a thorough review of submitted code can be harder than writing it |
| 23 |
yourself. If I merge, I'm responsible for it. Which is why I am not entirely |
| 24 |
happy with a pull request based workflow... To put it blunt and exaggerate, |
| 25 |
why should I put in a lot of work and take over responsibility for a bunch of |
| 26 |
lazies who want to contribute somehow but feel disinclined to do it properly? |
| 27 |
|
| 28 |
The recruiting is the process where people prove they can themselves take |
| 29 |
responsibility for our users and are willing to do it. |
| 30 |
|
| 31 |
I hear again and again that opensource is about fun. The moment when this |
| 32 |
fails is when your "product" has a large userbase that relies on it. If you |
| 33 |
base your decisions on how much fun you have coding alone and not on the |
| 34 |
impact on your users and your responsibility to them, you end up pissing off a |
| 35 |
lot of people and just prove yourself immature. (KDEPIM 4.6 comes to my mind.) |
| 36 |
|
| 37 |
> I've been asked recently by a community member if he should bother to |
| 38 |
> try to become a gentoo dev, because he heard it's a pain. |
| 39 |
> Then again... regularly contributing to gentoo via bug reports is even |
| 40 |
> more a pain... so he's just running yet another personal overlay. |
| 41 |
|
| 42 |
Yes. Exactly. 100% true. We all know this situation. |
| 43 |
|
| 44 |
So, as you point out, a decentral operation is one solution (reduced core |
| 45 |
repository, more overlays). What it means though is that all quality control |
| 46 |
measures in place (security team, arch team, qa team, rules what needs |
| 47 |
discussion on the lists, ...) only apply to the main tree, and the overlays |
| 48 |
slip out of it. Which is something that I plainly do not want. Even if things |
| 49 |
do not work perfectly now, we'd still lose far too much. |
| 50 |
|
| 51 |
Here's my answer to your contributor: "It's great that you're considering it, |
| 52 |
and we're happy to help you. It's worth becoming a full dev, since you have |
| 53 |
far more possibilities to directly contribute and also influence where Gentoo |
| 54 |
is going. However, it's going to be some work and it will need some |
| 55 |
commitment." |
| 56 |
|
| 57 |
> The fact that projects like proxy-maintainers and sunrise have to exist |
| 58 |
> are proof that we are doing something wrong! I'm not discrediting any of |
| 59 |
> those. They fill a gap, but the question is... why do we have that gap |
| 60 |
> in the first place? |
| 61 |
|
| 62 |
Because you can't answer the quizzes in 166 characters and submit them via |
| 63 |
Instagram? |
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
Andreas K. Huettel |
| 68 |
Gentoo Linux developer |
| 69 |
perl, office, comrel, council |
Archives