| 1 |
Tuesday 19 Jan 2016 00:44:49, NP-Hardass wrote : |
| 2 |
> With all of the unclaimed herds and unclaimed packages within them, I |
| 3 |
> started to wonder what will happen after the GLEP 67 transition |
| 4 |
> finally comes to fruition. This left me with some concerns and I was |
| 5 |
> wondering what the community thinks about them, and some possible |
| 6 |
> solutions. |
| 7 |
> |
| 8 |
> There is a large number of packages from unclaimed herds that, at this |
| 9 |
> time, look like they will not be claimed by developers. This will |
| 10 |
> likely result in a huge increase in maintainer-needed packages (and |
| 11 |
> subsequent package rot). This isn't to say that some of these |
| 12 |
> packages weren't previously in a "maintainer-needed" like state, but |
| 13 |
> now, they will explicitly be there. |
| 14 |
> |
| 15 |
> A possible approach to reducing this is to adopt some new policies. |
| 16 |
> |
| 17 |
> The first of which is an "adopt-a-package" type program. In |
| 18 |
> functionality, this is no different than proxy-maintenance, however, |
| 19 |
> this codifies it into an explicit policy whereby users are encouraged |
| 20 |
> to step and take over a package. This obviously requires a greater |
| 21 |
> developer presence in the proxy-maint project (or something similar), |
| 22 |
> but, personally, I think that a stronger dev presence in proxy-maint |
| 23 |
> would be better for Gentoo as a whole. |
| 24 |
> |
| 25 |
> The second policy change would be that maintainer-needed packages can |
| 26 |
> have updates by anyone while maintaining the standard "you fix it if |
| 27 |
> you break it" policy. This would extend to users as well. With the |
| 28 |
> increased ease that users can contribute via git/github, they should |
| 29 |
> be encouraged to contribute and have their efforts facilitated to ease |
| 30 |
> contributions to whatever packages they desire (within the |
| 31 |
> maintainer-needed category). |
| 32 |
> |
| 33 |
> Similar to the concept of a "bugday," coupled with above, an |
| 34 |
> "ebuildday" where users and devs get together so users can learn to |
| 35 |
> write ebuilds and for devs to work together to maintain packages that |
| 36 |
> usually fall outside their normal workload could prove beneficial to |
| 37 |
> the overall health of Gentoo packaging. |
| 38 |
> |
| 39 |
> Once again, these are just some random musings inspired by recent |
| 40 |
> events on the dev ML, and thought it might be worth discussing. |
| 41 |
> I've cc'd proxy-maint as a lot of this discussion is likely to involve |
| 42 |
> them, and would like them to put in their official opinion as well. |
| 43 |
> |
| 44 |
> |
| 45 |
> -- |
| 46 |
> NP-Hardass |
| 47 |
|
| 48 |
More food for thought on the topic of "what do we do with maintainer-wanted |
| 49 |
packages". |
| 50 |
|
| 51 |
NP-Hardass I quite like your idea but what about clearing down the massive |
| 52 |
queue of reports assigned to maintainer-wanted first? |
| 53 |
|
| 54 |
Right now, the number of bug reports assigned to maintainer-wanted amounts to |
| 55 |
over 4k: http://tiny.cc/maintainer_wanted |
| 56 |
|
| 57 |
There's literally a slew of reports we can mark as WONTFIX / OBSOLETE because, |
| 58 |
well, some of these bugs are over 10 years old (!) and a lot of projects have |
| 59 |
stalled / are dead by now / or the industry has moved on. It has to be done at |
| 60 |
some point anyway so better now than later. And the upside is that it doesn't |
| 61 |
require ebuild skills or knowing Gentoo by heart: only clicking links and |
| 62 |
checking whether projects are still alive. |
| 63 |
|
| 64 |
What do you think? |
| 65 |
|
| 66 |
-- |
| 67 |
Patrice Clement |
| 68 |
Gentoo Linux developer |
| 69 |
http://www.gentoo.org |
Archives