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

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

[NP-Hardass]

-----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.

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
-----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-----

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

[Duncan]

NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:

> "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.

That gave me the idea of a maintainer-needed eclass.  When packages are 
set to maintainer-needed, they can simply inherit this eclass and add 
whatever function to the pkg_postinst, that will add a message that will 
in effect say "adopt-me please", probably printing a proxy-maintainer 
invitation URL to go to for more information.

Talking about pkg_postinst messages, unless I missed it there's no simple 
way to add a one ATM, without coding up the whole function, making it 
problematic for eclasses, etc.  For EAPI-7, what about either a helper 
function that can be called, or an array variable that can be simply 
added to, that simply adds the supplied message to a list of messages 
printed at pkg_postinst time, and of course an appropriate 
default_pkg_postinst to go along with it?  Then ebuilds and eclasses can 
call this helper or set this var in whatever phase they need to, and the 
message will be printed at pkg_postinst time without having to worry 
about setting up your own pkg_postinst or stepping on anything 
pkg_postinst related setup elsewhere.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Göktürk Yüksek]

Duncan:
> NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:
> 
>> "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.
> 
> That gave me the idea of a maintainer-needed eclass.  When packages are 
> set to maintainer-needed, they can simply inherit this eclass and add 
> whatever function to the pkg_postinst, that will add a message that will 
> in effect say "adopt-me please", probably printing a proxy-maintainer 
> invitation URL to go to for more information.
> 
> Talking about pkg_postinst messages, unless I missed it there's no simple 
> way to add a one ATM, without coding up the whole function, making it 
> problematic for eclasses, etc.  For EAPI-7, what about either a helper 
> function that can be called, or an array variable that can be simply 
> added to, that simply adds the supplied message to a list of messages 
> printed at pkg_postinst time, and of course an appropriate 
> default_pkg_postinst to go along with it?  Then ebuilds and eclasses can 
> call this helper or set this var in whatever phase they need to, and the 
> message will be printed at pkg_postinst time without having to worry 
> about setting up your own pkg_postinst or stepping on anything 
> pkg_postinst related setup elsewhere.
> 
See:
sys-apps/portage: show an elog message when merged package is maintained
by maintainer-needed
https://bugs.gentoo.org/show_bug.cgi?id=398633

Can we reconsider implementing this idea perhaps?

--
gokturk

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

[Ian Delaney]

On Tue, 19 Jan 2016 22:02:21 -0500
Göktürk Yüksek <gokturk@binghamton.edu> wrote:

> Duncan:
> > NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:
> >   
>  [...]  
> > 
> > That gave me the idea of a maintainer-needed eclass.  When packages
> > are set to maintainer-needed, they can simply inherit this eclass
> > and add whatever function to the pkg_postinst, that will add a
> > message that will in effect say "adopt-me please", probably
> > printing a proxy-maintainer invitation URL to go to for more
> > information.
> > 
> > Talking about pkg_postinst messages, unless I missed it there's no
> > simple way to add a one ATM, without coding up the whole function,
> > making it problematic for eclasses, etc.  For EAPI-7, what about
> > either a helper function that can be called, or an array variable
> > that can be simply added to, that simply adds the supplied message
> > to a list of messages printed at pkg_postinst time, and of course
> > an appropriate default_pkg_postinst to go along with it?  Then
> > ebuilds and eclasses can call this helper or set this var in
> > whatever phase they need to, and the message will be printed at
> > pkg_postinst time without having to worry about setting up your own
> > pkg_postinst or stepping on anything pkg_postinst related setup
> > elsewhere. 
> See:
> sys-apps/portage: show an elog message when merged package is
> maintained by maintainer-needed
> https://bugs.gentoo.org/show_bug.cgi?id=398633
> 
> Can we reconsider implementing this idea perhaps?
> 

Given the thrust of this whole discussion this is a good idea. It
naturally advertises packages of this unmaintained status to users as
they emerge.

> --
> gokturk
> 
> 



-- 
kind regards

Ian Delaney

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

On Sat, 23 Jan 2016 21:04:56 +0800 Ian Delaney wrote:
> On Tue, 19 Jan 2016 22:02:21 -0500
> Göktürk Yüksek <gokturk@binghamton.edu> wrote:
> 
> > Duncan:
> > > NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:
> > >   
> >  [...]  
> > > 
> > > That gave me the idea of a maintainer-needed eclass.  When packages
> > > are set to maintainer-needed, they can simply inherit this eclass
> > > and add whatever function to the pkg_postinst, that will add a
> > > message that will in effect say "adopt-me please", probably
> > > printing a proxy-maintainer invitation URL to go to for more
> > > information.
> > > 
> > > Talking about pkg_postinst messages, unless I missed it there's no
> > > simple way to add a one ATM, without coding up the whole function,
> > > making it problematic for eclasses, etc.  For EAPI-7, what about
> > > either a helper function that can be called, or an array variable
> > > that can be simply added to, that simply adds the supplied message
> > > to a list of messages printed at pkg_postinst time, and of course
> > > an appropriate default_pkg_postinst to go along with it?  Then
> > > ebuilds and eclasses can call this helper or set this var in
> > > whatever phase they need to, and the message will be printed at
> > > pkg_postinst time without having to worry about setting up your own
> > > pkg_postinst or stepping on anything pkg_postinst related setup
> > > elsewhere. 
> > See:
> > sys-apps/portage: show an elog message when merged package is
> > maintained by maintainer-needed
> > https://bugs.gentoo.org/show_bug.cgi?id=398633
> > 
> > Can we reconsider implementing this idea perhaps?
> > 
> 
> Given the thrust of this whole discussion this is a good idea. It
> naturally advertises packages of this unmaintained status to users as
> they emerge.
 
Please make this optional. Elog already contains too much
information and it is already hard to read logs after world update
or other massive change. It literally takes hours sometimes.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[waltdnes]

On Sat, Jan 23, 2016 at 10:54:01PM +0300, Andrew Savchenko wrote

> Please make this optional. Elog already contains too much information
> and it is already hard to read logs after world update or other
> massive change. It literally takes hours sometimes.

  Agreed 100%.  I filed a successfull bug request last month to remove
the "ewarn" about English word lists being dropped from default vim
install 2 years ago https://bugs.gentoo.org/show_bug.cgi?id=569056  The
last thing I want is more ewarns.

  A better policy may be to keyword them, e.g. ~amd64 ~x86, etc.  This
would be reasonable, because there is actually a valid reason to do so.
I.e. users would be using unmaintained software.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3936 bytes --]

On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@gentoo.org> 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?


>
> 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?)


>
> 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-----
>
>

[-- Attachment #2: Type: text/html, Size: 5114 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:
> On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@gentoo.org> 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]

I couldn't have said this better myself. The gentoo-x86 tree is not a
software archival service. If packages are unmaintained, that is what
the treecleaners project is for is to boot those packages out of the
tree.

I would like to see a possible timelimit set on how long packages can
stay in maintainer-needed; once a package goes there, if we can't find
someone to maintain it, we should consider booting it after that time
limit passes.

If someone wants to run the graveyard overlay and keep those old
packages around more power to them, but they definitely do not
belong in the main tree if they are unmaintained for an extended period
of time.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Alexis Ballier]

On Thu, 21 Jan 2016 10:53:58 -0600
William Hubbs <williamh@gentoo.org> wrote:

