Re: [gentoo-dev] the graveyard overlay

[Alec Warner]

On Fri, Jul 8, 2016 at 2:50 PM, Alec Warner  wrote:

>
>
> On Fri, Jul 8, 2016 at 1:21 PM, Philip Webb  wrote:
>
>> 160708 William Hubbs wrote:
>> > On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
>> >> IMO the criteria should be whether they work or not,
>> >> not whether upstream is more or less active.
>> >> If they're blockers on other work, by all means cull them.
>> >> However, if the biggest problem with them is
>> >> that they're using a few inodes in the repo, they should probably stay.
>> > There is an overlay for packages that are removed from the official tree
>> > -- https://github.com/gentoo/graveyard --
>> > and that is where old software should go,
>> > if it doesn't have an active maintainer.
>>
>> A lot of this lengthy discussion is missing some basic points,
>> though a few people have mentioned them in passing.
>> As someone who has used Gentoo exclusively since 2003
>> & who raised the objections to removal of Xcdroast + Nethack,
>> let me try to get you all to focus on the real-life issues.
>>
>> (1) The fact that a pkg has little or no upstream support
>> or that it doesn't have an active Gentoo maintainer
>> is not a reason for removing it from the regular tree.
>>
>
> So basically what you are advocating for is:
>
> "Having completely unmaintained packages in the tree is OK."
>
> And honestly, I do not buy that premise.
>
>
>>
>> One basic reason some software is no longer being actively developed
>> is simply that they work perfectly well as they now are,
>> eg the file manager Krusader & the desktop manager Fluxbox :
>> both of these are very useful & have no drop-in replacements,
>> but very little development has occurred for several years.
>> The same is true of Xcdroast & Nethack, which have been threatened,
>> but which have been rescued after some small patches have been applied.
>> This is likely to be true of more + more pkgs, as time passes :
>> even changes in the kernel these days rarely affect desktop users.
>>
>
> No one is trying to remove flubox (which had a release in 2015 and had
> activity in its git repo as recently as last week.)
>
> Xcdroast for example, hasn't had a release in 8 years and I can't even
> find its source tracker in sourceforge. These are the sorts of packages
> that I think are not great to have in the tree and for Xcdroast, if I were
> treecleaner lead i would probably advocate for working around the security
> bug (dropped SUID) instead of removal. I do not necessarily want to remove
> software that people are using.
>
> That being said, I do not want unmaintained software in the tree either.
>
>
>>
>> (2) There are  3  basic categories of Gentoo user :
>> (a) server-farm managers, (b) multi-user sysadmins, (c) single-users.
>> Each of these have different security concerns :
>> (a) need to be alert to the many threats from all over the Internet ;
>> (b) need (among other things) to prevent privilege escalation ;
>> (c) are largely immune to those types of threat,
>> though a few of the Internet variety can affect them.
>>
>
> I appreciate the argument you are trying to make; but i do not think it
> really drives Gentoo Security Policy (nor should it.)
>
> As my security manager used to say "security is not a race to the bottom."
>
>
>>
>> The security objections raised against Xcdroast + Nethack
>> were both problems which would arise only on multi-user systems,
>> yet single-users were also to be deprived of access to them.
>> Perhaps part of the problem is that many Gentoo developers
>> also earn their livings as sysadmins with many users or many servers :
>> the simpler happier world of single-users escapes their attention.
>>
>> (3) Users generally don't want to be developers : they're too busy or too
>> old.
>> Asking them "Are you willing to maintain it yourself ?" is a silly excuse
>> ;
>> offering them the chance to dig around in a graveyard is even worse ;
>> even maintaining an overlay is a nuisance : I tried it with KDE Sunset.
>> Neither Xcdroast nor Nethack belong in a graveyard of any kind :
>> once the obscure security problems have been fixed,
>> they belong in the regular tree marked 'stable',
>> like many other pkgs whose development has been completed.
>>
>> Users all do -- or should -- appreciate the unpaid work of the developers,
>> but developers also need to realise that without non-developer users
>> Gentoo would very quickly die & their justified pride + satisfaction die
>> too.
>>
>
> I'm a bit confused by this argument.
>
> 1) It appears that no Gentoo developers want to maintain a software
> package.
> 2) The software package has no active upstream.
> 3) The software has no bugs.
>

Sorry, in my argument the package has open bugs, I mis-typed ;)


> 4) We mask the software because it has bugs and no active maintianer, for
> years.
> 5) No one volunteers to proxy-maintain the software.
>
> But you advocate we keep such software in the tree, because users 

Re: [gentoo-dev] the graveyard overlay

[Alec Warner]

On Fri, Jul 8, 2016 at 1:21 PM, Philip Webb  wrote:

> 160708 William Hubbs wrote:
> > On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
> >> IMO the criteria should be whether they work or not,
> >> not whether upstream is more or less active.
> >> If they're blockers on other work, by all means cull them.
> >> However, if the biggest problem with them is
> >> that they're using a few inodes in the repo, they should probably stay.
> > There is an overlay for packages that are removed from the official tree
> > -- https://github.com/gentoo/graveyard --
> > and that is where old software should go,
> > if it doesn't have an active maintainer.
>
> A lot of this lengthy discussion is missing some basic points,
> though a few people have mentioned them in passing.
> As someone who has used Gentoo exclusively since 2003
> & who raised the objections to removal of Xcdroast + Nethack,
> let me try to get you all to focus on the real-life issues.
>
> (1) The fact that a pkg has little or no upstream support
> or that it doesn't have an active Gentoo maintainer
> is not a reason for removing it from the regular tree.
>

So basically what you are advocating for is:

"Having completely unmaintained packages in the tree is OK."

And honestly, I do not buy that premise.


>
> One basic reason some software is no longer being actively developed
> is simply that they work perfectly well as they now are,
> eg the file manager Krusader & the desktop manager Fluxbox :
> both of these are very useful & have no drop-in replacements,
> but very little development has occurred for several years.
> The same is true of Xcdroast & Nethack, which have been threatened,
> but which have been rescued after some small patches have been applied.
> This is likely to be true of more + more pkgs, as time passes :
> even changes in the kernel these days rarely affect desktop users.
>

No one is trying to remove flubox (which had a release in 2015 and had
activity in its git repo as recently as last week.)

Xcdroast for example, hasn't had a release in 8 years and I can't even find
its source tracker in sourceforge. These are the sorts of packages that I
think are not great to have in the tree and for Xcdroast, if I were
treecleaner lead i would probably advocate for working around the security
bug (dropped SUID) instead of removal. I do not necessarily want to remove
software that people are using.

