[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Running repoman on the portage tree
From:       Michael Orlitzky <mjo () gentoo ! org>
Date:       2014-11-22 1:31:04
Message-ID: 546FE758.6020807 () gentoo ! org
[Download RAW message or body]

On 11/21/2014 05:06 PM, Piotr Szymaniak wrote:
> On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote:
>> http://packages.gentooexperimental.org/repoman-checks/
>>
>> updated per cron job, split by category. Much easier to handle :)
>>
>> Feel free to work on fixing things - there's enough issues that you
>> won't run out of work this decade.
> 
> So, lets assume that a lot of users get their hands on fixing things
> ("lets make Gentoo a better distro!"). What's the work path here?  Fix,
> diff, new bug "I fixed this and that!"? git portage... pull request?

The long answer is: please become a developer, that's really the best
way. If you're interested in fixing repoman warnings, updating EAPIs,
and things like that, the QA team might be a good place to look for a
mentor (#gentoo-qa).

In the meantime, anyone can fill out the quizzes:

  http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt

That will save you a lot of time when you do begin the recruitment
process, since you can just send off the quiz that you already have
finished.


> Just asking, but I know that fixing things that will stay forever on
> Bugzilla is killing motivation.

Indeed, I know the feeling. To avoid burning out, you'd have to pick
issues that are likely to actually get fixed. As a non-developer, that
rules out the areas that could most use the help: maintainer-needed
packages, and packages belonging only to herds that are essentially
abandoned. Without the threat of commit access behind you, it's going to
be next to impossible to fix those.

And stable ebuilds can't be changed, so those are out.

So I would look for ebuilds with active, non-herd maintainers that are
still in ~arch to work on. And then open bugs that will get assigned to
the maintainer. A diff against the latest ebuild in the tree is fine. If
you do find a mentor in QA, I believe they have the authority to fix
these things, so you might get some help if your fixes are ignored.

Another way you can help out is to find the bugs that belong to upstream
(e.g. parallel compilation), and submit fixes to their respective bug
trackers. Then you can open a Gentoo bug pointing to the upstream
report. When the upstream bug is fixed, the workaround can go away.

[prev in list] [next in list] [prev in thread] [next in thread]