> I would like to see a possible timelimit set on how long packages can
> stay in maintainer-needed; once a package goes there, if we can't find
> someone to maintain it, we should consider booting it after that time
> limit passes.

Note that maintainer-needed doesn't necessarily mean package is crap.
Some simply don't really need a maintainer because they just work.

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 992 bytes --]

On 01/21/2016 06:15 PM, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 10:53:58 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> I would like to see a possible timelimit set on how long packages can
>> stay in maintainer-needed; once a package goes there, if we can't find
>> someone to maintain it, we should consider booting it after that time
>> limit passes.
> 
> Note that maintainer-needed doesn't necessarily mean package is crap.
> Some simply don't really need a maintainer because they just work.
> 
> 

However it can cause complications when issues are detected, in
particular security relevant ones. Attaching a CSV of bugs assigned to
security with maintainer-needed CCed.

e.g app-text/htmltidy has multiple reverse dependecies but is itself
maintainer needed with at least two vulnerabilities (bug 561452)

-- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: bugs-2016-01-21.csv --]
[-- Type: text/csv; name="bugs-2016-01-21.csv", Size: 2962 bytes --]

"Bug ID","Product","Component","Assignee","Status","Resolution","Summary","Changed"
571824,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","dev-db/firebird: authenticated remote crash by gbak invocation","2016-01-14 09:47:30"
537524,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-arch/ppmd: directory traversal","2016-01-10 17:07:17"
551144,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","<media-libs/libwmf-0.2.8.4-r6: heap overflow when decoding BMP images (CVE-2015-0848)","2016-01-10 14:20:56"
553818,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","<media-libs/libwmf-0.2.8.4-r6: Denial of Service (CVE-2015-{4588,4695,4696})","2016-01-10 10:41:41"
535708,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","<app-arch/arj-3.10.22-r5: two vulnerabilities (CVE-2015-{0556,0557})","2016-01-09 07:11:06"
561452,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-text/htmltidy: Two Denial of Service Vulnerabilities (CVE-2015-{5522,5523})","2016-01-08 14:11:28"
553604,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","net-mail/checkpw: DoS vulnerability (CVE-2015-0885)","2016-01-06 13:59:53"
537528,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-admin/usermin: Read Mail Module Vulnerability","2016-01-06 13:36:12"
536334,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","net-nds/389-ds-base: Information disclosure vulnerability (CVE-2014-3562)","2016-01-06 13:30:52"
515272,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","net-misc/italc: LZO Denial of Service and Arbitrary Code Execution through embedded code","2016-01-06 13:15:41"
499328,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","sys-apps/yum : ""YumCronBase()"" Package Spoofing Vulnerability (CVE-2014-0022)","2016-01-05 11:23:14"
541500,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-arch/arj: buffer overflow write access initiated by a size read from a crafted archive (CVE-2015-2782)","2015-12-31 04:57:10"
568398,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","dev-util/nsis: privilege escalation and code execution vulnerabilities in generated NSIS installers","2015-12-16 08:24:43"
562898,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-admin/lsyncd: Direct mode allwos injecting unauthorized filesystem operations","2015-11-29 16:41:48"
537522,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-arch/pax: directory traversal (CVE-2015-{1193,1194})","2015-11-25 04:33:59"
534184,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-misc/run-mailcap: Command Injection","2015-11-04 15:23:24"
548142,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","net-nds/389-ds-base: access control bypass with modrdn","2015-04-29 15:53:29"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Alexis Ballier]

On Thu, 21 Jan 2016 18:25:21 +0100
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 01/21/2016 06:15 PM, Alexis Ballier wrote:
> > On Thu, 21 Jan 2016 10:53:58 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> >   
> >> I would like to see a possible timelimit set on how long packages
> >> can stay in maintainer-needed; once a package goes there, if we
> >> can't find someone to maintain it, we should consider booting it
> >> after that time limit passes.  
> > 
> > Note that maintainer-needed doesn't necessarily mean package is
> > crap. Some simply don't really need a maintainer because they just
> > work.
> > 
> >   
> 
> However it can cause complications when issues are detected, in
> particular security relevant ones. Attaching a CSV of bugs assigned to
> security with maintainer-needed CCed.
> 
> e.g app-text/htmltidy has multiple reverse dependecies but is itself
> maintainer needed with at least two vulnerabilities (bug 561452)
> 

well, 'not ( forall x, x is m-n, x is crap )' and 'exists x, x is
m-n, x is crap' don't necessarily disagree either :)

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

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/21/2016 06:30 PM, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 18:25:21 +0100 Kristian Fiskerstrand
> <k_f@gentoo.org> wrote:
> 


>> However it can cause complications when issues are detected, in 
>> particular security relevant ones. Attaching a CSV of bugs
>> assigned to security with maintainer-needed CCed.
>> 
>> e.g app-text/htmltidy has multiple reverse dependecies but is
>> itself maintainer needed with at least two vulnerabilities (bug
>> 561452)
>> 
> 
> well, 'not ( forall x, x is m-n, x is crap )' and 'exists x, x is 
> m-n, x is crap' don't necessarily disagree either :)
> 

Indeed, however it does cause issues with assignment when security
vulnerabilities are reported, as nobody is CCed to handle it if m-n.
So this list needs to be actively maintained and treecleaning is
difficult with reverse deps involved.

... we might get around this by amending procedures to CC every
maintainer of reverse deps in these cases though (and if no rdep
simply treeclean it).

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWoRb4AAoJECULev7WN52F4ZMH/i4c5tSxJqgPmJY07c4qFkfL
N2cNWz+lRe9xr/VQxS9kLwG9IlqEJMMe4A6f2MvIeKwgN3A+HpLHQrEfK7we6Ctl
+wy25IxEWbfk8ajuXU89qYN29CIeZcunhcNkA/5WvZSI4fiakxMkP2aDq9nSl+t3
VJ5V54jVEQGvS4vBcR8hKSU7uW5fnwWFIRxV4TFeD+wQNEIDdF8dMEvvqdJUpKuj
5LzlLnXXjBW9vB53wM8n0BsufLVOK/xU1Cx8AJabqmoUX5O+NdlDTXks2r/yuVUk
YAze94Pb4oFKUSsQ0eHObr7vXXkpFQgwA4c4H0u75y5zAtaSDQFJ+8Fg7qIvb1k=
=NQwO
-----END PGP SIGNATURE-----

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

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On 2016.01.21 16:53, William Hubbs wrote:
> On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:
> > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@gentoo.org>
> 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]
> 
> I couldn't have said this better myself. The gentoo-x86 tree is not a
> software archival service. If packages are unmaintained, that is what
> the treecleaners project is for is to boot those packages out of the
> tree.
> 
> I would like to see a possible timelimit set on how long packages can
> stay in maintainer-needed; once a package goes there, if we can't find
> someone to maintain it, we should consider booting it after that time
> limit passes.
> 
> If someone wants to run the graveyard overlay and keep those old
> packages around more power to them, but they definitely do not
> belong in the main tree if they are unmaintained for an extended
> period
> of time.
> 
> William
> 
> 

There is no point in removing unmaintained but perfectly functional software from the tree.
It needs to be both unmaintained and broken. Broken being evidenced by at least one open bug.

How would you define unmaintained?
Maybe its not changed for a year or two because there is no need for any maintenance?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