That being said, I do not want unmaintained software in the tree either.


>
> (2) There are  3  basic categories of Gentoo user :
> (a) server-farm managers, (b) multi-user sysadmins, (c) single-users.
> Each of these have different security concerns :
> (a) need to be alert to the many threats from all over the Internet ;
> (b) need (among other things) to prevent privilege escalation ;
> (c) are largely immune to those types of threat,
> though a few of the Internet variety can affect them.
>

I appreciate the argument you are trying to make; but i do not think it
really drives Gentoo Security Policy (nor should it.)

As my security manager used to say "security is not a race to the bottom."


>
> The security objections raised against Xcdroast + Nethack
> were both problems which would arise only on multi-user systems,
> yet single-users were also to be deprived of access to them.
> Perhaps part of the problem is that many Gentoo developers
> also earn their livings as sysadmins with many users or many servers :
> the simpler happier world of single-users escapes their attention.
>
> (3) Users generally don't want to be developers : they're too busy or too
> old.
> Asking them "Are you willing to maintain it yourself ?" is a silly excuse ;
> offering them the chance to dig around in a graveyard is even worse ;
> even maintaining an overlay is a nuisance : I tried it with KDE Sunset.
> Neither Xcdroast nor Nethack belong in a graveyard of any kind :
> once the obscure security problems have been fixed,
> they belong in the regular tree marked 'stable',
> like many other pkgs whose development has been completed.
>
> Users all do -- or should -- appreciate the unpaid work of the developers,
> but developers also need to realise that without non-developer users
> Gentoo would very quickly die & their justified pride + satisfaction die
> too.
>

I'm a bit confused by this argument.

1) It appears that no Gentoo developers want to maintain a software package.
2) The software package has no active upstream.
3) The software has no bugs.
4) We mask the software because it has bugs and no active maintianer, for
years.
5) No one volunteers to proxy-maintain the software.

But you advocate we keep such software in the tree, because users are "too
busy" or "too old" to maintain it themselves?


>
> (4) I have  3  simple recommendations to fix the everyday problems.
>
> (a) the justification for tree-cleaning should be explicitly
> that a pkg either (i) won't compile, (ii) crashes when run
> or (iii) has a serious 

[gentoo-dev] [warning] the bug queue has 97 bugs

[Alex Alexander]

Our bug queue has 97 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] Re: the graveyard overlay

[Neil Bothwick]

On Fri, 8 Jul 2016 19:17:44 +0300, Andrew Savchenko wrote:

> > Completely aside from the question of criteria for removing stuff from
> > the main tree, it would make a lot of users happy if every package
> > which *is* removed were added to the graveyard overlay.  
> 
> Good idea, since we have attic no more, and users need this [1].
> While any removed package can be extracted from git, this is not
> a trivial operation and is definitely harder then fetching filesv
> from overlay.
> 
> But the problem is that this way overlay will become completely
> broken in terms of both QA and security.

That's no different from ebuilds in the CVS attic. They were no longer
maintained and may even have been removed for security reasons, or even
failure to build, but they were still made available through the attic.


-- 
Neil Bothwick


pgpJTkrjYpYPE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] the graveyard overlay

[Philip Webb]

160708 William Hubbs wrote:
> On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
>> IMO the criteria should be whether they work or not,
>> not whether upstream is more or less active.
>> If they're blockers on other work, by all means cull them.
>> However, if the biggest problem with them is
>> that they're using a few inodes in the repo, they should probably stay.
> There is an overlay for packages that are removed from the official tree
> -- https://github.com/gentoo/graveyard --
> and that is where old software should go,
> if it doesn't have an active maintainer.

A lot of this lengthy discussion is missing some basic points,
though a few people have mentioned them in passing.
As someone who has used Gentoo exclusively since 2003
& who raised the objections to removal of Xcdroast + Nethack,
let me try to get you all to focus on the real-life issues.

(1) The fact that a pkg has little or no upstream support
or that it doesn't have an active Gentoo maintainer
is not a reason for removing it from the regular tree.

One basic reason some software is no longer being actively developed
is simply that they work perfectly well as they now are,
eg the file manager Krusader & the desktop manager Fluxbox :
both of these are very useful & have no drop-in replacements,
but very little development has occurred for several years.
The same is true of Xcdroast & Nethack, which have been threatened,
but which have been rescued after some small patches have been applied.
This is likely to be true of more + more pkgs, as time passes :
even changes in the kernel these days rarely affect desktop users.

(2) There are  3  basic categories of Gentoo user :
(a) server-farm managers, (b) multi-user sysadmins, (c) single-users.
Each of these have different security concerns :
(a) need to be alert to the many threats from all over the Internet ;
(b) need (among other things) to prevent privilege escalation ;
(c) are largely immune to those types of threat,
though a few of the Internet variety can affect them.

The security objections raised against Xcdroast + Nethack
were both problems which would arise only on multi-user systems,
yet single-users were also to be deprived of access to them.
Perhaps part of the problem is that many Gentoo developers
also earn their livings as sysadmins with many users or many servers :
the simpler happier world of single-users escapes their attention.

(3) Users generally don't want to be developers : they're too busy or too old.
Asking them "Are you willing to maintain it yourself ?" is a silly excuse ;
offering them the chance to dig around in a graveyard is even worse ;
even maintaining an overlay is a nuisance : I tried it with KDE Sunset.
Neither Xcdroast nor Nethack belong in a graveyard of any kind :
once the obscure security problems have been fixed,
they belong in the regular tree marked 'stable',
like many other pkgs whose development has been completed.

Users all do -- or should -- appreciate the unpaid work of the developers,
but developers also need to realise that without non-developer users
Gentoo would very quickly die & their justified pride + satisfaction die too.

(4) I have  3  simple recommendations to fix the everyday problems.

(a) the justification for tree-cleaning should be explicitly
that a pkg either (i) won't compile, (ii) crashes when run
or (iii) has a serious security hole which affects all  3  types of user.

(b) there needs to be a developer role 'General Maintainer',
who should be available to look at pkgs which have no regular maintainer,
but which compile, run properly & are generally secure :
their job would be to step in, like Mr Savchenko -- thanks again -- ,
to fix small problems which would otherwise be neglected ;
less formally, all developers might see it as part of their role
to help out occasionally with such small problems.

(c) Gentoo's rules + policies need explicitly to reflect the fact
that there are  3  types of user, as described :
eg some pkgs might be marked as 'not safe for multi-user systems' ;
that would recognise real distinctions which are now being ignored.

HTH & thanks as always to all of you for making Gentoo work since 2003.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] the graveyard overlay

