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

[Michael Jones]

Hopefully some comments from a user / power-user are welcome on this topic.
Just my two cents, is all.

On Tue, Jan 19, 2016 at 12:35 PM, Alec Warner <antarus@g.o> wrote:

> On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@g.o> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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.
>>
>
> Speaking as the dude who founded the treecleaners project...all things
> die. Even software. While some may yearn for a software archive (nee,
> graveyard!), I put forth that the gentoo-x86 tree is not such a thing. Do
> not weep for the unmaintained packages that will be cleaned![1]
>
>
>>
>> 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.
>>
>
> I'm not sure what concrete proposal you are actually making here. Sure I'd
> love for users to actually maintain the software that they want in the
> tree. How do we encourage such behavior?
>
>

An explicit message to the effect of "This package doesn't have a
maintainer, please help" would be a huge push for users like myself to
pitch in. I write small ebuilds for my own projects from time to time, and
occasionally copy official ebuilds into my own overlay to make changes. If
I knew that there was a project that I used that wasn't getting any
official attention, that would light a fire under any users with a similar
mindset to my own.


>> 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).
>>
>
> So how do user contributed changes land (the aforementioned proxy-maint
> team?)
>
>

This is the question that I wanted to address in my reply.

Prior to the Git migration, I would say "Yea, good luck there". But now
it's incredibly easy for users to submit a pull request on the github
mirror, or similar infrastructure.

I know that there has been a lot of debate on how to properly handle that,
and I'm not sure if there was a resolution to that debate. Assuming that
there was a resolution (Or will be), a hyperlink to an appropriate page for
pull requests (or similar mechanism) would drastically increase the number
of "regular users" who were willing to try their hand at contributing.

I think that, as a user, I'd recommend against asking people to file bugs
on bugzilla with ebuilds attached. It's intimidating how many thousands of
bugs there are, and new users might think that the bugzilla isn't actively
used (even though it clearly is). Hopefully that suggestion doesn't cause
too much bike-shedding.



>> 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.
>>
>
> We used to have bugday. I presume the person running it stopped. Feel free
> to start it up again.
>
>
>>
>> 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJWnc1RAAoJEBzZQR2yrxj7WMYQALdOH13N+N0hCuDrCKcFwhp1
>> GjosbY2ZQsqVL8WX46K8I+Kr9EV/JD1LWfB5S24YMANFgk+iAHJUlDebKmbIOUek
>> JiT1eRG8LrIJE3VWfMtJxMfPxzkYEPf+Ew3DXBADekhtWbIb3Ha9hWYGgD/gZ2UN
>> vY0xDBU2oXuJjoSTYwfdbVXG950CgiEfI+QtaeHaMihdqR/ZB7WcHXx788EnnXeA
>> Q9M3JtNbRyLL7UI7XeVzxN7A+ODhN3highYXELdImHR5fZh2T7sm1Limvev5lgaU
>> uiugUMnFbDISqiWLSPFbTaJBwrl0tyqa9hjYnhP9LLj8zIXLe/PN+8hQ7Et8aq8w
>> hRUr6ntm++4HFD2TKySZ4So09yntb+xapeFIM4UjTvN6Tfy2gUyTnpzDdsAlBoHt
>> zhExBzidA+g1syCY5LrMkndP+8iKDDbUlPkMtfldf2XBMXu5jFBfUXKoZRFC9P27
>> XOqneJHcBEjocjvcmnu4BeUz0+Nu3jRpQuGj35hNLTsFyG7Dh9Qw1eJ0mDnCm2PZ
>> YrWWw2Z7nJGKsStwI3Ox6HIeXHuiFGup4XfveC0jE/ggZcK+E9jrkXDbwc9sOPYg
>> WRMsgCHFHke1YgPhOxHA1RSE0bZv5j9CYkJx8piif8c0p1HkPUj93r3zgpycfSRi
>> 35R7+OKBC4AQeIIoCBXI
>> =5UdF
>> -----END PGP SIGNATURE-----
>>
>>
>