On Thu, 21 Jan 2016 17:25:02 +0000
Roy Bamford <neddyseagoon@gentoo.org> wrote:

> On 2016.01.21 16:53, William Hubbs wrote:
> > On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:  
> > > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@gentoo.org>  
> > 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]  
> > 
> > I couldn't have said this better myself. The gentoo-x86 tree is not a
> > software archival service. If packages are unmaintained, that is what
> > the treecleaners project is for is to boot those packages out of the
> > tree.
> > 
> > I would like to see a possible timelimit set on how long packages can
> > stay in maintainer-needed; once a package goes there, if we can't find
> > someone to maintain it, we should consider booting it after that time
> > limit passes.
> > 
> > If someone wants to run the graveyard overlay and keep those old
> > packages around more power to them, but they definitely do not
> > belong in the main tree if they are unmaintained for an extended
> > period
> > of time.
> > 
> > William
> > 
> >   
> 
> There is no point in removing unmaintained but perfectly functional software from the tree.
> It needs to be both unmaintained and broken. Broken being evidenced by at least one open bug.

That's nonsense. In fact, that's exactly the opposite of what should be
removed.

If I see a package that clearly doesn't build or otherwise simply
doesn't work, could not have worked for past 3 years, are you forcing
me to waste a time reporting a bug to no maintainer who could fix it?

Because to me, the lack of any open bugs is a clear evidence that
the package is not only unmaintained, but also unused.


-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[waltdnes]

On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
> On Thu, 21 Jan 2016 17:25:02 +0000
> Roy Bamford <neddyseagoon@gentoo.org> wrote:
> 
> > There is no point in removing unmaintained but perfectly functional
> > software from the tree.  It needs to be both unmaintained and broken.
> > Broken being evidenced by at least one open bug.
> 
> That's nonsense. In fact, that's exactly the opposite of what should
> be removed.
> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?

  I think you misunderstood Roy.  He was speaking about "unmaintained
but perfectly functional software".  You're talking about "a package
that clearly doesn't build or otherwise simply doesn't work, could not
have worked for past 3 years".  Between those 2 extremes will be many
cases of doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?

  Maybe we should start a "gentoo-ebuilds" mailing list to help regular
users learn the ins and outs of making ebuilds.  Once regular users run
a lot of their own ebuilds from their local overlays, then it would be
possible to do draconian pruning of the "official portage tree", without
so adversely affecting regular users.  This would fit in with the mantra
of Gentoo being about freedom of choice.

  E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to build
as regular user, su, and copy the binary to /usr/local.  You can see
"Walter's excellent adventure" <G> as I learn the build process at...
https://forum.palemoon.org/viewtopic.php?f=37&t=10002

  I'd like to have Portage manage the process.  The ebuild from Firefox
should serve as a template, because they both use the same weird Mozilla
build setup.  The main change should be where the source is pulled from.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Rich Freeman]

On Thu, Jan 21, 2016 at 5:41 PM,  <waltdnes@waltdnes.org> wrote:
>   I think you misunderstood Roy.  He was speaking about "unmaintained
> but perfectly functional software".  You're talking about "a package
> that clearly doesn't build or otherwise simply doesn't work, could not
> have worked for past 3 years".  Between those 2 extremes will be many
> cases of doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?
>

I don't think we need any kind of formalized policy.  The treecleaners
can make a decision and there doesn't need to be any appeals.

The treecleaners should remove packages that are both unmaintained and
broken.  They don't have to have bugs open, and simply having a bug
open for a long time shouldn't be a reason to treeclean on its own.
If a package has a security issue or is just generally crippled then
it should be removed.  That might sound a bit subjective, but I don't
think that is a problem - if the treecleaners want to make a statement
of policy they can do so.

And if somebody disagrees with the treecleaners then they can go ahead
and volunteer to maintain the package.  Maintainers aren't actually
obligated to fix non-security bugs at all, by the way (though doing so
would certainly be nice).  But, they'll get to listen to all the grief
about problems they cause instead of the treecleaners.  Obviously if
things get out of hand there are ways to escalate.

In any case, I consider the labeling of these unmaintained packages as
maintainer-needed as a good thing, even if some get treecleaned as a
result.  Part of our social contract is not hiding problems.
Unmaintained packages should be clearly labeled as such.  And I'm all
for some suggestions that have been offered to hghlight packages they
use which are unmaintained (I'd suggest that instead of messing with
eclasses we simply put that feature in portage though).

-- 
Rich

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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/21/2016 02:41 PM, waltdnes@waltdnes.org wrote:
> On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
>> On Thu, 21 Jan 2016 17:25:02 +0000 Roy Bamford
>> <neddyseagoon@gentoo.org> wrote:
>> 
>>> There is no point in removing unmaintained but perfectly
>>> functional software from the tree.  It needs to be both
>>> unmaintained and broken. Broken being evidenced by at least one
>>> open bug.
>> 
>> That's nonsense. In fact, that's exactly the opposite of what
>> should be removed.
>> 
>> If I see a package that clearly doesn't build or otherwise
>> simply doesn't work, could not have worked for past 3 years, are
>> you forcing me to waste a time reporting a bug to no maintainer
>> who could fix it?
> 
> I think you misunderstood Roy.  He was speaking about
> "unmaintained but perfectly functional software".  You're talking
> about "a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years".  Between
> those 2 extremes will be many cases of
> doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?
> 
> Maybe we should start a "gentoo-ebuilds" mailing list to help
> regular users learn the ins and outs of making ebuilds.  Once
> regular users run a lot of their own ebuilds from their local
> overlays, then it would be possible to do draconian pruning of the
> "official portage tree", without so adversely affecting regular
> users.  This would fit in with the mantra of Gentoo being about
> freedom of choice.
> 
> E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to
> build as regular user, su, and copy the binary to /usr/local.  You
> can see "Walter's excellent adventure" <G> as I learn the build
> process at... 
> https://forum.palemoon.org/viewtopic.php?f=37&t=10002
> 
> I'd like to have Portage manage the process.  The ebuild from
> Firefox should serve as a template, because they both use the same
> weird Mozilla build setup.  The main change should be where the
> source is pulled from.
> 

The idea sounds nice, but there's already the devmanual to cover
ebuild development, and now that the gentoo repo is in git, any
ebuilds that get treecleaned can be fetched again through history, and
users can then add those to their personal overlay(s) and keep the
piece if they break.