[Rich Freeman]

On Fri, Jul 8, 2016 at 2:51 PM, Chí-Thanh Christopher Nguyễn
 wrote:
>
> I'm sorry for harping on that topic again, but if we had used grobian's
> initial proposal for git migration[0] - one repository per package, and the
> portage tree would be an aggregation of those - then we could have such a
> thing basically for free now.

Not really.  Unless you planned to never delete old versions of
packages from the tree.  Also, if you remove a package from the tree
you'd need to ensure that its repository didn't later disappear, or
that people could actually find it.

That design also has other problems, like a lack of consistency across
the tree.  If one package syncs and another one doesn't, maybe you get
things that don't work.  And heaven help the guy trying to do a
tree-wide change.  Just as with cvs there would be no association with
a change in one package with a change in another.

It wasn't a bad idea, but in the end the pros didn't seem worth the
cons.  I definitely wouldn't do it just so that I didn't have to run
git log to find a deleted ebuild.

-- 
Rich

Re: [gentoo-dev] the graveyard overlay

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:

On Fri, Jul 8, 2016 at 2:22 PM, Chí-Thanh Christopher Nguyễn
 wrote:

I think the point of a graveyard repository is that discovering and
extracting deleted ebuilds from git is more cumbersome than from CVS attic.

It would be even better if the graveyard repository preserved the commit
history, but I don't see any easy solution for that.



Like I said.  If the only use case is helping people who don't know
how to use git find deleted ebuilds, then just create a directory tree
with everything that was ever in the Gentoo repo.  That would be
pretty easy to script.  QA doesn't need to have anything to do with
it.


I'm sorry for harping on that topic again, but if we had used grobian's 
initial proposal for git migration[0] - one repository per package, and the 
portage tree would be an aggregation of those - then we could have such a 
thing basically for free now.


But that's how it is now. Getting ebuilds from CVS attic could be done via 
the sources.g.o web interface even, no local checkout needed.



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: the graveyard overlay

[William Hubbs]

On Fri, Jul 08, 2016 at 07:17:44PM +0300, Andrew Savchenko wrote:

*snip*

> But the problem is that this way overlay will become completely
> broken in terms of both QA and security.

Once it is in an overlay, we don't care about qa or security any longer,
so this isn't a problem just a fact of dealing with an overlay.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] the graveyard overlay

[Rich Freeman]

On Fri, Jul 8, 2016 at 2:22 PM, Chí-Thanh Christopher Nguyễn
 wrote:
> I think the point of a graveyard repository is that discovering and
> extracting deleted ebuilds from git is more cumbersome than from CVS attic.
>
> It would be even better if the graveyard repository preserved the commit
> history, but I don't see any easy solution for that.
>

Like I said.  If the only use case is helping people who don't know
how to use git find deleted ebuilds, then just create a directory tree
with everything that was ever in the Gentoo repo.  That would be
pretty easy to script.  QA doesn't need to have anything to do with
it.

-- 
Rich

Re: [gentoo-dev] the graveyard overlay

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:

You say that there are no bugs in those packages. How do you know? You
don't know unless you test it, and no maintainer means nobody is known
to test it regularly. The package can be pretty much completely broken
and we'll not know unless someone tests it.



This sounds like a tree falling in the forest with nobody around...

If a package is in the tree, and it has no known bugs, and no users,
who cares?

If somebody tries to use it, and it doesn't work, then they can file a
bug, and then we can treeclean it.


One might add here that toralf is doing a great job at building all packages 
and reporting those that fail. So at least we see build failures.



Having a graveyard that ONLY contains broken stuff as an overlay just
doesn't make sense to me.  Why would you install packages directly
from it without fixing them first?  Certainly for build failures you'd
be forced to do this.  I guess for security issues you could decide
that you don't care, or that your host is in a locked room with no
network access or something.  However, these seem like such minor use
cases that somebody could just stick the ebuilds in their own overlay
if they needed them.


I think the point of a graveyard repository is that discovering and 
extracting deleted ebuilds from git is more cumbersome than from CVS attic.


It would be even better if the graveyard repository preserved the commit 
history, but I don't see any easy solution for that.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] masking and removing *coin packages

[William Hubbs]

On Fri, Jul 08, 2016 at 07:09:04PM +0300, Andrew Savchenko wrote:
> On Fri, 8 Jul 2016 10:01:58 -0500 William Hubbs wrote:
> > On Fri, Jul 08, 2016 at 08:10:07AM -0500, james wrote:
> > > On 07/08/2016 05:17 AM, Andrew Savchenko wrote:
> > > > On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:
> > > >> Hi everyone,
> > > >>
> > > >> I emailed the list some time ago about giving away a bunch of bitcoin
> > > >> forks to see if anyone was interested in taking them.  I didn't get any
> > > >> feedback so as of tomorrow I'll be masking the following for removal in
> > > >> 30 days.
> > > >
> > > > Any reason for mask and removal? Are these packages broken?
> > > > Just drop them to maintainer-needed.
> > > >
> > > > Best regards,
> > > > Andrew Savchenko
> > > >
> > > 
> > > Perhaps we should start posting these  orphaned-package announcements to 
> > > gentoo-user, so folks interested in learning about ebuilds can ponder 
> > > proxy-maintenance of a few packages as an opportunity?
> > 
> > I'm not sure that's necessary, that's what g-d-a is for.
> 
> How many users are subscribed to the gentoo-dev-announce ML? The
> very name suggests that this is development announce, not something
> related to our users.
> 
> We already duplicate Last-rites messages to gentoo-dev ML, why not
> add gentoo-user here too? Why do we need to duplicate Last-rites on
> gentoo-dev in the first place? I suppose there are two reasons:
> 
> 1) even not all devs are subscribed to gentoo-dev-announce;

They should be, the last I heard this list is mandatory for all devs.

> 2) this is a moderated list, which creates some delays.
 
 This might be a consideration, but I'm not sure.

I'm not really for adding another list we cross-post last rites
announcements to, I would rather encourage folks who want to keep track
of that to subscribe to g-d-a. That's also where the announcements for
council meetings go, etc.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] the graveyard overlay

[james]

On 07/08/2016 11:51 AM, Michał Górny wrote:

On Fri, 8 Jul 2016 18:33:35 +0300
Andrew Savchenko  wrote:


On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:

I'm starting a new thread so this will be a completely separate
discussion.

On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:

On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:

On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  wrote:


Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed.  These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.



IMO the criteria should be whether they work or not.  Not whether
upstream is more or less active.

