Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Ian Delaney]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512



On Sat, 23 Jan 2016 12:12:57 +0100

Patrice Clement <monsieurp@g.o> wrote:



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


On behalf of the proxy-maintainers project, it is perhaps fitting to

reply to this around the time the actual switch is to occur; from the

citing of herd to the new versioned projects, and so forth. 



This topic touches on the potential impact upon the orphaned package

list known as maintainer-needed. Patrice has more or less pulled in the

associated list of bugs under maintainer-wanted. The two combined boast

an awesome tally. 



In brief, the proxy-maintainer project has had a significant change of

face in the last 6 or so months. While it had some momentum as a

vehicle in which users can proxy maintain packages and overshadowing

sunrise, it almost collapsed into a memory of history at election time

when the lead elected to not be nominated for election, then promptly

withdrew from the project entirely, no-one nominated anyone else and

consequently no-one voted for anyone else in a typical non election.

Having accidentally missed the election period, in collaboration with

jlec & mrueg, it was endorsed that I took the lead role, and

concurrently created the channel #gentoo-proxy-maint. Clearly, this is

not common knowledge since some responders to this thread have pointed

users at gentoo-dev-help as a source of support, quite unaware of the

existence of the channel, let alone the rate of activity it generates,

arguably possessing the longest logs of any given day in any gentoo

channel since its inception. Such is the state of activity of users

discussing gentoo and working ebuilds and pull requests, and various

cakes, on a daily basis. The release of the Reviewer's project also

give it an automatic boost.



While the project was forged on the notion of users picking up packages

from the orphaned package list, it has simply added to its 'raison

dêtre' by users maintaining new packages to portage under the

supervision of the devs of the project. This came into vogue before I

joined. What this has done is to generate a need for extended policies

given the expanded activities and the permutations that come with them.



With regard to this thread, the points that relate are:



1. the impact of the addition of packages to the maintainer-wanted

list,

2. the existence of the maintainer-wanted list in its own right

3. The practices and policies in the proxy-maintainers project in its

current period

4. The notion of bugday and ebuild day floated and re-cited in the

initial thread.

5. Documentation and record / stats keeping performed within the

modern day gentoo.



The purpose here is to state a stance on behalf of the

proxy-maintainers project relative to its place re the above issues /

processes. Keeping it brief has already proven nigh on impossible.



As much as it urks, in this case I shall have to side with mgorny's

'stance on issue number 1. 



"this isn't going to be some kind of huge growth. Right now I can count

380 new maintainer-needed packages, from which some will most likely be

mapped. I would estimate the final outcome to around 300 packages,

maybe less"



The notion that the "fallthrough" of around 300 packages has cause

some to anticipate a possible flurry of activity upon the

proxy-maintainers project since it is the only project designated to

deal directly with the orphaned package list. Frankly, mgorny's

approach here rings true; it may end up being a big meh. It is merely

speculation that the "shuffling come loss" of any distinguishable

ownership will cause ripples of activity in the project. Firstly, the

project requires devs and users willing to grab the packages and commit

changes to the tree. As a broad statement of response, the project is

ready and able if the cause arises. If I had not reshaped it to what it

is, the list of users and devs of the channel would not exist. The

project itself likely would not exist as a recognizable functioning

entity. This isn't a case of blowing my own horn, this is merely a

summary of a series of observable and recorded events.



As the replies have already illustrated, there are many permutations

of states possible to this shuffled list. To pre-empt them is frankly

foolhardy.



2. The maintainer-wanted list. monsieurp has included this in the mix

in a prior reply in this thread. After some inhouse discussion with the

most active current key members, it's apparent that some see little

value in investing time and effort into culling and, in fact finally

directly dealing with, on embarrassingly huge history of inattention

and outright shunning by the developer community towards legitimately

presented requests by users. Others in fact do. (Horses for courses)

While the project has no duty towards dealing with this small mountain,

it does represent 'work', under a package manager banner, that can be

executed by advanced and willing users, overseered by a developer or

two, that also qualifies as legitimate training exercises in the

acquisition / development of the skill set required to become a

developer. All this is consistent with the overall mission of this

project. While neither obliged nor pressured, there are already some

users of the member's list who have begun an assault on this formidable

and ancient list. 



3. With recent policies added to the wiki page of the project, it is

adequately equipped to deal with what may spill forth form the switch.

The page has had a section added by monsieurp which I edited (mostly for

grammar and style), and a link to a new page; Project:Proxy

Maintainers/Maintainer Wanted, dealing precisely with the points

raised by monsieurp in his (previous) reply. They have a set of

criteria with which to make the decisions required to manage the bugs.



4. The bugday is merely an entry in the pages of bugs I have never

seen enacted, or organised, and acted upon.  Frankly, an ebuild, while

a viable idea, sounds like what we do in the channel most days.

However, an idea or activity of this type, albeit a repetition of a day

in the life of the proxy-maintainers, still makes for a legit addition

to what gentoo cam make available to nay users who may attend,

assisting in the learning curve that must be trodden by any user, or

mentoree, keen to advance their skills. This remains, traditionally,

an endemic gap in the fabric that is modern gentoo environment.



5. At the risk of sounding like Patrick, gentoo lacks some forms of

documentation pertaining to established proxy maintainers and to forms

of stats analysis. In discussions, points were raised regarding the

gathering of stats data re packages' tally of downloads and instances

of emerging into a gentoo system. Most of the desired stats appear to

lack any form of tools available to gather and report data that would

prove helpful in evaluating packages of either the m-w or m-n lists.



The topic of recruitment and recruiting are tied, but imo, quite

disparate. 





- -- 

kind regards



Ian Delaney

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.1



iQJ8BAEBCgBmBQJWpOAmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w

ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw

QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6ECAQAJnDqx7EBbAa8tl5/A9HiF6t

8ajaf9NqJYYQZApNjaa6SY60/EP7a5trYW7QOGxE8EvRpNDYlxRIzTZZmb2uCsER

GOgovqYAelaPhwBBGYGGU91i4wKtJ+U+ujrFRLb3eE9Bsv3NcOOzhRIn6zWr9KuB

OBkwYHi37xc8WUsJKR7rBjmOx+OG5Izs5z4gRF3BZVV3+MHgH2zb6Q4W4u13lhOg

BtYBqN5/Y52bzFKgcX0tYeTt9xoYI/Zk1szwX1M3rYizKmYGZwh/lCmUO7PA+Q8V

ZoRhHAaZIgm4eRScnoQBWWm8aStw9nFFRIWcxRKVIx5aEYODWcFz6JEO/zKseNqD

LH/67ssc1/y4JIw0MbZ1YyFrouATs0TnSgbJzKAiMLSJsjHI+EEjdKyEhlRVLVHk

FjM3RzyGTcZWfzFBWXKdYgfCR2GzJZ4Q3rYMZKZARW2t1om1pRJo6JK66JHDErVA

GQiQpEsGQgjOFmp1DyhEJpziBIuTL6l8TwaLamqvJeWhgFEzuaqqfv+Lh/5H8jFB

ghRYkeGiqX6p1pPV+bBYNfxrAlpNeNRoyyKt8Jupuwnr63QA1QevBko/2ngfNgGl

5OQBJhcjs+BJ4KlS/3X1v5rKqSK/eLf1Yy87CY52+2P2rEabfKjB8JHxzu6E7O7/

XaQEesz4Egp1ZOrfMJC+

=sq9P

-----END PGP SIGNATURE-----