I like the idea of encouraging people to learn good ebuild writing,
but who really has the time and skill to teach it?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWoXgPAAoJEAEkDpRQOeFwPvUP/1cOdVx0Mnm2yF6DU9BCXCzn
6LdE4/g05CnkggQkQEPsL6U+oiU/C2wu9nsSSRwrHNKEoIvly/pZEz75+FFoEnF5
RQTltJQi4lyG63bzaHYCx1nzmqAHBVbCBGDPqEC8whV8C8YAufk3SxqocBaIsD5Z
IbujCelJNGvRGBPmsIOD38aaVbcyJZFGG+m9nTTJyRQtdFGxfccE/K+xuZMLKFS/
BQkyJdAyvGscRBLAx80o5TgZ+h7BTNW78b8aIubWaeMyqYrvQhdwaDTK7xj0cb5M
uxC7fg493PphNLLYY5sL9yHPKtyJzuWhE6r9IXtMSH3b8sTEUU4cXxF4Ep1af+k0
9BafYy+vAxv6fM/3VS8KGcGCwElNrCiNLJYjEdW7mCDRFNQR8cja5IVRF8KGlXD3
33eKUviyPtx9LB5GNS2bZNSayeJbIENr1LsY2gZ4C6nfXUOzsUp7KhM4P4WmFKWV
TOn/DbigDQjMa07L0+G+cwvrc2X2QJWG8kstD16iARvaRAnlvlO+HQeSAtO1LWwU
7O44z0eQDxpGO6RZrBDVKNGe8dAaObQT+ueCL/sOHV2Co71Iz8zCu8z75OIhSWWM
8Tu4pa+doFetFLmOkfkcFTxuAjcxJAJomxnLD9rNcdjDtuWF2wxATdWFruFmYPm+
u0/PNb0YQg4Xx5M2qV63
=FxNx
-----END PGP SIGNATURE-----

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