If they're blockers on other work, by all means cull them.  However,
if the biggest problem with them is that they're using a few inodes in
the repo, then they should probably stay.


+1

Best regards,
Andrew Savchenko


There is also an overlay for packages that are removed from the official
tree [1], and imo that is where old software should go if it doesn't
have an active maintainer.

I don't know why we haven't been using this, but using it more than we
have makes a lot of sense.


When software is in the main tree, it is a subject of tree-wide
changes like GLEP 67 update, package moves and so on. In a
separated overlay it will be completely abandoned and it may create
inter-overlay dependencies issues (e.g. when A is an old
package from the tree and package B from some overlay depends on A,
so if A will move to graveyard, B will be broken).


And that is the exact problem. As long as it's in Gentoo, it creates
work for others. Others who have enough work already without your help,
thank you.

There is a major difference between doing a global changes involving
few dozen or hundred packages when they are maintained, and having few
dozen more unmaintained packages to care for. The changes already
require a lot of effort, you know.

Now, there's a significant difference between lastriting unmaintained
packages at treecleaner's leisure and having a clean tree to work on,
and having to figure out how many of the packages blocking some global
change are unmaintained and if they can be cleaned, and cleaning them
while doing something completely different, then checking again,
then...


I completely do not understand why having "old" software in tree is
a problem, if such software have no serious issues and is not
blocking major progress. If software _is_ sufficiently broken, then
indeed move it to graveyard.


Right now, we have over 1500 unmaintained packages. Please tell me, how
that speaks of Gentoo? Because as far as I can see, we have 1500
packages which nobody looks after unless forced to.

You say that there are no bugs in those packages. How do you know? You
don't know unless you test it, and no maintainer means nobody is known
to test it regularly. The package can be pretty much completely broken
and we'll not know unless someone tests it.

Now, as long as package is in ::gentoo it is somehow officially
supported. Which means it pops up for user when he is looking for
something, and he assumes it's going to solve his problem. This is good
if it works. But considering it's unmaintained, nobody's testing it.

So the package might work, or it might not. It might have major
problems but nobody may notice them before user learns about them
the hard way. If he reports a bug, the bug goes to /dev/null, unless
some developer accidentally notices it and decides to fix it. Or just
lastrite the package.


More often a given package does not work for a noob-to-gentoo but and 
old hack can make it work. I've seen tons of evidence for this on 
gentoo-user over the last 12 years




Let me summarize the user experience. User was looking for a good tool.
Instead, he found a well-advertised unmaintained old piece of software
that promised to solve his problems and instead created more problems
for him. Nevertheless, he decided to be a good user and reported
the bug. Then he learned that nobody cares to fix the bug, the package
is long forgotten, and all his effort was for nothing.


From a tree-cleaner prospective, you might be correct. As a gentoo-user,
and one that responses to many of the ML queries, there is a full 
spectrum of experiences you are not accurately characterizing, imho.




Then he has to look for an alternative... and he starts to wonder how
to filter out those unmaintained packages because he'd rather use
something that somebody has really tested in the last 5 years.



Don't stop there. Users soon learn about overlays and a wide variety of 
packages contained in those, as well as sabayon, calculate, coreos and 
surely more to come (flatpak?). After a while you learn (after some 
pain) which overlays  and ebuild sources you can trust 

Re: [gentoo-dev] the graveyard overlay

[Rich Freeman]

On Fri, Jul 8, 2016 at 12:51 PM, Michał Górny  wrote:
>
> Now, there's a significant difference between lastriting unmaintained
> packages at treecleaner's leisure and having a clean tree to work on,
> and having to figure out how many of the packages blocking some global
> change are unmaintained and if they can be cleaned, and cleaning them
> while doing something completely different, then checking again,
> then...

Packages that are unmaintained are tagged as such.  Perhaps we need
better reporting tools to make it easier to identify blockers
associated with these?

Perhaps some kind of QA tool that lists all unmaintained packages that
are a blocker for anything and auto-treecleans them?

>
> You say that there are no bugs in those packages. How do you know? You
> don't know unless you test it, and no maintainer means nobody is known
> to test it regularly. The package can be pretty much completely broken
> and we'll not know unless someone tests it.
>

This sounds like a tree falling in the forest with nobody around...

If a package is in the tree, and it has no known bugs, and no users,
who cares?

If somebody tries to use it, and it doesn't work, then they can file a
bug, and then we can treeclean it.

I tend to favor just leaving things alone in the tree unless there is
a serious bug, or it is something sensitive enough that it just isn't
worth taking the chance.

However, I think broadly speaking there are two approaches that I
think make some sort of sense:
1.  Packages stay in tree until there is a problem (serious bug,
blocker, etc), then rapid and aggressive cleanout.
2.  Only maintained packages in tree.  Have a graveyard repo for
unmaintained stuff that doesn't have serious bugs (including not
working due to some change introduced in the main tree), and
aggressive cleanout if these criteria fail.

I don't think that keeping stuff in the tree until it is broken and
then moving them to a graveyard makes sense, at least not if they're
seriously broken.  The only use case I really see for this is people
who don't know how to work git.  I think a better solution for that
use case is for somebody to just make a repo that contains the latest
version of every file that has ever been in the gentoo repo (so,
basically a replay of the scm history minus delete operations, except
maybe for moves).  That really should just be used as a convenience
and not as an actual overlay.

Having a graveyard that ONLY contains broken stuff as an overlay just
doesn't make sense to me.  Why would you install packages directly
from it without fixing them first?  Certainly for build failures you'd
be forced to do this.  I guess for security issues you could decide
that you don't care, or that your host is in a locked room with no
network access or something.  However, these seem like such minor use
cases that somebody could just stick the ebuilds in their own overlay
if they needed them.

-- 
Rich

Re: [gentoo-dev] why is the security team running around p.masking packages

[Alec Warner]

On Fri, Jul 8, 2016 at 9:02 AM, Andrew Savchenko  wrote:

