Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 06/01/17 17:14, Alec Warner wrote: > > Treecleaning to me is really two things: > > 1) developer maintenance time. > a) It costs nothing to add packages to the tree, and the tree grows > in size every year. > b) Removals occur due to obsolescence (X replaces Y, etc) but these > are strictly less than the addition rate. > c) Treecleaning is an attempt to aid in the reducing growth rate of > tree size by removing packages. > d) The concern here is nominally overall maintenance work (not a > technical component like computing resources.) > 2) A clear indication that this ebuild is unmaintained and may be > broken; even if marked stable. > a) Nominally we have maintainer-needed or similar tags for packages > which indicates this. > b) Packages tended to be tested at stabilization time, but never > tested again[1] ( sometimes for years.) > c) The packages have no maintainer, so have many open bugs, and users > shout into the void on bugzilla. This leads to a bad user experience. > > The nice thing about ::graveyard or similar is that its a clear > demarcation between maintained (in tree) and unmaintained (graveyard.) > It also means that people doing actual maintenance work can basically > ignore the graveyard as a matter of policy. The ebuilds are archived > there (for users) but since they are unmaintained they may not work > correctly. > > [1] Tinderboxing can help here, specifically if upstream provides a > test suite so we know the package builds and does some correct things. > I think a ::graveyard policy would be much better policy, with perhaps an 'auto-clean' strategy after, say, 5 years. That way, fast-updating users could be caught fine by the 30 day policy, and those who perhaps don't update for a year, could be pulled up by ::graveyard. Of course, anyone sufficiently inclined can drag something up from the archives of either/any tree, but this would provide a better case for handling those users who aren't constantly updating stable or running ~arch. There are often good reasons for not updating every week, but currently Gentoo doesn't support these users very well [self included]. signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 06/01/17 15:01, Rich Freeman wrote: > On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote: >> If packages had a field called "BUGS=" it could contain an array of >> bugs a package is known to contain, but can be conditionally avoided if >> you're careful. >> >> Packages with non-empty BUGS= fields would be treated as hard-masked >> for the purpose of repoman checks, and so packages that depend on >> specific version ranges of packages with BUGS= fields are invalid, >> and need their own BUGS= fields. >> > So, while I'm not sure if this is the best way to go about it, I think > what it does point to is there being possible benefit in creating a > closer link between our repository and bug trackers. > > We've seen this come up in managing stable requests as well (having > users be able to vote on things, having automated testing, etc). > > With the recent stable changes we have bugs being tagged with "atoms." > With your proposal we have ebuilds being tagged with bugs. > > I can see benefits to having a single way to associate bugs and > ebuilds, and making those associations available to bug trackers and > package managers. > > I think the question is: > 1. What is the best way to go about this? > 2. Is anybody actually going to make use of this? > > The intended use cases in #2 probably will influence #1. However, it > doesn't make sense to have multiple ways of doing these associations, > because bugzilla doesn't know anything about the repo, and portage > doesn't know anything about bugzilla. Having one place to store the > associations and tools to make that information accessible elsewhere > makes more sense. > #gentoo-grumpy :) o/ leio ! signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 06/01/17 04:27, Kent Fredric wrote: > On Tue, 3 Jan 2017 10:23:02 -0500 > Rich Freeman wrote: > >> I tend to be firmly in the camp that a package shouldn't be removed >> unless there is evidence of a serious bug (and that includes things >> blocking other Gentoo packages). > I would probably go further and extend that argument to older versions > of packages, for similar reasons, at least in regards to older versions > with specific and exclusive APIs. > > Our duty as maintainers is to protect our users from the mistakes > upstream make as much as possible, not to protect ourselves as > maintainers from having difficult challenges. > > But our duty here doesn't extend to protecting users from problems the > user knows don't affect them. > > If for example, a media playback suite has a memory corruption bug when > playing media of a certain type, making it unusable when playing that > media, it does seem reasonable for us at first to kill that suite. > > However, if the user in question knows they're never going to play > that certain type of media, and only uses that media suite for a narrow > and specific kind of problem, then we're not serving them much utility, > or much freedom of choice by ripping this tool out of their hands for a > problem they'll never have. > > Maybe we need an intermediate option, where the sensible default when > we discover this kind of error is to remove it, but provide a way to > easily restore that package if the users are ok with it. > > Like, this is not my proposal, just an idea so you can see where I'm > headed with thoughts: > > If packages had a field called "BUGS=" it could contain an array of > bugs a package is known to contain, but can be conditionally avoided if > you're careful. > > Packages with non-empty BUGS= fields would be treated as hard-masked > for the purpose of repoman checks, and so packages that depend on > specific version ranges of packages with BUGS= fields are invalid, > and need their own BUGS= fields. > > Users get portage by default telling them "X package has to go away, > because it has bug #145 , #1286234, and #123756" > > And if this is not satisfactory, they can override portage with > > ACCEPT_BUGS="145 1286234 123756" > > You could even have > > BUGS=" x86? ( 112345 )" > > This to me sounds like a more user-empowering approach. > > The only questions to me are: > > - Do we have the resources to support this kind of strategy? > - How much additional complexity and confusion will this introduce for > users? > - Is that additional complexity and confusion something users want to > indulge, or is our current feature set already too complex. > > That last one is pretty much the one that weighs most on my mind > lately, with users frequently stumped by handling subslot upgrades > and required-use conflicts. > > Granted, this is just yet-another alternative flavour of hard-masking > things, so I'd rather we stick with careful use of hardmasks to inform > users of problems they might face, allowing them to contravene the hard > masks if they're feeling like they want to be adults. > > > +1 I like this proposal .. we are supposedly a distribution of Choice and Flexibility .. part of that is being an adult about making that choice available, and the consequences of it .. Just my 2c50 as usual ;) signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Friday, January 6, 2017 9:13:20 AM EST Michael Mol wrote: > > The bigger resource drain, I suspect, will come from maintaining new ebuilds > of old packages; as eclass development and maintenance seeks to eliminate > old and buggy code, old ebuilds will need to be dragged along for the ride. This is already taking place, and has since the first EAPI. I am not opposed to such things, EAPI. But EAPI does lead to what I call "ebuild wheel spinning". Constantly revising an ebuilds internals that may or may not produce much. May not close any bugs, may not change installed files, may prevent future bugs. But does create more work, and why some stuff remains behind all the way back to EAPI=0. It blows me away how some old ebuilds that should be removed, get touched and improved per eclass and other changes. Or things get updated, but not the package itself. Lots of work that produces very little end benefit. Like revising patches for -p1, when they patch may apply fine now with epatch. Modifying -pN of a patch is minor, but still consumes time for very little if any benefit. Patch applied before, patch applies when changed to -p1. What was the benefit for that time spent? -- William L. Thomson Jr. signature.asc Description: This is a digitally signed message part.
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote: > > The nice thing about ::graveyard or similar is that its a clear demarcation > between maintained (in tree) and unmaintained (graveyard.) It also means > that people doing actual maintenance work can basically ignore the > graveyard as a matter of policy. The ebuilds are archived there (for users) > but since they are unmaintained they may not work correctly. This is what the Java team used to do. There was a java-graveyard-overlay. I do not believe any package ever moved there came back into the tree. It did result in a pretty messed up overlay, but makes it a user problem. At the same time, something could always be restored from VC. Not like removal is removing all history and traces. Thus not sure such overlay is really even beneficial. Using it could cause lots of problems if they just care about 1 package or a few. -- William L. Thomson Jr. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: x11-libs/gtk+:1
# Mart Raudsepp (06 Jan 2017) # No releases of this API version since April 2001, abandoned # in favour of gtk+:2 for 14 years. # Masked for removal in 30 days. Bug 604862. x11-libs/gtk+:1
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner wrote: > > So my understanding of the status quo is that maintainers get to make the > call with regard to what is reasonable to keep or drop. I'm loathe to add > additional policy here; mostly because the expectation is that the > maintainer has the most state here. That doesn't mean you can't: > I think the main concern is with unmaintained packages. -- Rich
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric wrote: > On Tue, 3 Jan 2017 10:23:02 -0500 > Rich Freeman wrote: > > > I tend to be firmly in the camp that a package shouldn't be removed > > unless there is evidence of a serious bug (and that includes things > > blocking other Gentoo packages). > > I would probably go further and extend that argument to older versions > of packages, for similar reasons, at least in regards to older versions > with specific and exclusive APIs. > > So my understanding of the status quo is that maintainers get to make the call with regard to what is reasonable to keep or drop. I'm loathe to add additional policy here; mostly because the expectation is that the maintainer has the most state here. That doesn't mean you can't: 1) Try to convince the maintainer that older versions are needed to support some important use case. 2) Volunteer to help in maintenance of older versions to support your important use case. I'm unclear on how having a more explicit policy is advantageous. > Our duty as maintainers is to protect our users from the mistakes > upstream make as much as possible, not to protect ourselves as > maintainers from having difficult challenges. > But our duty here doesn't extend to protecting users from problems the > user knows don't affect them. > > If for example, a media playback suite has a memory corruption bug when > playing media of a certain type, making it unusable when playing that > media, it does seem reasonable for us at first to kill that suite. > > However, if the user in question knows they're never going to play > that certain type of media, and only uses that media suite for a narrow > and specific kind of problem, then we're not serving them much utility, > or much freedom of choice by ripping this tool out of their hands for a > problem they'll never have. > > Maybe we need an intermediate option, where the sensible default when > we discover this kind of error is to remove it, but provide a way to > easily restore that package if the users are ok with it. > > Like, this is not my proposal, just an idea so you can see where I'm > headed with thoughts: > > If packages had a field called "BUGS=" it could contain an array of > bugs a package is known to contain, but can be conditionally avoided if > you're careful. > > Packages with non-empty BUGS= fields would be treated as hard-masked > for the purpose of repoman checks, and so packages that depend on > specific version ranges of packages with BUGS= fields are invalid, > and need their own BUGS= fields. > > Users get portage by default telling them "X package has to go away, > because it has bug #145 , #1286234, and #123756" > > And if this is not satisfactory, they can override portage with > > ACCEPT_BUGS="145 1286234 123756" > > You could even have > > BUGS=" x86? ( 112345 )" > > This to me sounds like a more user-empowering approach. > Treecleaning to me is really two things: 1) developer maintenance time. a) It costs nothing to add packages to the tree, and the tree grows in size every year. b) Removals occur due to obsolescence (X replaces Y, etc) but these are strictly less than the addition rate. c) Treecleaning is an attempt to aid in the reducing growth rate of tree size by removing packages. d) The concern here is nominally overall maintenance work (not a technical component like computing resources.) 2) A clear indication that this ebuild is unmaintained and may be broken; even if marked stable. a) Nominally we have maintainer-needed or similar tags for packages which indicates this. b) Packages tended to be tested at stabilization time, but never tested again[1] ( sometimes for years.) c) The packages have no maintainer, so have many open bugs, and users shout into the void on bugzilla. This leads to a bad user experience. The nice thing about ::graveyard or similar is that its a clear demarcation between maintained (in tree) and unmaintained (graveyard.) It also means that people doing actual maintenance work can basically ignore the graveyard as a matter of policy. The ebuilds are archived there (for users) but since they are unmaintained they may not work correctly. [1] Tinderboxing can help here, specifically if upstream provides a test suite so we know the package builds and does some correct things. The only questions to me are: > > - Do we have the resources to support this kind of strategy? > - How much additional complexity and confusion will this introduce for > users? > - Is that additional complexity and confusion something users want to > indulge, or is our current feature set already too complex. > > That last one is pretty much the one that weighs most on my mind > lately, with users frequently stumped by handling subslot upgrades > and required-use conflicts. > > Granted, this is just yet-another alternative flavour of hard-masking > things, so I'd rather we stick with careful use of hardmasks to inform > users of problems they might face, allowin
Re: [gentoo-dev] New Project: Gentoostats
On 01/06/2017 08:08 AM, Gokturk Yuksek wrote:
> Hi,
>
> Daniel Campbell:
>> On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
>>> Alexander Shorin:
Hi!
Thanks for sharing. Would be nice see updated README file (it contains
outdated links to Not Found pages) and add few notes about comparison
of your solution with collectd, ussd and the rest modern stats
collecting tools.
How better it suites Gentoo machines and why to use it today instead
of any existed and mature tool?
>>>
>>> We are interested in different kinds of stats with gentoostats. The main
>>> purpose of gentoostats is to collect package statistics, and currently
>>> it does so by utilizing the Portage API. Here's a sample output from the
>>> gentoostats-cli tool that may give you a better idea:
>>>
>>> $ gentoostats-cli search --c sys-apps --p portage --v 2.3.0 --r gentoo
>>> --min_hosts 4
>>> Search results
>>> [{'CAT': 'sys-apps',
>>> 'HOSTS': 5,
>>> 'PKG': 'portage',
>>> 'REPO': 'gentoo',
>>> 'VER': '2.3.0'}]
>>>
>>> There is also other Gentoo-specific information it collects such as this:
>>>
>>> $ gentoostats-cli list arch
>>> Arch
>>> {'amd64': {'HOSTS': 4}, 'x86': {'HOSTS': 1}}
>>>
--
,,,^..^,,,
>>>
>>> --
>>> gokturk
>>>
>>>
>> Is it too late to suggest more standard flags? `--c` for example doesn't
>> make sense to me since '--' is used more for GNU long options. So it
>> should be '--category' and '-c' instead. Of course that's just my
>> opinion, so take it with salt as usual. :)
>>
>
> That's a typo on my part, thanks for pointing it out :) It's
> '-c/--category', '-p/--package', '-v/--version' and '-r/--repo'. I used
> the long options, then decided to go with the short ones to increase
> readability, forgot to remove extra '-'.
>
>> Still, interesting project and I might run it on a machine if it can
>> help us out.
>>
>
>
I guess we can ignore that little nitpick then. :P
I'll check it out when I get some time to spare.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote: > > If packages had a field called "BUGS=" it could contain an array of > bugs a package is known to contain, but can be conditionally avoided if > you're careful. > > Packages with non-empty BUGS= fields would be treated as hard-masked > for the purpose of repoman checks, and so packages that depend on > specific version ranges of packages with BUGS= fields are invalid, > and need their own BUGS= fields. > So, while I'm not sure if this is the best way to go about it, I think what it does point to is there being possible benefit in creating a closer link between our repository and bug trackers. We've seen this come up in managing stable requests as well (having users be able to vote on things, having automated testing, etc). With the recent stable changes we have bugs being tagged with "atoms." With your proposal we have ebuilds being tagged with bugs. I can see benefits to having a single way to associate bugs and ebuilds, and making those associations available to bug trackers and package managers. I think the question is: 1. What is the best way to go about this? 2. Is anybody actually going to make use of this? The intended use cases in #2 probably will influence #1. However, it doesn't make sense to have multiple ways of doing these associations, because bugzilla doesn't know anything about the repo, and portage doesn't know anything about bugzilla. Having one place to store the associations and tools to make that information accessible elsewhere makes more sense. -- Rich
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote: > On Tue, 3 Jan 2017 10:23:02 -0500 > > Rich Freeman wrote: > > I tend to be firmly in the camp that a package shouldn't be removed > > unless there is evidence of a serious bug (and that includes things > > blocking other Gentoo packages). > > I would probably go further and extend that argument to older versions > of packages, for similar reasons, at least in regards to older versions > with specific and exclusive APIs. > > Our duty as maintainers is to protect our users from the mistakes > upstream make as much as possible, not to protect ourselves as > maintainers from having difficult challenges. > > But our duty here doesn't extend to protecting users from problems the > user knows don't affect them. > > If for example, a media playback suite has a memory corruption bug when > playing media of a certain type, making it unusable when playing that > media, it does seem reasonable for us at first to kill that suite. > > However, if the user in question knows they're never going to play > that certain type of media, and only uses that media suite for a narrow > and specific kind of problem, then we're not serving them much utility, > or much freedom of choice by ripping this tool out of their hands for a > problem they'll never have. > > Maybe we need an intermediate option, where the sensible default when > we discover this kind of error is to remove it, but provide a way to > easily restore that package if the users are ok with it. > > Like, this is not my proposal, just an idea so you can see where I'm > headed with thoughts: > > If packages had a field called "BUGS=" it could contain an array of > bugs a package is known to contain, but can be conditionally avoided if > you're careful. > > Packages with non-empty BUGS= fields would be treated as hard-masked > for the purpose of repoman checks, and so packages that depend on > specific version ranges of packages with BUGS= fields are invalid, > and need their own BUGS= fields. > > Users get portage by default telling them "X package has to go away, > because it has bug #145 , #1286234, and #123756" > > And if this is not satisfactory, they can override portage with > > ACCEPT_BUGS="145 1286234 123756" > > You could even have > > BUGS=" x86? ( 112345 )" > > This to me sounds like a more user-empowering approach. I really like where this is going. > > The only questions to me are: > > - Do we have the resources to support this kind of strategy? How much of the work can be automated? I.e. can bugs on bgo be tagged such that a maintainer's script can scoop up the bugs and apply them, at least naively? Being able to express something like "x86? (!mmx)" clearly in a bgo ticket's metadata could well be useful, and would lend itself to something like this. The bigger resource drain, I suspect, will come from maintaining new ebuilds of old packages; as eclass development and maintenance seeks to eliminate old and buggy code, old ebuilds will need to be dragged along for the ride. > - How much additional complexity and confusion will this introduce for > users? I think you'd want autounmask to not support applying changes for automatically unmasking bugs. Apart from that, it shouldn't result in any additional complexity or confusion for users who aren't deliberately holding on to package versions that have known bugs. Most of the users I've seen who would be faced with this functionality are the users who will run a gymnastics course just to use a browser version that has an old, familiar interface. > - Is that additional complexity and confusion something users want to > indulge, or is our current feature set already too complex. So long as it stays out of a user's way until the user needs it, I wouldn't say it adds needless complexity from a user's perspective. > > That last one is pretty much the one that weighs most on my mind > lately, with users frequently stumped by handling subslot upgrades > and required-use conflicts. Choosing to engage with this functionality sounds like very much an opt-in experience for the user; the path of least resistance is to go ahead and update (and that will generally provide the best-tested global configuration), but if they wish to hold on to difficult configurations, they can at least do that. There is one other advantage to a system like this; it permits for a larger, deeper tree, with old versions more frequently available. That'll significantly assist the upgrade efforts of people who go ridiculous amounts of time between @world updates, people who are dusting off stowed systems, etc. > > Granted, this is just yet-another alternative flavour of hard-masking > things, so I'd rather we stick with careful use of hardmasks to inform > users of problems they might face, allowing them to contravene the hard > masks if they're feeling like they want to be adults. signature.asc Description: This is a digital
[gentoo-dev] Drop global USE=frontbase
The "frontbase" USE flag has no consumers that I can find: gentoo.git $ grep -irl frontbase * profiles/arch/x86/use.mask profiles/use.desc profiles/base/use.mask If no one objects, I'll drop the flag and its masks.
Re: [gentoo-dev] Packages up for grabs due to retirement
Ühel kenal päeval, N, 05.01.2017 kell 22:00, kirjutas Daniel Campbell: > I'm in favor of keeping software around until it breaks. When there's > a > non-existent upstream and nobody's willing to take up the helm > themselves, it's a clear indication that it's in danger of being > treecleaned. In some cases that's good; some packages get left behind > and never updated, CVEs get released, CVEs don't get released about dead packages that no-one cares about or has installed as no-one is checking them for bugs and evaluating if they are security bugs. They just sit there, potentially providing a nice potential security hole to abuse. > nobody cares about the package and > it sits masked for a while. Those are the packages we should consider > for treecleaning, not just "oh it's been 2 years since a release" or > "upstream website troubles". > > On the latter count, does anyone attempt to reach upstream before > suggesting we get rid of the package(s)? Is there not some forum we > can > use to reach users who may be interested in proxy-maintaining it? > This > discussion makes me wonder if we need (more) formal guidelines for > treecleaning. I think we've got a few people who are eager to clean > the > tree -- and their goal is admirable -- but until we can get metrics > on > who's using what, it's hard to say how much damage removing a package > will do for users. A thread on gentoo-user re: lastrites might not be > a > bad idea. The package.masked message that is shown to a user having it installed is supposed to be providing that forum to potential proxy-maintainers and such, to step up and fix things within that period and save it from permanent deletion. That's the reason we just don't outright delete them immediately, but do this "last rited, deletion in 30 days" dance. Even though the message doesn't repeatedly say this for all the p.mask descriptions (but maybe the package manager stock extra text does, or should). And ultimately things can be added back, when sensible, e.g a new upstream appears that fixes issues, or whatever. Perhaps this user interested in it enough to care deeply about it being remove from Gentoo is interested enough to become that upstream or chase down someone who is willing to, or provide motivation to the old upstream, or...