[Ian Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, 21 Jan 2016 16:30:14 -0800
Daniel Campbell <zlg@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 01/21/2016 02:41 PM, waltdnes@waltdnes.org wrote:
> > On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote  
>  [...]  
>  [...]  
>  [...]  
> > 
> > I think you misunderstood Roy.  He was speaking about
> > "unmaintained but perfectly functional software".  You're talking
> > about "a package that clearly doesn't build or otherwise simply
> > doesn't work, could not have worked for past 3 years".  Between
> > those 2 extremes will be many cases of
> > doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?
> > 
> > Maybe we should start a "gentoo-ebuilds" mailing list to help
> > regular users learn the ins and outs of making ebuilds.  Once
> > regular users run a lot of their own ebuilds from their local
> > overlays, then it would be possible to do draconian pruning of the
> > "official portage tree", without so adversely affecting regular
> > users.  This would fit in with the mantra of Gentoo being about
> > freedom of choice.
> > 
> > E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to
> > build as regular user, su, and copy the binary to /usr/local.  You
> > can see "Walter's excellent adventure" <G> as I learn the build
> > process at... 
> > https://forum.palemoon.org/viewtopic.php?f=37&t=10002
> > 
> > I'd like to have Portage manage the process.  The ebuild from
> > Firefox should serve as a template, because they both use the same
> > weird Mozilla build setup.  The main change should be where the
> > source is pulled from.
> >   
> 
> The idea sounds nice, but there's already the devmanual to cover
> ebuild development, and now that the gentoo repo is in git, any
> ebuilds that get treecleaned can be fetched again through history, and
> users can then add those to their personal overlay(s) and keep the
> piece if they break.
> 
> I like the idea of encouraging people to learn good ebuild writing,
> but who really has the time and skill to teach it?
> 

me. Been doing it for months. You had not noticed? via
#gentoo-proxy-maint, which I made from scratch, despite the notion
initially being discounted by one mrueg. He now is a colleague in the
channel.

> - -- 
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWoXgPAAoJEAEkDpRQOeFwPvUP/1cOdVx0Mnm2yF6DU9BCXCzn
> 6LdE4/g05CnkggQkQEPsL6U+oiU/C2wu9nsSSRwrHNKEoIvly/pZEz75+FFoEnF5
> RQTltJQi4lyG63bzaHYCx1nzmqAHBVbCBGDPqEC8whV8C8YAufk3SxqocBaIsD5Z
> IbujCelJNGvRGBPmsIOD38aaVbcyJZFGG+m9nTTJyRQtdFGxfccE/K+xuZMLKFS/
> BQkyJdAyvGscRBLAx80o5TgZ+h7BTNW78b8aIubWaeMyqYrvQhdwaDTK7xj0cb5M
> uxC7fg493PphNLLYY5sL9yHPKtyJzuWhE6r9IXtMSH3b8sTEUU4cXxF4Ep1af+k0
> 9BafYy+vAxv6fM/3VS8KGcGCwElNrCiNLJYjEdW7mCDRFNQR8cja5IVRF8KGlXD3
> 33eKUviyPtx9LB5GNS2bZNSayeJbIENr1LsY2gZ4C6nfXUOzsUp7KhM4P4WmFKWV
> TOn/DbigDQjMa07L0+G+cwvrc2X2QJWG8kstD16iARvaRAnlvlO+HQeSAtO1LWwU
> 7O44z0eQDxpGO6RZrBDVKNGe8dAaObQT+ueCL/sOHV2Co71Iz8zCu8z75OIhSWWM
> 8Tu4pa+doFetFLmOkfkcFTxuAjcxJAJomxnLD9rNcdjDtuWF2wxATdWFruFmYPm+
> u0/PNb0YQg4Xx5M2qV63
> =FxNx
> -----END PGP SIGNATURE-----
> 



- -- 
kind regards

Ian Delaney
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJWoz9TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw
QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6jrcQAI70DMC1K2H5cyPs9sia+3ml
6teGcQLNm8DbtBLkJu5R/4Tj+idn9BinMYx7VuxlGBBXSLbDMZlJYBQd5G3fTP6r
1++oqBzVdkA2h6RaYp04NeJsJDRLrHvMh4jX+k0izR9G7kHOVwda15sdmYthcojs
++khE85mgleS9mio/a1gy2EEyY3+lkGCUSs13AU+epzioe/ZCz1zFlNqH/uDmG6+
COZaFbVuW3YlC30as5yvpoKRselx9TD/saZyMwwx2l61jMT6i8Rvo2XD/1Sp0kvb
4PPyBN8VwUId5HDhFvBKPbKezyu5K7xA01hOLFEEC+SH9Q13tfHhIiyCnogHGlDA
iXZ37Q4LcXQeJnM5xjuPWVaA9SDbkv4fkUq6r7w6mXbIOtnM3hMceM+xO8eHT6CO
8jykUiNyuXd2hWiJ+oQUiQEbWrAWhqP67e63ScRpH+e1AlpFpKcwJ9mskMaMkbFm
L3LWNJFnewn8ouKh2YtQro76/cW+XptK7OMfCGzHKa9eTlGUrG9y10YhBufMNktx
o7K7rVSxQrizsSvGl1c/lqbanQsHB12SxGZFSyFHwG4ES1Uii/Lbx64Hw9Jhs+Wv
sTIdp7bR8lBNI1YILDb4UY/ksfHIVFlB9ZVS+jwOsYYTTk/wDJri8fZhZt9ciOsF
pvGUwOslCyWnhC7zY5AG
=LdOn
-----END PGP SIGNATURE-----

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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/23/2016 12:52 AM, Ian Delaney wrote:
> On Thu, 21 Jan 2016 16:30:14 -0800 Daniel Campbell <zlg@gentoo.org>
> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> 
>> On 01/21/2016 02:41 PM, waltdnes@waltdnes.org wrote:
>>> On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
>>> 
>> [...] [...] [...]
>>> 
>>> I think you misunderstood Roy.  He was speaking about 
>>> "unmaintained but perfectly functional software".  You're
>>> talking about "a package that clearly doesn't build or
>>> otherwise simply doesn't work, could not have worked for past 3
>>> years".  Between those 2 extremes will be many cases of 
>>> doesn't-work-for-me/works-for-me.  Who'll be the final
>>> arbiter?
>>> 
>>> Maybe we should start a "gentoo-ebuilds" mailing list to help 
>>> regular users learn the ins and outs of making ebuilds.  Once 
>>> regular users run a lot of their own ebuilds from their local 
>>> overlays, then it would be possible to do draconian pruning of
>>> the "official portage tree", without so adversely affecting
>>> regular users.  This would fit in with the mantra of Gentoo
>>> being about freedom of choice.
>>> 
>>> E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to 
>>> build as regular user, su, and copy the binary to /usr/local.
>>> You can see "Walter's excellent adventure" <G> as I learn the
>>> build process at... 
>>> https://forum.palemoon.org/viewtopic.php?f=37&t=10002
>>> 
>>> I'd like to have Portage manage the process.  The ebuild from 
>>> Firefox should serve as a template, because they both use the
>>> same weird Mozilla build setup.  The main change should be
>>> where the source is pulled from.
>>> 
> 
>> The idea sounds nice, but there's already the devmanual to cover 
>> ebuild development, and now that the gentoo repo is in git, any 
>> ebuilds that get treecleaned can be fetched again through
>> history, and users can then add those to their personal
>> overlay(s) and keep the piece if they break.
> 
>> I like the idea of encouraging people to learn good ebuild
>> writing, but who really has the time and skill to teach it?
> 
> 
> me. Been doing it for months. You had not noticed? via 
> #gentoo-proxy-maint, which I made from scratch, despite the notion 
> initially being discounted by one mrueg. He now is a colleague in
> the channel.
> 
I didn't, actually. I guess the only thing I've seen as a result of
your work is possibly more new devs. That's pretty awesome, though; I
had no idea. I can't speak for other devs but I respect people who
have the patience and gift to teach people. You helped me a little
when I was becoming a developer and I appreciate it.

>> - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @
>> hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A
>> 9091 1EA0 55D6
>> 

> 

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWpWdoAAoJEAEkDpRQOeFwnkgP/iRHumL4sYupyh5jxe8g97Bo
//TEU/k4osiz4Ofl79fTVfabYZiMTacMaRj++swccGw0NorjBRf4TUc2bc08++NH
iUOjBwC5nAhPlx6UFM1IKAyOLvc4MZIpfR3m688EkTKnYH2865WhLjClfAwT7AFC
0Ux4/Knb7j4XtDBjM1tumA28VR27CTaIOsuPFMKIQ3gm0UnpZbPEOyiXNkszfq5g
IMkJynUtIgGegscdz9i+uGHVToqQXZnCxs/4fG+d6xr0ENMgwr+sOS8GnwR3wNtv
/wZ6qwUJuwGuh9Y0BDXibnoEE5vr+srZRPPZigLvbps24dCYbFE7dmpeEU11o5lB
fV5pI78QV81xI9NUYQsyPj3PbZn9qzgUtjw59lQvTN1rBtqSlezeRJ8JD+U1nBym
I2cL8Auy3Uu0W3q8G31iRmVW+LCe9njw6GZkj24QOzlsqkW3cjn+VyQHSNz2QNI9
384cY6NDngKvTugi5ccbkPicGO5pAxZ0UA44JwURLiGr0W9bbiaBOLBG6xQYkTQZ
j7F9P3RjGIbIGgxQQTQatyEQpqFnRBR22J8VH688OCHEjZprEc/F/xA4R1TLCRxx
3S3OMbuw99fsEXbqYhFhqWUsmOwaCCd7ofgrjXiefrf2NtRkl0V6loRoKlHz9ycY
wkPbzmPJ7zvNR+PcDud1
=JQSf
-----END PGP SIGNATURE-----

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

[Michael Orlitzky]

On 01/21/2016 05:41 PM, waltdnes@waltdnes.org wrote:
> 
>   Maybe we should start a "gentoo-ebuilds" mailing list to help regular
> users learn the ins and outs of making ebuilds.

Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC.

We should be trying to get these things proxy maintained at least since
they don't do anyone else any good in a personal overlay.

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

[Ian Delaney]

On Thu, 21 Jan 2016 19:51:51 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/21/2016 05:41 PM, waltdnes@waltdnes.org wrote:
> > 
> >   Maybe we should start a "gentoo-ebuilds" mailing list to help
> > regular users learn the ins and outs of making ebuilds.  
> 
> Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on
> IRC.
> 
> We should be trying to get these things proxy maintained at least
> since they don't do anyone else any good in a personal overlay.
> 
> 

Are you not missing something here?

-- 
kind regards

Ian Delaney

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

[waltdnes]

On Thu, Jan 21, 2016 at 07:51:51PM -0500, Michael Orlitzky wrote
> On 01/21/2016 05:41 PM, waltdnes@waltdnes.org wrote:
> > 
> >   Maybe we should start a "gentoo-ebuilds" mailing list to help regular
> > users learn the ins and outs of making ebuilds.
> 
> Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC.
> 
> We should be trying to get these things proxy maintained at least since
> they don't do anyone else any good in a personal overlay.

  Thanks for the pointer to gentoo-devhelp.  I'll try that list.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Alexis Ballier]

On Thu, 21 Jan 2016 18:45:20 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?

sure, don't waste your time and just delete it so that nobody can track
why it was removed or even attempt to fix it.

> Because to me, the lack of any open bugs is a clear evidence that
> the package is not only unmaintained, but also unused.


lack of open bug means there is no known bug; anything else is pure
supposition



if you see a package that "could not have worked for past 3 years", you
open a bug, cc treecleaners or lastrite it yourself, and it will be
quickly gone

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On 22 Jan 2016 12:04, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 18:45:20 +0100 Michał Górny wrote:
> > If I see a package that clearly doesn't build or otherwise simply
> > doesn't work, could not have worked for past 3 years, are you forcing
> > me to waste a time reporting a bug to no maintainer who could fix it?
> 
> sure, don't waste your time and just delete it so that nobody can track
> why it was removed or even attempt to fix it.
> 
> > Because to me, the lack of any open bugs is a clear evidence that
> > the package is not only unmaintained, but also unused.
> 
> lack of open bug means there is no known bug; anything else is pure
> supposition

this.  if anything, it sounds like i need to keep open a trivial bug
for a package to keep people from wrongly proactively tree cleaning.

the # of users of a package is irrelevant.  if there are (real i.e. not
"typo in message" bugs) open, then that's a diff story.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Fri, Jan 22, 2016 at 1:33 PM, Mike Frysinger <vapier@gentoo.org> wrote:

> On 22 Jan 2016 12:04, Alexis Ballier wrote:
> > On Thu, 21 Jan 2016 18:45:20 +0100 Michał Górny wrote:
> > > If I see a package that clearly doesn't build or otherwise simply
> > > doesn't work, could not have worked for past 3 years, are you forcing
> > > me to waste a time reporting a bug to no maintainer who could fix it?
> >
> > sure, don't waste your time and just delete it so that nobody can track
> > why it was removed or even attempt to fix it.
> >
> > > Because to me, the lack of any open bugs is a clear evidence that
> > > the package is not only unmaintained, but also unused.
> >
> > lack of open bug means there is no known bug; anything else is pure
> > supposition
>
> this.  if anything, it sounds like i need to keep open a trivial bug
> for a package to keep people from wrongly proactively tree cleaning.
>
> the # of users of a package is irrelevant.  if there are (real i.e. not
> "typo in message" bugs) open, then that's a diff story.
>