> On Wed, 6 Jul 2016 23:13:55 +0300 Andrew Savchenko wrote:
> > On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
> > > What kind of policing would you like to see councilman?  Would you
> like to
> > > see me removed from the project, because your precious package was
> > > p.masked?  You have ignored every thing I have said regarding your
> > > inability to work with the security team.  Even after an apology from
> me
> > > and a request to work with us you continue on with the rhetoric of
> powers.
> > > It displays a lot about your inability to work with others.
> > >
> > > No other developer is complaining... it is *literally* only you.
> >
> > It is really not just him. I do not agree with media-video/motion
> > pmask with 30-days removal term. But I had not pushed this issue
> > hard, since I'm not a maintainer of this package.
> >
> > If this package would have been masked without removal term, I can
> > at least accept if not agree with such action. But there is no
> > other alternative for this package and security bugs are not
> > critical (at least they do not affect many use cases at all). So
> > removal from the tree will harm our users sufficiently.
> >
> > When approach is "mask until issues are resolved, so that users are
> > informed about security hazard" — it sounds reasonable, and we
> > already have several packages in the tree this way. But when
> > approach is to purge package from the tree in 30 days regardless of
> > severity of security flaws and ignoring the fact that there is
> > nothing to replace this package with — this is not a kind of the
> > policy I'd like to see in Gentoo.
> >
> > Please understand me correctly: I'm not blaming you or security
> > team for this or that issue. But it looks like security team indeed
> > needs to review some policies and approaches to suit needs of
> > Gentoo users better in both of terms of security and usability, to
> > find some reasonable compromise between them, which will satisfy
> > most users. For these very issues it looks like canceling "removal
> > in 30 days" clause from p.mask action will do the job.
>
> One more package to the list: app-cdr/xcdroast. It was being tree
> cleaned[1] due to a minor security flaw (o+r on suid binary) on
> optional functionality disabled by default (so users have to enable
> that suid binary themselves each time after package update).
>
>
The treecleaning policies are pretty clear:

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

Packages should probably not live in the tree for years with open security
issues. If nothing else, someone (e.g. a maintainer) should decide that the
issue is minor and fix it. No one had done so for Xcdroast, and so it was
slated for removal.

For instance, they could remove suid entirely (force people to use sudo to
burn or similar setups.)

And despite multiple calls from users (see user comments on [1]
> and read whole thread [2]) saying they need this package, they were
> asked by security team to "stop spamming this bug"[3]. Such actions
> in my opinion make more harm then good by deteriorating user
> experience and number of choices available, while bringing only
> small and not always meaningful security improve.


Yeah that is not great, but in the end we would prefer someone step up and
maintain the package. Its not clear that the status quo was a great
situation (regardless of what the users thought.)


>
> So it looks like that both security and treecleaners teams need to
> review their policies or at least discuss these problems publicly
> in more detail. Looks like one such discussion is emerging in
> thread [4].
>

Xcdroast hasn't had a new release in 8 years, and is unmaintained. So if no
one in Gentoo is going to maintain it, I do question why we keep it around;
someone should be keeping an on eye it (minimally media-optical, which
seems dead?)

-A


>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=345337
> [2]
> https://archives.gentoo.org/gentoo-user/message/6ef4447b7ffa34910ed203f4fff73cfc
> [3] https://bugs.gentoo.org/show_bug.cgi?id=345337#c18
> [4]
> https://archives.gentoo.org/gentoo-dev/message/b39c9b7365f0482ed1d5236d9ae2f6f4
>
> Best regards,
> Andrew Savchenko
>

Re: [gentoo-dev] the graveyard overlay

[james]

On 07/08/2016 10:33 AM, Andrew Savchenko wrote:

On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:

I'm starting a new thread so this will be a completely separate
discussion.

On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:

On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:

On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  wrote:


Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed.  These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.



IMO the criteria should be whether they work or not.  Not whether
upstream is more or less active.

If they're blockers on other work, by all means cull them.  However,
if the biggest problem with them is that they're using a few inodes in
the repo, then they should probably stay.


+1

Best regards,
Andrew Savchenko


There is also an overlay for packages that are removed from the official
tree [1], and imo that is where old software should go if it doesn't
have an active maintainer.


I disagree with the criteria. Old is not necessarily sufficiently 
broken. Granted every package should have a maintainer, but the lack 
thereof is not sufficient for removal.




I don't know why we haven't been using this, but using it more than we
have makes a lot of sense.


NP-H. just published a basic guide on how to resurrect  packages from 
github. Perhaps that should be tested by both devs and users, and 
modified and further documented to be compatible with 'the graveyard 
overlay' and those instructions linked to the graveyard.


In the future, the graveyard will itself look like the gentoo tree, 
except for the actual package contained therein, including  categories 
and files ? Patches? Sources ? How is the graveyard going to look and 
function for retrieval a year or two from now? Bare-bones copies of 
ebuilds only? Just like the attic, this 'graveyard' will be visited
often for package to be returned at least to a user's 
/usr/local/portage. So why not implement the full set of tooling for 
such needs

into the graveyard concept ?



When software is in the main tree, it is a subject of tree-wide
changes like GLEP 67 update, package moves and so on. In a
separated overlay it will be completely abandoned and it may create
inter-overlay dependencies issues (e.g. when A is an old
package from the tree and package B from some overlay depends on A,
so if A will move to graveyard, B will be broken).



I completely do not understand why having "old" software in tree is
a problem, if such software have no serious issues and is not
blocking major progress. If software _is_ sufficiently broken, then
indeed move it to graveyard.



As I said yesterday on IRC, one of the greatest virtues of Gentoo
is its ample spectra of packages available in the main tree. I do
not understand why it should be killed for nothing.


+1

Clearly we have significant differences in the dev and user communities 
on viability and usefulness of old packages. Perhaps the solution is to 
be conservative on tree removal, but aggressive on concurrent status via 
labeling of packages. For example, all of these issues  could be added 
to a simple tool like app-portage/eix to show, for example security, age 
 of last update and maintainer status, and any other issues deemed 
significant.




Best regards,
Andrew Savchenko


hth,
James

Re: [gentoo-dev] the graveyard overlay

[Michał Górny]

On Fri, 8 Jul 2016 18:33:35 +0300
Andrew Savchenko  wrote:

> On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:
> > I'm starting a new thread so this will be a completely separate
> > discussion.
> > 
> > On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:  
> > > On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:  
> > > > On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile 
> > > >  wrote:  
> > > > >
> > > > > Also there's some debate in IRC about whether or not these packages
> > > > > should be lastrited or dropped to maintainer-needed.  These forks are
> > > > > not in good shape upstream, so I think it makes better sense to
> > > > > p.mask/lastrite and then move them to the graveyard overlay when I
> > > > > remove them from the tree in 30 days.
> > > > >  
> > > > 
> > > > IMO the criteria should be whether they work or not.  Not whether
> > > > upstream is more or less active.
> > > > 
> > > > If they're blockers on other work, by all means cull them.  However,
> > > > if the biggest problem with them is that they're using a few inodes in
> > > > the repo, then they should probably stay.  
> > >  
> > > +1
> > > 
> > > Best regards,
> > > Andrew Savchenko  
> > 
> > There is also an overlay for packages that are removed from the official
> > tree [1], and imo that is where old software should go if it doesn't
> > have an active maintainer.
> > 
> > I don't know why we haven't been using this, but using it more than we
> > have makes a lot of sense.  
> 
> When software is in the main tree, it is a subject of tree-wide
> changes like GLEP 67 update, package moves and so on. In a
> separated overlay it will be completely abandoned and it may create
> inter-overlay dependencies issues (e.g. when A is an old
> package from the tree and package B from some overlay depends on A,
> so if A will move to graveyard, B will be broken).

