| 1 |
On 11/21/2014 05:06 PM, Piotr Szymaniak wrote: |
| 2 |
> On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote: |
| 3 |
>> http://packages.gentooexperimental.org/repoman-checks/ |
| 4 |
>> |
| 5 |
>> updated per cron job, split by category. Much easier to handle :) |
| 6 |
>> |
| 7 |
>> Feel free to work on fixing things - there's enough issues that you |
| 8 |
>> won't run out of work this decade. |
| 9 |
> |
| 10 |
> So, lets assume that a lot of users get their hands on fixing things |
| 11 |
> ("lets make Gentoo a better distro!"). What's the work path here? Fix, |
| 12 |
> diff, new bug "I fixed this and that!"? git portage... pull request? |
| 13 |
|
| 14 |
The long answer is: please become a developer, that's really the best |
| 15 |
way. If you're interested in fixing repoman warnings, updating EAPIs, |
| 16 |
and things like that, the QA team might be a good place to look for a |
| 17 |
mentor (#gentoo-qa). |
| 18 |
|
| 19 |
In the meantime, anyone can fill out the quizzes: |
| 20 |
|
| 21 |
http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt |
| 22 |
|
| 23 |
That will save you a lot of time when you do begin the recruitment |
| 24 |
process, since you can just send off the quiz that you already have |
| 25 |
finished. |
| 26 |
|
| 27 |
|
| 28 |
> Just asking, but I know that fixing things that will stay forever on |
| 29 |
> Bugzilla is killing motivation. |
| 30 |
|
| 31 |
Indeed, I know the feeling. To avoid burning out, you'd have to pick |
| 32 |
issues that are likely to actually get fixed. As a non-developer, that |
| 33 |
rules out the areas that could most use the help: maintainer-needed |
| 34 |
packages, and packages belonging only to herds that are essentially |
| 35 |
abandoned. Without the threat of commit access behind you, it's going to |
| 36 |
be next to impossible to fix those. |
| 37 |
|
| 38 |
And stable ebuilds can't be changed, so those are out. |
| 39 |
|
| 40 |
So I would look for ebuilds with active, non-herd maintainers that are |
| 41 |
still in ~arch to work on. And then open bugs that will get assigned to |
| 42 |
the maintainer. A diff against the latest ebuild in the tree is fine. If |
| 43 |
you do find a mentor in QA, I believe they have the authority to fix |
| 44 |
these things, so you might get some help if your fixes are ignored. |
| 45 |
|
| 46 |
Another way you can help out is to find the bugs that belong to upstream |
| 47 |
(e.g. parallel compilation), and submit fixes to their respective bug |
| 48 |
trackers. Then you can open a Gentoo bug pointing to the upstream |
| 49 |
report. When the upstream bug is fixed, the workaround can go away. |
Archives