https://wiki.gentoo.org/wiki/Project:Treecleaner/Policy

I tried to write the policy as clearly as possible, feel free to request
modifications.

-A



> -mike
>

[-- Attachment #2: Type: text/html, Size: 2131 bytes --]

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

[Ian Delaney]

On Fri, 22 Jan 2016 12:04:07 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> On Thu, 21 Jan 2016 18:45:20 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > If I see a package that clearly doesn't build or otherwise simply
> > doesn't work, could not have worked for past 3 years, are you
> > forcing me to waste a time reporting a bug to no maintainer who
> > could fix it?  
> 
> sure, don't waste your time and just delete it so that nobody can
> track why it was removed or even attempt to fix it.
> 
> > Because to me, the lack of any open bugs is a clear evidence that
> > the package is not only unmaintained, but also unused.  
> 
> 
> lack of open bug means there is no known bug; anything else is pure
> supposition
> 
> 
> 
> if you see a package that "could not have worked for past 3 years",
> you open a bug, cc treecleaners or lastrite it yourself, and it will
> be quickly gone
> 

and on it goes. In the above we see a common theme. The emphasis on the
wasting of time over an absurd task because it is so obviously absurd.
Except, wait, it isn't so absurd because .......
This kind of leaping to a final conclusion and declaring an assessment
of it on a knee jerk type interpretation is all too common. Frankly I
find it difficult to fathom how this constant trail of such
premature evaluations has its source from gentoo developer
community; I.T. professional folk who by rights excel in objective
analysis of the data at hand and routinely arrive at technical
solutions to cover a minimal required set of conditions. Or is there
something wrong in my suppositions there regarding the precursors?

Either way; see 
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Wanted

last edited between myself and kensington cs 24-01 this year. The
important content, obviously, are the Criteria for closing a report.


-- 
kind regards

Ian Delaney

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

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On 2016.01.21 17:45, Michał Górny wrote:
[snip]

> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?
> 
[snip]
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
> 

Michał 

Your statement implies that there is an active search process for broken packages.

I did not intend to imply that if you happened across a broken package with no bugs, 
you needed to raise a bug to remove it from the tree.

Actively building every package in the tree to discover candidates for removal 
takes a lot more resources than searching bugs to identify potential candidates.

Its the old case of absence of evidence is not evidence of absence.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Ian Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, 21 Jan 2016 18:45:20 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Thu, 21 Jan 2016 17:25:02 +0000
> Roy Bamford <neddyseagoon@gentoo.org> wrote:
> 
> > On 2016.01.21 16:53, William Hubbs wrote:  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> > 
> > There is no point in removing unmaintained but perfectly functional
> > software from the tree. It needs to be both unmaintained and
> > broken. Broken being evidenced by at least one open bug.  
> 
> That's nonsense. In fact, that's exactly the opposite of what should
> be removed.
> 

So take the long standing President of the Board of Trustees who began
gentoo likely when you were still in school, peruse, and without
hesitation, with the opening line, declare the cited benchmark of
evidence as nonsense.

Sighs, and groans.


> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?
> 

Surely no.

> Because to me, the lack of any open bugs is a clear evidence that
> the package is not only unmaintained, but also unused.
> 
> 

This is the way it really is, obviously. Well, to be fair; "Because to
me", so not quite. But I can't help being of the impression
that because you think so, it must in fact BE.

Happily, master Neddy being as capable as he is with management of such
expression, has already retorted to the description of his conclusion
as nonsense as, well, nonsense.

- -- 
kind regards

Ian Delaney
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJWpJ6rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw
QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM68qIQAMaiuJwwU9hUtJwfO5AwjGHM
Yukp7mib/MAHUCHExfNTrGQ/rlgOmzgG1gmx75Ruh6utia4xz3Xlcp4VkVWcyZER
StuRAXCuL874aUW4iSRL0fSAXK38L7AfvHs+3RVzV9Dr1DhPIUdIwwdmbLE25AEY
BSDcRDPSnkmDn9+ifuO/s+/lH7quQRugkS6LPDxB37Vnbi6yudrUpNB8x+B4IRb9
F9hgB0GXOhAAR8z1z2avf5f5yzKXp93tDwfxfl2uOMs3iUm3wedpaMyC+6YBkmsc
Flwu9gYfUVM957t5u84jUId4ckjyBYltZmCtzWoA6oQx0umPUkB4Q8R+p4azsTST
Vmr/9se0Em+QHXFDbTzQLiMuotKO6yRFhpQn2T8F46SEqI7OA+wrVmKmZXfdg2OH
CVV29X85uomLRGw0NrCwnKCQaKRUiFDwadjclfOBPy31LBMaNUoKsHdImjUgy1fA
r29oZsCVK16Io7fh9lWE2F6Q5uIsANaCNeGp+HqOd13xEvqSwW+NPRTxSD17uw4m
akdA1oTNiQoYfR6BUz14GXFc0oXH9zrO2TLZpRqnhjOIb8TGeaDyEuKfG95TD3mq
vSyPsNaaTp14tiEjLRy+S+vlxkGdovdK0dFOoVouFFFpz7sP38ngWOCdO92OoEeR
C7g32EiMSIoJrJe4VLOE
=wTau
-----END PGP SIGNATURE-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

On Tue, 19 Jan 2016 00:44:49 -0500
NP-Hardass <NP-Hardass@gentoo.org> 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.

I don't understand why you're turning this problem upside-down.
The problem was, is and will be that packages are unmaintained. Not
that stats show that they are many.

It's better to have packages maintainer-needed than 'maintained' by
developers who ignore bugs, requests and basically act as showstoppers
for people who want to fix stuff.

> 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.

That's not really a change. Additional advertisement at best.

> 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).

This is already the case.

> 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.

If you want to do some fun coding, here's my idea: find reverse
dependencies of maintainer-needed packages, and try to convince
the maintainers of those revdeps to take those packages. After all,
those revdeps require the packages, and are going to benefit from them
being maintained.


-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ciaran McCreesh]

On Tue, 19 Jan 2016 23:32:30 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> The problem was, is and will be that packages are unmaintained. Not
> that stats show that they are many.

No it's not. Gentoo is about the community, and it's important for the
community not to perceive that there is a problem. Being honest where
users or Phoronix could pick up on it is bad PR. Let's not create a
toxic perception of the state of the tree.

-- 
Ciaran McCreesh

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

[Rich Freeman]

On Tue, Jan 19, 2016 at 5:42 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 19 Jan 2016 23:32:30 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>> The problem was, is and will be that packages are unmaintained. Not
>> that stats show that they are many.
>
> No it's not. Gentoo is about the community, and it's important for the
> community not to perceive that there is a problem. Being honest where
> users or Phoronix could pick up on it is bad PR. Let's not create a
> toxic perception of the state of the tree.
>

To be fair while at times I'm not a big fan of treecleaning things
that aren't horribly broken, I've never been opposed to marking them
as maintainer-needed.  That's what they are.  And I certainly don't
support hiding problems (and nor does our social contract).

Yes,I realize that by replying I'm basically accepting that the
criticism above applies to me.  I'll agree that on the community vs
pragmatism scale I tend to fall more to the left sometimes.  It isn't
a position without its disadvantages.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Tue, 19 Jan 2016 00:44:49 -0500
NP-Hardass <NP-Hardass@gentoo.org> 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.