And that is the exact problem. As long as it's in Gentoo, it creates
work for others. Others who have enough work already without your help,
thank you.

There is a major difference between doing a global changes involving
few dozen or hundred packages when they are maintained, and having few
dozen more unmaintained packages to care for. The changes already
require a lot of effort, you know.

Now, there's a significant difference between lastriting unmaintained
packages at treecleaner's leisure and having a clean tree to work on,
and having to figure out how many of the packages blocking some global
change are unmaintained and if they can be cleaned, and cleaning them
while doing something completely different, then checking again,
then...

> I completely do not understand why having "old" software in tree is
> a problem, if such software have no serious issues and is not
> blocking major progress. If software _is_ sufficiently broken, then
> indeed move it to graveyard.

Right now, we have over 1500 unmaintained packages. Please tell me, how
that speaks of Gentoo? Because as far as I can see, we have 1500
packages which nobody looks after unless forced to.

You say that there are no bugs in those packages. How do you know? You
don't know unless you test it, and no maintainer means nobody is known
to test it regularly. The package can be pretty much completely broken
and we'll not know unless someone tests it.

Now, as long as package is in ::gentoo it is somehow officially
supported. Which means it pops up for user when he is looking for
something, and he assumes it's going to solve his problem. This is good
if it works. But considering it's unmaintained, nobody's testing it.

So the package might work, or it might not. It might have major
problems but nobody may notice them before user learns about them
the hard way. If he reports a bug, the bug goes to /dev/null, unless
some developer accidentally notices it and decides to fix it. Or just
lastrite the package.

Let me summarize the user experience. User was looking for a good tool.
Instead, he found a well-advertised unmaintained old piece of software
that promised to solve his problems and instead created more problems
for him. Nevertheless, he decided to be a good user and reported
the bug. Then he learned that nobody cares to fix the bug, the package
is long forgotten, and all his effort was for nothing.

Then he has to look for an alternative... and he starts to wonder how
to filter out those unmaintained packages because he'd rather use
something that somebody has really tested in the last 5 years.

-- 
Best regards,
Michał Górny



pgp8CsLSWOWQU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] masking and removing *coin packages

[Michał Górny]

On Fri, 8 Jul 2016 19:09:04 +0300
Andrew Savchenko  wrote:

> On Fri, 8 Jul 2016 10:01:58 -0500 William Hubbs wrote:
> > On Fri, Jul 08, 2016 at 08:10:07AM -0500, james wrote:  
> > > On 07/08/2016 05:17 AM, Andrew Savchenko wrote:  
> > > > On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:  
> > > >> Hi everyone,
> > > >>
> > > >> I emailed the list some time ago about giving away a bunch of bitcoin
> > > >> forks to see if anyone was interested in taking them.  I didn't get any
> > > >> feedback so as of tomorrow I'll be masking the following for removal in
> > > >> 30 days.  
> > > >
> > > > Any reason for mask and removal? Are these packages broken?
> > > > Just drop them to maintainer-needed.
> > > >
> > > > Best regards,
> > > > Andrew Savchenko
> > > >  
> > > 
> > > Perhaps we should start posting these  orphaned-package announcements to 
> > > gentoo-user, so folks interested in learning about ebuilds can ponder 
> > > proxy-maintenance of a few packages as an opportunity?  
> > 
> > I'm not sure that's necessary, that's what g-d-a is for.  
> 
> How many users are subscribed to the gentoo-dev-announce ML? The
> very name suggests that this is development announce, not something
> related to our users.
> 
> We already duplicate Last-rites messages to gentoo-dev ML, why not
> add gentoo-user here too? Why do we need to duplicate Last-rites on
> gentoo-dev in the first place? I suppose there are two reasons:
> 
> 1) even not all devs are subscribed to gentoo-dev-announce;
> 2) this is a moderated list, which creates some delays.

There is a significant difference between duplicating message 
to a post-only announcement list, and having it on two regular traffic
lists.


-- 
Best regards,
Michał Górny



pgpslDVAkl0Sf.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: the graveyard overlay

[Andrew Savchenko]

On Fri, 8 Jul 2016 10:55:49 -0500 »Q« wrote:
> On Fri, 8 Jul 2016 10:11:45 -0500
> William Hubbs  wrote:
> 
> > There is also an overlay for packages that are removed from the
> > official tree [1], and imo that is where old software should go if it
> > doesn't have an active maintainer.
> > 
> > I don't know why we haven't been using this, but using it more than we
> > have makes a lot of sense.
> 
> Completely aside from the question of criteria for removing stuff from
> the main tree, it would make a lot of users happy if every package
> which *is* removed were added to the graveyard overlay.

Good idea, since we have attic no more, and users need this [1].
While any removed package can be extracted from git, this is not
a trivial operation and is definitely harder then fetching filesv
from overlay.

But the problem is that this way overlay will become completely
broken in terms of both QA and security.

[1] 
https://archives.gentoo.org/gentoo-dev/message/660e7f65e1b4d3f932aacfb69e273e3b

Best regards,
Andrew Savchenko


pgpV0tokLu35d.pgp
Description: PGP signature

Re: [gentoo-dev] why is the security team running around p.masking packages

[Andrew Savchenko]

On Wed, 6 Jul 2016 23:13:55 +0300 Andrew Savchenko wrote:
> On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
> > What kind of policing would you like to see councilman?  Would you like to 
> > see me removed from the project, because your precious package was 
> > p.masked?  You have ignored every thing I have said regarding your 
> > inability to work with the security team.  Even after an apology from me 
> > and a request to work with us you continue on with the rhetoric of powers.  
> > It displays a lot about your inability to work with others.
> > 
> > No other developer is complaining... it is *literally* only you.
> 
> It is really not just him. I do not agree with media-video/motion
> pmask with 30-days removal term. But I had not pushed this issue
> hard, since I'm not a maintainer of this package.
> 
> If this package would have been masked without removal term, I can
> at least accept if not agree with such action. But there is no
> other alternative for this package and security bugs are not
> critical (at least they do not affect many use cases at all). So
> removal from the tree will harm our users sufficiently.
> 
> When approach is "mask until issues are resolved, so that users are
> informed about security hazard" — it sounds reasonable, and we
> already have several packages in the tree this way. But when
> approach is to purge package from the tree in 30 days regardless of
> severity of security flaws and ignoring the fact that there is
> nothing to replace this package with — this is not a kind of the
> policy I'd like to see in Gentoo.
> 
> Please understand me correctly: I'm not blaming you or security
> team for this or that issue. But it looks like security team indeed
> needs to review some policies and approaches to suit needs of
> Gentoo users better in both of terms of security and usability, to
> find some reasonable compromise between them, which will satisfy
> most users. For these very issues it looks like canceling "removal
> in 30 days" clause from p.mask action will do the job.

One more package to the list: app-cdr/xcdroast. It was being tree
cleaned[1] due to a minor security flaw (o+r on suid binary) on
optional functionality disabled by default (so users have to enable
that suid binary themselves each time after package update).

And despite multiple calls from users (see user comments on [1]
and read whole thread [2]) saying they need this package, they were
asked by security team to "stop spamming this bug"[3]. Such actions
in my opinion make more harm then good by deteriorating user
experience and number of choices available, while bringing only
small and not always meaningful security improve.

So it looks like that both security and treecleaners teams need to
review their policies or at least discuss these problems publicly
in more detail. Looks like one such discussion is emerging in
thread [4].

[1] https://bugs.gentoo.org/show_bug.cgi?id=345337
[2] 
https://archives.gentoo.org/gentoo-user/message/6ef4447b7ffa34910ed203f4fff73cfc
[3] https://bugs.gentoo.org/show_bug.cgi?id=345337#c18
[4] 
https://archives.gentoo.org/gentoo-dev/message/b39c9b7365f0482ed1d5236d9ae2f6f4

Best regards,
Andrew Savchenko


pgpXpl0MilrPI.pgp
Description: PGP signature

[gentoo-dev] Re: the graveyard overlay

[»Q«]

On Fri, 8 Jul 2016 10:11:45 -0500
William Hubbs  wrote:

> There is also an overlay for packages that are removed from the
> official tree [1], and imo that is where old software should go if it
> doesn't have an active maintainer.
> 
> I don't know why we haven't been using this, but using it more than we
> have makes a lot of sense.

Completely aside from the question of criteria for removing stuff from
the main tree, it would make a lot of users happy if every package
which *is* removed were added to the graveyard overlay.

Re: [gentoo-dev] the graveyard overlay

[Andrew Savchenko]

On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:
> I'm starting a new thread so this will be a completely separate
> discussion.
> 
> On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
> > On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:
> > > On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  
> > > wrote:
> > > >
> > > > Also there's some debate in IRC about whether or not these packages
> > > > should be lastrited or dropped to maintainer-needed.  These forks are
> > > > not in good shape upstream, so I think it makes better sense to
> > > > p.mask/lastrite and then move them to the graveyard overlay when I
> > > > remove them from the tree in 30 days.
> > > >
> > > 
> > > IMO the criteria should be whether they work or not.  Not whether
> > > upstream is more or less active.
> > > 
> > > If they're blockers on other work, by all means cull them.  However,
> > > if the biggest problem with them is that they're using a few inodes in
> > > the repo, then they should probably stay.
> >  
> > +1
> > 
> > Best regards,
> > Andrew Savchenko
> 
> There is also an overlay for packages that are removed from the official
> tree [1], and imo that is where old software should go if it doesn't
> have an active maintainer.
> 
> I don't know why we haven't been using this, but using it more than we
> have makes a lot of sense.

When software is in the main tree, it is a subject of tree-wide
changes like GLEP 67 update, package moves and so on. In a
separated overlay it will be completely abandoned and it may create
inter-overlay dependencies issues (e.g. when A is an old
package from the tree and package B from some overlay depends on A,
so if A will move to graveyard, B will be broken).

I completely do not understand why having "old" software in tree is
a problem, if such software have no serious issues and is not
blocking major progress. If software _is_ sufficiently broken, then
indeed move it to graveyard.

As I said yesterday on IRC, one of the greatest virtues of Gentoo
is its ample spectra of packages available in the main tree. I do
not understand why it should be killed for nothing.

Best regards,
Andrew Savchenko


pgpWOJzchbcVv.pgp
Description: PGP signature

Re: [gentoo-dev] masking and removing *coin packages

[Anthony G. Basile]

On 7/8/16 10:42 AM, Rich Freeman wrote:
> On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  
> wrote:
>>
>> Also there's some debate in IRC about whether or not these packages
>> should be lastrited or dropped to maintainer-needed.  These forks are
>> not in good shape upstream, so I think it makes better sense to
>> p.mask/lastrite and then move them to the graveyard overlay when I
>> remove them from the tree in 30 days.
>>
> 
> IMO the criteria should be whether they work or not.  Not whether
> upstream is more or less active.

There is a QA against the current version of namecoin* and upstreams
newest packages are no good.

> 
> If they're blockers on other work, by all means cull them.  However,
> if the biggest problem with them is that they're using a few inodes in
> the repo, then they should probably stay.
> 

I have no strong feeling here, but I do want to get rid of them.  So I'm
okay with maintainer-needed@  I'll let the discussion continue for a bit
and then do whatever the consensus is.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] the graveyard overlay

[William Hubbs]

I'm starting a new thread so this will be a completely separate
discussion.

On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
> On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:
> > On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  
> > wrote:
> > >
> > > Also there's some debate in IRC about whether or not these packages
> > > should be lastrited or dropped to maintainer-needed.  These forks are
> > > not in good shape upstream, so I think it makes better sense to
> > > p.mask/lastrite and then move them to the graveyard overlay when I
> > > remove them from the tree in 30 days.
> > >
> > 
> > IMO the criteria should be whether they work or not.  Not whether
> > upstream is more or less active.
> > 
> > If they're blockers on other work, by all means cull them.  However,
> > if the biggest problem with them is that they're using a few inodes in
> > the repo, then they should probably stay.
>  
> +1
> 
> Best regards,
> Andrew Savchenko

There is also an overlay for packages that are removed from the official
tree [1], and imo that is where old software should go if it doesn't
have an active maintainer.

I don't know why we haven't been using this, but using it more than we
have makes a lot of sense.

William

[1] https://github.com/gentoo/graveyard


signature.asc
Description: Digital signature

Re: [gentoo-dev] masking and removing *coin packages

[William Hubbs]