Oh, and just to be clear, 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.

Now compare that to the current 1212 maintainer-needed packages.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[NP-Hardass]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

I'm not claiming that this is a new problem or that it will be orders of magnitude worse. Merely that it brings the issue back into the forefront and that we could benefit from official policies and (in some cases renewed) efforts to reduce their impact. An official policy/action is not likely to make an impact than an ad hoc, unofficial one, IMO.

On January 19, 2016 5:51:27 PM EST, "Michał Górny" <mgorny@gentoo.org> wrote:
>On Tue, 19 Jan 2016 00:44:49 -0500
>NP-Hardass <NP-Hardass@gentoo.org> 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.
>
>Oh, and just to be clear, 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.
>
>Now compare that to the current 1212 maintainer-needed packages.
>
>-- 
>Best regards,
>Michał Górny
><http://dev.gentoo.org/~mgorny/>

-- 
NP-Hardass

[-- Attachment #2: Type: text/html, Size: 2026 bytes --]

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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/18/2016 09:44 PM, 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.
> 
> 
> 
I like the idea behind this, but as others have already indicated,
there are some potential downfalls or redundancies. I think the
biggest problem here is, to my knowledge we don't have a way to see
how popular packages are. We don't know where to direct effort in the
tree without bugs or complaints over IRC/fora/ML. To get that
information we would need either volunteers or to violate our users'
privacy, which I'm not in favor of.

So we have maintainer-needed and proxy-maint, which from what I can
tell is a good gateway to becoming a developer. We could bring more
attention to that, but not without some support from other developers
who have an eye for spotting people who would be an asset to Gentoo.

As mgorny said, it does no good for us to assign dead packages to a
group of developers that won't give them the attention they deserve. I
know I'm guilty of it.

For better or worse, that's the nature of volunteer work. Users need
to know that Gentoo's tree is only as rich as the time and effort that
can go into it. We all have limitations on our time and energy, and if
nobody's interested or capable enough to maintain packages, then it
only makes sense to let them sit until someone comes along and either
takes the package or treecleans it. Last rites exist to ensure that
anybody who might care about a package will step up. They get 30 days,
iirc. I think that's plenty of time.

Since the tree's in git now, a user or would-be developer who wants to
revive a package still has something to work with. They'll just have
to fetch it from history, update it, and submit a PR or New-ebuild bug.

I guess what I'm saying here is I like your idea. I just don't think
we have the manpower or the interest among our users to make a big
dent. We should maybe put a *little* more attention on proxy-maint, if
they're okay with that, and let the community speak for themselves. If
packages die, it's because no developer wants to or can maintain it
and nobody in the community wanted to step up. Those that care can put
them into an overlay or step up and contribute.

My apologies if I'm coming off harsh. I don't mean to; it's just the
way FOSS development works imo.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWn39iAAoJEAEkDpRQOeFwo48P/jjBXPO0vb7uuIsoRaTuKJ8D
Edlzg8K35quvc09RGsofP2zC+Ywt/Qrh+reHWZxhrviZqpiwIbp7rUL0CnJJdku9
6NNtTsQDpcVAOWgIhIzqoZ/Ld0AJI+SqX2XwvLpGqzSqbZLTujD8IOHhjSqPH6bp
STbNKhB1DYkhoXh1tDIe0raOcsOEbqTFWPzhwmOBPr3OtmNeezvsPA4kDWlqikYr
SIRGPad4Mz6DtnWPyxXrFD9B5BpjD7T8LxlRCaMNI4exT156pS+DttyBq2LzQgbE
KfwaLK9yXCFxeakWZuZPE/dP+8sMH5jddMMk0lhYoDca/QaQ6syMZ+zo5qjLg4jf
LJqjSoEATDu7qbqllw/ZN3iSXOZKZ4e7mbGsStsD/z5381/ASfaUdS9b5Qfk3EBV
5KHkO37a/dgZ/LQjyYIMUGLUl7fSMtAI1nQB2qL2fUZCSh6sxX+rexqbTrM0hr0B
UReH9w+HvW93XfHqBxyoSyq5q/9f+De0caLOKIBOtjz1XjmgIKCZtBEsY0coCGcS
uQh5Ksoat/E0dARrc7XbRtgc59aWeEMMlU73YELgTGttvYQ3MqL4hQF0rnFNp2Rn
ulnB3yKuzTtmesZDF+9ewCHUJJRTreOMZY9jsYKVVZVZQXHBT2ole3vNUBsyBbo4
5frJQ0E1xGmOa6CcfQRM
=dh6h
-----END PGP SIGNATURE-----

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

[Patrice Clement]

[-- Attachment #1: Type: text/plain, Size: 3272 bytes --]

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?

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rich Freeman]

On Sat, Jan 23, 2016 at 6:12 AM, Patrice Clement <monsieurp@gentoo.org> wrote:
>
> <somebody>, I quite like your idea but what about <doing something else> first?

I don't see any strict dependency on these two ideas.  By all means
both of you should feel free to get them implemented.

If we only implemented ideas when all the other "more important" ideas
were already implemented, we probably wouldn't implement anything at
all.  :)

-- 
Rich

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@gentoo.org> 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-----

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