On Fri, Jul 08, 2016 at 08:10:07AM -0500, james wrote:
> On 07/08/2016 05:17 AM, Andrew Savchenko wrote:
> > On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:
> >> Hi everyone,
> >>
> >> I emailed the list some time ago about giving away a bunch of bitcoin
> >> forks to see if anyone was interested in taking them.  I didn't get any
> >> feedback so as of tomorrow I'll be masking the following for removal in
> >> 30 days.
> >
> > Any reason for mask and removal? Are these packages broken?
> > Just drop them to maintainer-needed.
> >
> > Best regards,
> > Andrew Savchenko
> >
> 
> Perhaps we should start posting these  orphaned-package announcements to 
> gentoo-user, so folks interested in learning about ebuilds can ponder 
> proxy-maintenance of a few packages as an opportunity?

I'm not sure that's necessary, that's what g-d-a is for.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] masking and removing *coin packages

[Andrew Savchenko]

On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:
> On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  
> wrote:
> >
> > Also there's some debate in IRC about whether or not these packages
> > should be lastrited or dropped to maintainer-needed.  These forks are
> > not in good shape upstream, so I think it makes better sense to
> > p.mask/lastrite and then move them to the graveyard overlay when I
> > remove them from the tree in 30 days.
> >
> 
> IMO the criteria should be whether they work or not.  Not whether
> upstream is more or less active.
> 
> If they're blockers on other work, by all means cull them.  However,
> if the biggest problem with them is that they're using a few inodes in
> the repo, then they should probably stay.
 
+1

Best regards,
Andrew Savchenko


pgpTATvMiWKjx.pgp
Description: PGP signature

Re: Re: [gentoo-dev] masking and removing *coin packages

[Rich Freeman]

On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile  wrote:
>
> Also there's some debate in IRC about whether or not these packages
> should be lastrited or dropped to maintainer-needed.  These forks are
> not in good shape upstream, so I think it makes better sense to
> p.mask/lastrite and then move them to the graveyard overlay when I
> remove them from the tree in 30 days.
>

IMO the criteria should be whether they work or not.  Not whether
upstream is more or less active.

If they're blockers on other work, by all means cull them.  However,
if the biggest problem with them is that they're using a few inodes in
the repo, then they should probably stay.

-- 
Rich

Fwd: Re: [gentoo-dev] masking and removing *coin packages

[Anthony G. Basile]

Okay,  I'll set the metadata.xml for both net-p2p/litecoin* and
sys-process/nmon to the following:


http://www.gentoo.org/dtd/metadata.dtd;>


marc.p...@sunny-computing.de
Marc Popp
Maintainer. Assign bugs to him


proxy-ma...@gentoo.org
Proxy Maintainers




Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed.  These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.

I haven't acted yet, so there's still time to bikeshed ;)


On 7/8/16 4:32 AM, Marc Popp wrote:
> Hi Anthony,
> 
> I would take over the litecoin* packages, but my last (and first) request
> to take over nmon was not even approved it answered yet. I guess, I wasn't
> following the right process.
> 
> Thanks
> Marc
> 
> 
> 
> On Friday, 8 July 2016, Anthony G. Basile  wrote:
> 
>> Hi everyone,
>>
>> I emailed the list some time ago about giving away a bunch of bitcoin
>> forks to see if anyone was interested in taking them.  I didn't get any
>> feedback so as of tomorrow I'll be masking the following for removal in
>> 30 days.
>>
>> net-dns/namecoind
>> net-dns/namecoin-qt
>>
>> net-p2p/bitcoinxtd
>> net-p2p/bitcoinxt-qt
>>
>> net-p2p/litecoind
>> net-p2p/litecoin-qt
>>
>> net-p2p/ppcoind
>> net-p2p/ppcoin-qt
>>
>> net-p2p/primecoind
>> net-p2p/primecoin-qt
>>
>> --
>> Anthony G. Basile, Ph.D.
>> Gentoo Linux Developer [Hardened]
>> E-Mail: bluen...@gentoo.org 
>> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
>> GnuPG ID  : F52D4BBA
>>
>>
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] masking and removing *coin packages

[Andrew Savchenko]

On Fri, 8 Jul 2016 08:10:07 -0500 james wrote:
> On 07/08/2016 05:17 AM, Andrew Savchenko wrote:
> > On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:
> >> Hi everyone,
> >>
> >> I emailed the list some time ago about giving away a bunch of bitcoin
> >> forks to see if anyone was interested in taking them.  I didn't get any
> >> feedback so as of tomorrow I'll be masking the following for removal in
> >> 30 days.
> >
> > Any reason for mask and removal? Are these packages broken?
> > Just drop them to maintainer-needed.
> >
> > Best regards,
> > Andrew Savchenko
> >
> 
> Perhaps we should start posting these  orphaned-package announcements to 
> gentoo-user, so folks interested in learning about ebuilds can ponder 
> proxy-maintenance of a few packages as an opportunity?
> 
> 
> Surely there is a wider audience that will see some packages they like
> are going away because there are not enough maintainers, and thus 
> respond by 'stepping up' to maintain a few packages?

The idea sounds reasonable, but it doesn't answer why we have a
highly alarming tendency of purging working packages from the tree
just because they have no maintainer.

Best regards,
Andrew Savchenko


pgpUlNpgJIhdd.pgp
Description: PGP signature

Re: [gentoo-dev] masking and removing *coin packages

[james]

On 07/08/2016 05:17 AM, Andrew Savchenko wrote:

On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:

Hi everyone,

I emailed the list some time ago about giving away a bunch of bitcoin
forks to see if anyone was interested in taking them.  I didn't get any
feedback so as of tomorrow I'll be masking the following for removal in
30 days.


Any reason for mask and removal? Are these packages broken?
Just drop them to maintainer-needed.

Best regards,
Andrew Savchenko



Perhaps we should start posting these  orphaned-package announcements to 
gentoo-user, so folks interested in learning about ebuilds can ponder 
proxy-maintenance of a few packages as an opportunity?



Surely there is a wider audience that will see some packages they like
are going away because there are not enough maintainers, and thus 
respond by 'stepping up' to maintain a few packages?


hth,
James

Re: [gentoo-dev] masking and removing *coin packages

[Andrew Savchenko]

On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote:
> Hi everyone,
> 
> I emailed the list some time ago about giving away a bunch of bitcoin
> forks to see if anyone was interested in taking them.  I didn't get any
> feedback so as of tomorrow I'll be masking the following for removal in
> 30 days.

Any reason for mask and removal? Are these packages broken?
Just drop them to maintainer-needed.

Best regards,
Andrew Savchenko


pgpjkGoWZ84vM.pgp
Description: PGP signature