[Andreas K. Hüttel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Summarizing some (not all) points from Ian's mail:

####
The proxy-maintainers project is nowadays very active on the channel #gentoo-
proxy-maint. Several new and very promising contributors are showing up there, 
and generating a flurry of activity.

Since the initial purpose of proxy-maintainers was to allow users to pick up 
orphaned packages, that team has volunteered also to look at maintainer-wanted 
bugs. Sorting them is something that can also be done by not-yet-devs under 
supervision. Right now the team is discussing criteria how to handle the old 
bugs, see [1].

[1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Wanted
###

... and here's some personal remark from me: The proxy-maint project seems to 
have gotten a good start now, with an active but informal community of 
interested users forming on the channel, submitting e.g. pull requests and 
discussing ebuild topics. As dev, please consider helping out there; more eyes 
not just improve code quality, but also response times and community 
coherence.

Cheers, 
Andreas

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWpPAoAAoJEHRrah2soMK+yj0QAMuNz82REqd2FofJ5OAWyMNI
8giKqlB5cOIz2I14jVa2WfizQ0EP/LpVGFpAD5bVNy4/gvgFUr6fDfJfF3onhpS8
sLika3JngeGgALYB131l0flavm1jsNdE67ysxcCsb4ilsVjHw5eEOCDonRR2fMIY
RmuzyH2wimH1yM9DP7MvniRDqbAFvsMWz+7UZferZF9NCAnpLJJuYD+T/jgbZ/G4
M47mc0JEkNEcenz0f/ZHKNcyG37oXz3ZCG4IWhGl93tw449xF0VQXbyxk4HAqR6C
oYZPRvIXVqaou8ONcxsIqxITSaxBfNbx49oHWXKdbnMTwhO66mflZ4TegCpLBBhA
9k1oYgE7wdUGB8lg2FDecNy0sSkmHH0BZS1eYJcn6uCXor6gF+jr/LkrHPpp9OD3
XfkZ3p1CGmUUQoA908cZ8KDEP66FPmxqud+HUDAHk64ah7ohlwv2Qhe7nvvSCFPA
T34MfrPm2QfQ2HZq9PSj/uagwBixovnmED/tghosJaThlLkFdc5kVSp3qiSidbT1
y8e9pOWSCm4dax6EM/MXZdW9EDHqlCPmkfeHke9vrx9Im7U6nEVMZbF8xSegjkEk
hfmR8gn6otf3dbmVl/wA6SLuyTF6yaXtZyTRp/2idEKwTeLvHttzDQJaUOAoI7y+
NwRuxVUA7cfEWUMp3g/a
=xyEX
-----END PGP SIGNATURE-----

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

[Göktürk Yüksek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ian Delaney:
> 
> 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.
> 
> 
I don't want to go off-topic here too much but this is more than a
missing tools issue. There are privacy concerns regarding the
collection of such information. I recall this proposed idea from
Google Summer of Code:

https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_statistics_reporting_tool
> 

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

iQEcBAEBCgAGBQJWpPLJAAoJEIT4AuXAiM4zoJUIAKU2HiHPp+zH6vsieBRzz0It
ZgW66aiI7KWeTRlE0kPy+HHIHNG85M4686pgStHYnlJwAOEWej4aujYfWVKMXB/4
ty1511Pgb0o9yQuZLDV+5rprhcUyRggqu+dLQ16tjYRNuIHOGdZ+A0FM+H2E5Ty5
Ca4ab8wLq1TiV4oEbVst1b/z8tt1JAtBpjS0i4G9+sd80YA8wS2jG6NwgBqPB/2r
VqKT7hR2RXVZodz1d+rQZUhF5GP7kABvNnY332Vzt8yjEAAMIOWeltnRdkL58R2C
wzs34/rEAtWkn49EK6qw8/PFe2VA4U9XHqCSIbbJyTPxgIyZXnC3uWJpp4qIaz8=
=0G0w
-----END PGP SIGNATURE-----

[gentoo-dev] Gentoostats

[Andreas K. Hüttel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sunday 24 January 2016 16:50:46 Göktürk Yüksek wrote:
> 
> I don't want to go off-topic here too much but this is more than a
> missing tools issue. There are privacy concerns regarding the
> collection of such information. I recall this proposed idea from
> Google Summer of Code:
> 
> https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_stati
> stics_reporting_tool

This has been debated to death. As long as noone is forced to use it, privacy 
concerns shouldnt be a problem. And it would be extremely useful how many of 
our maintainer-needed packages are actually still compiled once per year. (Or 
if any one single person even uses KDE on ppc64.)

Gentoostats is a typical stillbirth of the Gentoo Google Summer of Soon-
Obsolete Code. Would I be happy if someone were to revive and actually deploy 
it (the last point is important!)? YES!

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWpPT9AAoJEHRrah2soMK+WjoP/2zsgRV565keOQdPaya/j5ak
0ga6F4xjf+XdAg4soPG+c0guN/Qz3tZtuIdDnl7NDaWBUBWGvA6DuqcKxPj3g0EQ
X9EZTCigAsO+0d1F4cLMqW7JsL5YqTL4wHftzjuCqqSTD7OtX6NtOBA1namIDCoz
MpmSArjjBy31oiJgDRRBDwCRAMoSErKEnkeyXVyuFyD4yV9E8PMOFcrNkeO2MFHy
/Ehy0v14F5pTiGNeDnt7EDXNf5rcOFGUYTUitNyrhotUuX7sobcS9RfX2B9VtWUF
pgg3zRKGJdpeKwRx3MFZZA/O8f5bPT3ne1dMLZ/LOjxgvt/CglG5G4K+iL3lFC9v
WEeHj4zejXQuKlX1olWOgZdAYlt9bUmg7YO2K+OOPfQrTmqbShlnPFiAXuMTIS0h
elnKY8I5e1flHbFicQg6lnT+qBriy7afYhj7WkGypzC8DAhI1N4/eROavrALCkMW
nqNbEM0x4RiNdpgmdoN4L8dFBygXW73O4G8Iu5xjE1hKA6xUCmYitP3AsI5rVx1A
Jt6A2edk3Zk/g584nZ07GIt4W5AceFlFhBaYxKNgAo8MZUUE5gzvcblbPTF7Si4t
gTkjyXy0qabpvDBlimWxFENxGSIUqM/8N0YB1xba/FXNLn4KmTmD8Tezvze2c5Al
Htxql3SYp7YaY0HFrYdx
=lclI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gentoostats

[Dirkjan Ochtman]

On Sun, Jan 24, 2016 at 4:59 PM, Andreas K. Hüttel <dilfridge@gentoo.org> wrote:
> Gentoostats is a typical stillbirth of the Gentoo Google Summer of Soon-
> Obsolete Code. Would I be happy if someone were to revive and actually deploy
> it (the last point is important!)? YES!

When I last looked into it, I couldn't actually access Gentoo infra to
deploy it on. If that would be possible, I wouldn't mind taking a look
at what can be done here.

Cheers,

Dirkjan

Re: [gentoo-dev] Gentoostats

[Alexis Ballier]

On Sun, 24 Jan 2016 16:59:57 +0100
"Andreas K. Hüttel" <dilfridge@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On Sunday 24 January 2016 16:50:46 Göktürk Yüksek wrote:
> > 
> > I don't want to go off-topic here too much but this is more than a
> > missing tools issue. There are privacy concerns regarding the
> > collection of such information. I recall this proposed idea from
> > Google Summer of Code:
> > 
> > https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_stati
> > stics_reporting_tool  
> 
> This has been debated to death. As long as noone is forced to use it,
> privacy concerns shouldnt be a problem. And it would be extremely
> useful how many of our maintainer-needed packages are actually still
> compiled once per year. (Or if any one single person even uses KDE on
> ppc64.)

you'd probably get much more reliable stats on package usage by
gathering distfiles d/l stats from mirrors and mapping that to packages

Re: [gentoo-dev] Gentoostats

[Chí-Thanh Christopher Nguyễn]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

Andreas K. Hüttel schrieb:
> And it would be extremely useful how many of our maintainer-needed
> packages are actually still compiled once per year. (Or if any one
> single person even uses KDE on ppc64.)
>
> Gentoostats is a typical stillbirth of the Gentoo Google Summer of
> Soon- Obsolete Code. Would I be happy if someone were to revive and
> actually deploy it (the last point is important!)? YES!

Actually there is something in use already which would allow you to find
out which packages are compiled when. It is a community website called GenTwoo:

http://gentwoo.elisp.net/

There is not all information visible, and there could be some improvements
of course, but it exists.

Best regards,
Chí-Thanh Christopher Nguyễn



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Michael Palimaka]

On 01/25/2016 02:50 AM, Göktürk Yüksek wrote:
> Ian Delaney:
> 
>> 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.
> 
> 
> I don't want to go off-topic here too much but this is more than a
> missing tools issue. There are privacy concerns regarding the
> collection of such information. I recall this proposed idea from
> Google Summer of Code:
> 
> https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_statistics_reporting_tool
> 

This was implemented but never deployed. Data collection would always be
optional and off by default. There was even a nice configuration file to
select exactly which information is and is not sent.

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

[Michael Jones]

[-- Attachment #1: Type: text/plain, Size: 5606 bytes --]

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@gentoo.org> wrote:

> On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <NP-Hardass@gentoo.org> 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-----
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7755 bytes --]