[gentoo-dev] Packages up for grabs due to retirement

[gentoo-dev] Packages up for grabs due to retirement

[Thomas Kahle]

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

Hi,

I will retire, so here are my remaining packages.  Feel free to
e-mail me any questions re this.  sci-math is in CC because there
are quite a few math packages.

app-emacs/undo-tree
app-misc/anki
app-portage/tatt
app-text/tesseract
app-text/pdfsandwich
dev-cpp/gtest
dev-python/python-wpactrl
dev-python/python-iwscan
media-sound/gmtp
net-misc/wicd
sci-libs/bliss
sci-libs/mpir
sci-libs/lrslib
sci-mathematics/gfan
sci-mathematics/nauty
sci-mathematics/singular
sci-mathematics/frobby
sci-mathematics/normaliz
sci-mathematics/polymake
sci-mathematics/4ti2
sci-mathematics/bertini
sci-mathematics/topcom
sci-mathematics/gimps
sci-mathematics/xmds
sci-mathematics/Macaulay2
sci-misc/flashdot
www-apps/tt-rss

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[James Le Cuirot]

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

On Sat, 31 Dec 2016 22:54:28 +0100
Thomas Kahle <tomka@gentoo.org> wrote:

> I will retire

Sorry to hear that. :(

> app-text/tesseract

I maintain media-libs/leptonica, which is primarily in the tree because
of Tesseract. I don't use Tesseract myself though and it's not a
trivial package to maintain so I'd rather someone else picked it up.
Surely one of you does some OCR? This is the best free software OCR
project around.

> www-apps/tt-rss

I'll take this one. I use it every day.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Thomas Kahle]

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

On 01/01/2017 00:00, James Le Cuirot wrote:
> On Sat, 31 Dec 2016 22:54:28 +0100
> Thomas Kahle <tomka@gentoo.org> wrote:
> 
>> I will retire
> 
> Sorry to hear that. :(
> 
>> app-text/tesseract
> 
> I maintain media-libs/leptonica, which is primarily in the tree because
> of Tesseract. I don't use Tesseract myself though and it's not a
> trivial package to maintain so I'd rather someone else picked it up.
> Surely one of you does some OCR? This is the best free software OCR
> project around.

I started maintaining tesseract because I use

app-text/pdfsandwich

Maybe takers also want to look at this.  It's very little work (but it
depends on ocaml).

>> www-apps/tt-rss
> 
> I'll take this one. I use it every day.

Very good.  Note that this has a rolling release model upstream.
The master branch is considered stable.  I used to make a tarball
from this every 3 or 4 months and host them on my devspace.
Please also change the SRC_URI for the current ebuilds, as my
devspace will go offline eventually.

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


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

[gentoo-dev] Re: Packages up for grabs due to retirement

[David Seifert]

On Sat, 2016-12-31 at 22:54 +0100, Thomas Kahle wrote:
> Hi,
> 
> I will retire, so here are my remaining packages.  Feel free to
> e-mail me any questions re this.  sci-math is in CC because there
> are quite a few math packages.
> 
> app-emacs/undo-tree
> app-misc/anki
> app-portage/tatt
> app-text/tesseract
> app-text/pdfsandwich
> dev-cpp/gtest
> dev-python/python-wpactrl
> dev-python/python-iwscan
> media-sound/gmtp
> net-misc/wicd
> sci-libs/bliss
> sci-libs/mpir
> sci-libs/lrslib
> sci-mathematics/gfan
> sci-mathematics/nauty
> sci-mathematics/singular
> sci-mathematics/frobby
> sci-mathematics/normaliz
> sci-mathematics/polymake
> sci-mathematics/4ti2
> sci-mathematics/bertini
> sci-mathematics/topcom
> sci-mathematics/gimps
> sci-mathematics/xmds
> sci-mathematics/Macaulay2
> sci-misc/flashdot
> www-apps/tt-rss
> 
> Cheers,
> Thomas
> 
> 

Sad to see you go Thomas. As a finalising act, could you please assign

  sci-{libs,misc}/* -> sci project
  sci-mathematics/* -> sci-mathematics project

We will then maintain those packages as part of the project.

Regards
David

Re: [gentoo-dev] Packages up for grabs due to retirement

[James Le Cuirot]

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

On Sun, 1 Jan 2017 10:42:51 +0100
Thomas Kahle <tomka@gentoo.org> wrote:

> On 01/01/2017 00:00, James Le Cuirot wrote:
> > On Sat, 31 Dec 2016 22:54:28 +0100
> > Thomas Kahle <tomka@gentoo.org> wrote:
> >   
> >> I will retire  
> > 
> > Sorry to hear that. :(
> >   
> >> app-text/tesseract  
> > 
> > I maintain media-libs/leptonica, which is primarily in the tree because
> > of Tesseract. I don't use Tesseract myself though and it's not a
> > trivial package to maintain so I'd rather someone else picked it up.
> > Surely one of you does some OCR? This is the best free software OCR
> > project around.  
> 
> I started maintaining tesseract because I use
> 
> app-text/pdfsandwich
> 
> Maybe takers also want to look at this.  It's very little work (but it
> depends on ocaml).

Just want to add that if it sounds like I'm being lazy, I don't
actually use Leptonica either! I only maintain it because I've
developed a close relation with upstream over the years that stemmed
from trying to get (the now defunct) Audiveris to work.

> >> www-apps/tt-rss  
> > 
> > I'll take this one. I use it every day.  
> 
> Very good.  Note that this has a rolling release model upstream.
> The master branch is considered stable.  I used to make a tarball
> from this every 3 or 4 months and host them on my devspace.
> Please also change the SRC_URI for the current ebuilds, as my
> devspace will go offline eventually.

Yeah, I did notice that. Upstream does still make the odd tag even
since he announced it's now rolling but I guess I shouldn't wait for
those to appear. No need to host it on devspace though.

https://tt-rss.org/gitlab/fox/tt-rss/repository/archive.tar.gz?ref=832aa24943f6b65a811dc6c7414dede412ab1ec6

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

[gentoo-dev] Re: Packages up for grabs due to retirement

[Thomas Kahle]

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

On 01/01/2017 10:48, David Seifert wrote:
> On Sat, 2016-12-31 at 22:54 +0100, Thomas Kahle wrote:
>> Hi,
>>
>> I will retire, so here are my remaining packages.  Feel free to
>> e-mail me any questions re this.  sci-math is in CC because there
>> are quite a few math packages.
>>
>> app-emacs/undo-tree
>> app-misc/anki
>> app-portage/tatt
>> app-text/tesseract
>> app-text/pdfsandwich
>> dev-cpp/gtest
>> dev-python/python-wpactrl
>> dev-python/python-iwscan
>> media-sound/gmtp
>> net-misc/wicd
>> sci-libs/bliss
>> sci-libs/mpir
>> sci-libs/lrslib
>> sci-mathematics/gfan
>> sci-mathematics/nauty
>> sci-mathematics/singular
>> sci-mathematics/frobby
>> sci-mathematics/normaliz
>> sci-mathematics/polymake
>> sci-mathematics/4ti2
>> sci-mathematics/bertini
>> sci-mathematics/topcom
>> sci-mathematics/gimps
>> sci-mathematics/xmds
>> sci-mathematics/Macaulay2
>> sci-misc/flashdot
>> www-apps/tt-rss
>>
>> Cheers,
>> Thomas
>>
>>
> 
> Sad to see you go Thomas. As a finalising act, could you please assign
> 
>   sci-{libs,misc}/* -> sci project
>   sci-mathematics/* -> sci-mathematics project
> 
> We will then maintain those packages as part of the project.

Done.  They all had the relevant projects as maintainers listed, so I
just removed myself.  sci-libs/bliss also has ottxor as a maintainer.

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Lars Wendler]

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

Hi Thomas,

On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:

>Hi,
>
>I will retire, so here are my remaining packages. 

Sad day seeing another dev leaving :-(

>net-misc/wicd

I can take this one if nobody else is interested in it.


>Cheers,
>Thomas
>
>

I wish you all the best and if you ever feel the urge, please come
back :)

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Packages up for grabs due to retirement

[Brian Evans]

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

On 01/01/2017 12:16 PM, Lars Wendler wrote:
> Hi Thomas,
> 
> On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:
> 
>> Hi,
>>
>> I will retire, so here are my remaining packages. 
> 
> Sad day seeing another dev leaving :-(
> 
>> net-misc/wicd
> 
> I can take this one if nobody else is interested in it.

IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools and WEXT.

Brian


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[grozin]

On Mon, 2 Jan 2017, Brian Evans wrote:
> IMO, this one should be given last-rites as upstream is dead and it
> heavily depends on wireless-tools and WEXT.
I use it on 2 notebooks. It works fine, and is (from my point of view) the 
most convenient tool to control ethernet and wifi connections on a 
notebook. Why lastrite it when it works?

Andrey

Re: [gentoo-dev] Packages up for grabs due to retirement

[Michał Górny]

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

On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
grozin@gentoo.org wrote:

> On Mon, 2 Jan 2017, Brian Evans wrote:
> > IMO, this one should be given last-rites as upstream is dead and it
> > heavily depends on wireless-tools and WEXT.  
> I use it on 2 notebooks. It works fine, and is (from my point of view) the 
> most convenient tool to control ethernet and wifi connections on a 
> notebook. Why lastrite it when it works?

This is the Gentoo Way™. Having a working software is not a goal.
Gentoo focuses on the best bleeding edge experience and therefore
highly relies on software packages that are under active development
and require active maintenance. The packages in early stages of
development are especially interesting since they can supply users
and developers with variety of interesting bugs and unpredictable
issues.

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

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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Lars Wendler]

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

Hi,

On Tue, 3 Jan 2017 16:00:52 +0700 (+07) grozin@gentoo.org wrote:

>On Mon, 2 Jan 2017, Brian Evans wrote:
>> IMO, this one should be given last-rites as upstream is dead and it
>> heavily depends on wireless-tools and WEXT.  

this is plain wrong. Upstream is not dead, just not very active anymore.

>I use it on 2 notebooks. It works fine, and is (from my point of view)
>the most convenient tool to control ethernet and wifi connections on a 
>notebook. Why lastrite it when it works?
>
>Andrey
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

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

On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> 
> grozin@gentoo.org wrote:
> > On Mon, 2 Jan 2017, Brian Evans wrote:
> > > IMO, this one should be given last-rites as upstream is dead and it
> > > heavily depends on wireless-tools and WEXT.
> > 
> > I use it on 2 notebooks. It works fine, and is (from my point of view) the
> > most convenient tool to control ethernet and wifi connections on a
> > notebook. Why lastrite it when it works?
> 
> This is the Gentoo Way™. Having a working software is not a goal.
> Gentoo focuses on the best bleeding edge experience and therefore
> highly relies on software packages that are under active development
> and require active maintenance. The packages in early stages of
> development are especially interesting since they can supply users
> and developers with variety of interesting bugs and unpredictable
> issues.

Do we have detailed treatise documenting the points and counterpoints to "Why 
lastrite it when it works?" It's a question that comes up every month or two, 
and the reasons, for and against, are probably mature enough to get numbers, 
now.

Reason #3 in favor: "It works for me" may only be valid from a particular 
perspective. Without active maintenance, there may be subtle bugs that aren't 
immediately obvious. Bugs that aren't immediately obvious aren't always 
innocuous; sometimes they're insidious background data loss. Other times, they 
might be security vulnerabilities no good guy has yet noticed.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Damien LEVAC]

On 01/03/2017 09:14 AM, Michael Mol wrote:
> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>>
>> grozin@gentoo.org wrote:
>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>> heavily depends on wireless-tools and WEXT.
>>> I use it on 2 notebooks. It works fine, and is (from my point of view) the
>>> most convenient tool to control ethernet and wifi connections on a
>>> notebook. Why lastrite it when it works?
>> This is the Gentoo Way™. Having a working software is not a goal.
>> Gentoo focuses on the best bleeding edge experience and therefore
>> highly relies on software packages that are under active development
>> and require active maintenance. The packages in early stages of
>> development are especially interesting since they can supply users
>> and developers with variety of interesting bugs and unpredictable
>> issues.
> Do we have detailed treatise documenting the points and counterpoints to "Why
> lastrite it when it works?" It's a question that comes up every month or two,
> and the reasons, for and against, are probably mature enough to get numbers,
> now.
>
> Reason #3 in favor: "It works for me" may only be valid from a particular
> perspective. Without active maintenance, there may be subtle bugs that aren't
> immediately obvious. Bugs that aren't immediately obvious aren't always
> innocuous; sometimes they're insidious background data loss. Other times, they
> might be security vulnerabilities no good guy has yet noticed.
...and sometimes a package just stop being "actively" maintained because 
it is feature-complete (as far as the goals of the project were 
concerned) and just works.

The minimum conditions to lastrite something should be not actively 
maintained _and_ with open bugs that either compromise security or 
affect normal usage subject to the condition that it is not still used 
by users. I do not think at this point in time Gentoo devs have any mean 
to know the popularity of different packages, but that would be a must 
to take proper decision as far as retiring packages goes.

-- Just a random Gentoo user.

Re: [gentoo-dev] Packages up for grabs due to retirement

[M. J. Everitt]

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

On 03/01/17 11:05, Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> grozin@gentoo.org wrote:
>
>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>> IMO, this one should be given last-rites as upstream is dead and it
>>> heavily depends on wireless-tools and WEXT.  
>> I use it on 2 notebooks. It works fine, and is (from my point of view) the 
>> most convenient tool to control ethernet and wifi connections on a 
>> notebook. Why lastrite it when it works?
> This is the Gentoo Way™. Having a working software is not a goal.
> Gentoo focuses on the best bleeding edge experience and therefore
> highly relies on software packages that are under active development
> and require active maintenance. The packages in early stages of
> development are especially interesting since they can supply users
> and developers with variety of interesting bugs and unpredictable
> issues.
>
From your response I infer the following, please discuss:
1) "working software is not a goal" .. so we can have a tree full of
broken and/or unstable packages. What is the point of any QA/CI system
if this is applicable?
2) "require active maintainance" .. by whom exactly? Where are the flood
of keen developers bringing their bleeding edge code (with their
ludicrous packaging requirements and language demands) to Gentoo?
3) "interesting bugs and unpredictable isssue" .. WTF?

Michal .. are you (once again...) High .. or is your email (once again)
so soaked in sarcasm we can't tell any useful content from the complete
drivel ...


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Damien LEVAC]

On 01/03/2017 09:31 AM, M. J. Everitt wrote:
> On 03/01/17 11:05, Michał Górny wrote:
>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>> grozin@gentoo.org wrote:
>>
>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>> heavily depends on wireless-tools and WEXT.
>>> I use it on 2 notebooks. It works fine, and is (from my point of view) the
>>> most convenient tool to control ethernet and wifi connections on a
>>> notebook. Why lastrite it when it works?
>> This is the Gentoo Way™. Having a working software is not a goal.
>> Gentoo focuses on the best bleeding edge experience and therefore
>> highly relies on software packages that are under active development
>> and require active maintenance. The packages in early stages of
>> development are especially interesting since they can supply users
>> and developers with variety of interesting bugs and unpredictable
>> issues.
>>
>  From your response I infer the following, please discuss:
> 1) "working software is not a goal" .. so we can have a tree full of
> broken and/or unstable packages. What is the point of any QA/CI system
> if this is applicable?
> 2) "require active maintainance" .. by whom exactly? Where are the flood
> of keen developers bringing their bleeding edge code (with their
> ludicrous packaging requirements and language demands) to Gentoo?
> 3) "interesting bugs and unpredictable isssue" .. WTF?
>
> Michal .. are you (once again...) High .. or is your email (once again)
> so soaked in sarcasm we can't tell any useful content from the complete
> drivel ...
>
It was obviously sarcasm... The "Gentoo Way™" was the hint... It is a 
cynical criticism of younger generation of developers mixing 
intellectual curiosity with what should be an ultra-stable platform. (Or 
this is how I interpreted it...)

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

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

On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
> On 01/03/2017 09:14 AM, Michael Mol wrote:
> > On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> >> 
> >> grozin@gentoo.org wrote:
> >>> On Mon, 2 Jan 2017, Brian Evans wrote:
> >>>> IMO, this one should be given last-rites as upstream is dead and it
> >>>> heavily depends on wireless-tools and WEXT.
> >>> 
> >>> I use it on 2 notebooks. It works fine, and is (from my point of view)
> >>> the
> >>> most convenient tool to control ethernet and wifi connections on a
> >>> notebook. Why lastrite it when it works?
> >> 
> >> This is the Gentoo Way™. Having a working software is not a goal.
> >> Gentoo focuses on the best bleeding edge experience and therefore
> >> highly relies on software packages that are under active development
> >> and require active maintenance. The packages in early stages of
> >> development are especially interesting since they can supply users
> >> and developers with variety of interesting bugs and unpredictable
> >> issues.
> > 
> > Do we have detailed treatise documenting the points and counterpoints to
> > "Why lastrite it when it works?" It's a question that comes up every
> > month or two, and the reasons, for and against, are probably mature
> > enough to get numbers, now.
> > 
> > Reason #3 in favor: "It works for me" may only be valid from a particular
> > perspective. Without active maintenance, there may be subtle bugs that
> > aren't immediately obvious. Bugs that aren't immediately obvious aren't
> > always innocuous; sometimes they're insidious background data loss. Other
> > times, they might be security vulnerabilities no good guy has yet
> > noticed.
> 
> ...and sometimes a package just stop being "actively" maintained because
> it is feature-complete (as far as the goals of the project were
> concerned) and just works.
> 
> The minimum conditions to lastrite something should be not actively
> maintained _and_ with open bugs

What happens when the bugs exist, but nobody knows they're there? Let's say 
someone got a copy of Coverity and ran it on long-stable, ridiculously mature 
packages. They get a bunch of hits, but they keep it to themselves and instead 
develop exploits for the bugs they found.

For security's sake, even mature software needs, at minimum, routine auditing. 
Unless someone's doing that work, the package should be considered for 
removal. (Call that reason #	π, in honor of TeX.)

(I'm really not trying to start yet another massive thread on the subject, 
hence my original question: Do we have a documented treatise on the question? 
Not "Gentoo's Official Policy", but rather the rationales and counterpoints?) 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Kristian Fiskerstrand]

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

On 01/03/2017 03:57 PM, Michael Mol wrote:
> For security's sake, even mature software needs, at minimum, routine auditing. 
> Unless someone's doing that work, the package should be considered for 
> removal. (Call that reason #	π, in honor of TeX.)

A distinction here likely needs to be made between actively maintained
upstream and actively Gentoo maintained as well. Actively maintained
upstream might not be an issue for a feature complete package, but if it
lacks a Gentoo-maintainer in addition it is worrying.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Damien LEVAC]

On 01/03/2017 09:57 AM, Michael Mol wrote:
> On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
>> On 01/03/2017 09:14 AM, Michael Mol wrote:
>>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
>>>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>>>>
>>>> grozin@gentoo.org wrote:
>>>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>>>> heavily depends on wireless-tools and WEXT.
>>>>> I use it on 2 notebooks. It works fine, and is (from my point of view)
>>>>> the
>>>>> most convenient tool to control ethernet and wifi connections on a
>>>>> notebook. Why lastrite it when it works?
>>>> This is the Gentoo Way™. Having a working software is not a goal.
>>>> Gentoo focuses on the best bleeding edge experience and therefore
>>>> highly relies on software packages that are under active development
>>>> and require active maintenance. The packages in early stages of
>>>> development are especially interesting since they can supply users
>>>> and developers with variety of interesting bugs and unpredictable
>>>> issues.
>>> Do we have detailed treatise documenting the points and counterpoints to
>>> "Why lastrite it when it works?" It's a question that comes up every
>>> month or two, and the reasons, for and against, are probably mature
>>> enough to get numbers, now.
>>>
>>> Reason #3 in favor: "It works for me" may only be valid from a particular
>>> perspective. Without active maintenance, there may be subtle bugs that
>>> aren't immediately obvious. Bugs that aren't immediately obvious aren't
>>> always innocuous; sometimes they're insidious background data loss. Other
>>> times, they might be security vulnerabilities no good guy has yet
>>> noticed.
>> ...and sometimes a package just stop being "actively" maintained because
>> it is feature-complete (as far as the goals of the project were
>> concerned) and just works.
>>
>> The minimum conditions to lastrite something should be not actively
>> maintained _and_ with open bugs
> What happens when the bugs exist, but nobody knows they're there? Let's say
> someone got a copy of Coverity and ran it on long-stable, ridiculously mature
> packages. They get a bunch of hits, but they keep it to themselves and instead
> develop exploits for the bugs they found.
>
> For security's sake, even mature software needs, at minimum, routine auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason #	π, in honor of TeX.)
>
> (I'm really not trying to start yet another massive thread on the subject,
> hence my original question: Do we have a documented treatise on the question?
> Not "Gentoo's Official Policy", but rather the rationales and counterpoints?)
But routine auditing, while being wishful thinking in the open-source 
world (even when the projects are alive), are not meant to find those 
kind of bugs anyway (and wouldn't be effective at doing so either).

I would argue that those concerns apply to every packages to different 
degree and you might not be safer (on the contrary) with a maintained 
but more experimental package...

Even if just for the sake of stability, shouldn't there be a policy of 
inertia? I.e. if it is not broken it does not need fixing, or something 
like that? Like you said, this topic comes every once in a while and 
every time it is a waste of time. Unless there is an unknown maintaining 
cost in having it in the tree unmaintained?

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[M. J. Everitt]

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

On 03/01/17 14:57, Michael Mol wrote:
> On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
>> On 01/03/2017 09:14 AM, Michael Mol wrote:
>>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
>>>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>>>>
>>>> grozin@gentoo.org wrote:
>>>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>>>> heavily depends on wireless-tools and WEXT.
>>>>> I use it on 2 notebooks. It works fine, and is (from my point of view)
>>>>> the
>>>>> most convenient tool to control ethernet and wifi connections on a
>>>>> notebook. Why lastrite it when it works?
>>>> This is the Gentoo Way™. Having a working software is not a goal.
>>>> Gentoo focuses on the best bleeding edge experience and therefore
>>>> highly relies on software packages that are under active development
>>>> and require active maintenance. The packages in early stages of
>>>> development are especially interesting since they can supply users
>>>> and developers with variety of interesting bugs and unpredictable
>>>> issues.
>>> Do we have detailed treatise documenting the points and counterpoints to
>>> "Why lastrite it when it works?" It's a question that comes up every
>>> month or two, and the reasons, for and against, are probably mature
>>> enough to get numbers, now.
>>>
>>> Reason #3 in favor: "It works for me" may only be valid from a particular
>>> perspective. Without active maintenance, there may be subtle bugs that
>>> aren't immediately obvious. Bugs that aren't immediately obvious aren't
>>> always innocuous; sometimes they're insidious background data loss. Other
>>> times, they might be security vulnerabilities no good guy has yet
>>> noticed.
>> ...and sometimes a package just stop being "actively" maintained because
>> it is feature-complete (as far as the goals of the project were
>> concerned) and just works.
>>
>> The minimum conditions to lastrite something should be not actively
>> maintained _and_ with open bugs
> What happens when the bugs exist, but nobody knows they're there? Let's say 
> someone got a copy of Coverity and ran it on long-stable, ridiculously mature 
> packages. They get a bunch of hits, but they keep it to themselves and instead 
> develop exploits for the bugs they found.
>
> For security's sake, even mature software needs, at minimum, routine auditing. 
> Unless someone's doing that work, the package should be considered for 
> removal. (Call that reason #	π, in honor of TeX.)
>
> (I'm really not trying to start yet another massive thread on the subject, 
> hence my original question: Do we have a documented treatise on the question? 
> Not "Gentoo's Official Policy", but rather the rationales and counterpoints?) 
Possibly this page may help:

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

Also

https://wiki.gentoo.org/wiki/Project:Bug-cleaners

is quite enlightening [having burnt my fingers on those].


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> For security's sake, even mature software needs, at minimum, routine auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason #    π, in honor of TeX.)
>

Are you suggesting that we should ban any package from the tree if we
don't have evidence of it having recently being subjected to a
security audit?  We might literally have 3 packages left in the tree
in that case, probably not including the kernel (forget the GNU/Linux
debate, we might be neither).

The fact that a project gets 47 commits and 100 list posts a week
doesn't mean that it is being security audited, or that security is
any kind of serious consideration in how their workflow operates.

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).  If somebody wants to come up with a
"curated" overlay or some way of tagging packages that are considered
extra-secure that would be a nice value-add, but routine auditing is
not a guarantee we provide to our users.  The lack of such an audit
should not be a reason to treeclean.

-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Alice Ferrazzi]

On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@gmail.com> wrote:
>>
>> For security's sake, even mature software needs, at minimum, routine auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reason #    π, in honor of TeX.)
>>
>
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit?  We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
>
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.
>
> 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).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add, but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

+1

>
> --
> Rich
>



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi <alicef@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

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

On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@gmail.com> wrote:
> > For security's sake, even mature software needs, at minimum, routine
> > auditing. Unless someone's doing that work, the package should be
> > considered for removal. (Call that reason #    π, in honor of TeX.)
> 
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit? 

Of course not. Full security audits are stupid expensive, be it in terms of 
money, time or labor. It Would Be Nice if they at least periodically got 
subjected to -Werror -Wall from time to time, or at least a linter check, or 
some tie-in to Coverity, with the results considered, but even that's going to 
be too much to ask an upstream to accept patches for.

Besides, there are going to be vulnerabilities that come from combinations of 
packages and their environments; something that's fine on x86 might have a 
critical vulnerability on arm. Something that's fine on x86_64 might have a bug 
that only presents itself in a constrained address space like x86. Something 
that's generally fine on its own might have a subtle bug that only manifests 
when a particular version of another package's headers are present at build 
time.

It's ludicrous to be absolutist about security. As I remarked to someone the 
other day, there are always more things to fix or secure than you'll have 
resources to follow though on. If someone one think a system is as secure as 
it can possibly be, then they're not as clever as they think they are.

> We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
> 
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.

I'm sure we all remember Heartbleed.

> 
> 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).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add,

Ideas like this is one reason I'm looking for a corpus of pros and cons for 
treecleaning. I don't see it as black and white. But having ideas like these 
brought up is at least useful.

> but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

I'm not trying to drive a "clean all the things" campaign. Rather, I'm 
principally interested in having a list of the standard arguments one way or 
another, for reference in the inevitable "why should this get cleaned up? It 
works." threads.

There's an old joke that goes something like this:

> Joe is going to his first comedian's convention. He's excited to see all 
> these funny people in person.

> The opening session begins with Robert, who gets up and says, "42!" Everyone 
> busts a gut laughing. Then Susan gets up and says, "73!" Again, everyone 
> laughs.

> Joe asks the guy next to him, "What's going on? I don't get it."

> "Oh, you see, everyone's heard all the same jokes over and over, so to save 
time, they reference them by number."

> "Ah! Let me give it a try."

> Joe stands up and says, "3!" Nobody laughs. Embarassed, Joe sits back down.

> "I don't understand," Joe says to the guy next to him. Why didn't anyone 
> laugh? Was 3 a poor joke?

> "Oh, no, 3 is fine, but the key is in the timing!"

Essentially, I'm looking for the joke book. Because these recurring threads 
would be a lot more interesting and less time-consuming and frictive if 
recurring material could be quickly identified and referenced. And then someone 
who still has a point to make can say, "Well, 3 is more important than 7, and 
here's why." And then have less spilling of words and boiling of blood 
irritating everyone and hardening positions before we get to consider 
something new.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> Ideas like this is one reason I'm looking for a corpus of pros and cons for
> treecleaning. I don't see it as black and white. But having ideas like these
> brought up is at least useful.
>

Sure, and almost any rule has its exceptions.  My throwing out my
opinion should be viewed as intended to add to the conversation, not
halt it.  I do think we should have a policy to keep stuff unless
there is a good reason to remove it, but perhaps those reasons extend
beyond the examples I gave.

-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[james]

On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:
> On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>
>>> For security's sake, even mature software needs, at minimum, routine auditing.
>>> Unless someone's doing that work, the package should be considered for
>>> removal. (Call that reason #    π, in honor of TeX.)
>>>
>>
>> Are you suggesting that we should ban any package from the tree if we
>> don't have evidence of it having recently being subjected to a
>> security audit?  We might literally have 3 packages left in the tree
>> in that case, probably not including the kernel (forget the GNU/Linux
>> debate, we might be neither).
>>
>> The fact that a project gets 47 commits and 100 list posts a week
>> doesn't mean that it is being security audited, or that security is
>> any kind of serious consideration in how their workflow operates.
>>
>> 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).  If somebody wants to come up with a
>> "curated" overlay or some way of tagging packages that are considered
>> extra-secure that would be a nice value-add, but routine auditing is
>> not a guarantee we provide to our users.  The lack of such an audit
>> should not be a reason to treeclean.
>
> +1

>> Rich

Not only do I agree with those sentiments express here (Rich's 
sentiments), I have an additional prospective. I have been deeply 
following the development of clusters, particularly "in-house" clusters
run on less than a dozen systems. There are an endless number of uses
for such clusters, kinda like the modern version of when "X" servers 
were all the rage decades (and decades) ago, at the very least. In fact 
the cluster space for in-house clusters, imho, will eventually end up, 
being a collection of tarballs (stage-4s in gentoo case) that are 
customized for thousands of finely tuned, secure needs. "Unikernels" is 
the current buzzword, that docker and others have been using. [1] and 
have a tightly and minimized framework. Folks that work for "Cloud 
Vendors" should understand that if individuals and small companies are
able to build and run localize, small clusters, then is very easy and 
comfortable for them to expand into hybrid clusters and become 
comfortable with outsourcing to the cloud. Many larger companies I 
consult with or have conversations with, are still uncomfortable with
"cloud" anything. In-house clusters are the gateway to growing the 
entire cloud business, imho.


Many of those old and stable codes, that lots of folks are so keen on 
purging from the tree, are actually quite useful and easy to secure,
for such custom frameworks. Those frameworks can easily be packaged up
into a stage-4 or a forked gentoo  distro or implemented via any number 
of deployment methods, included CoreOS's fleet, recently added to 
portage. Security is the pivotal issue with clusters, whether they are 
in-house or outsourced (the cloud/Paas/Saas/etc) imho.


So keeping those old codes around makes my life easier and more 
interesting. Sure I can go to these old codes and resurrect most, as 
needed, but why be vindictive by purging things that are old? Does the 
younger and more progressive devs in gentoo really want to purge old 
C-hacks like me from the community? I do not mean to offend anyone, but 
it just seems to me to be just plain unjustified purging useful that are 
currently not popular codes, and that hurts me on a personal basis. Us 
'old farts' are the unix historians, here at gentoo; perhaps the more 
aggressive devs will consider being 'politically correct' towards old 
farts that have decades and decades of history, with these old codes?


  Newer codes are valuable too, but often they add a layer of complexity 
and many attack surfaces, that older codes do not suffer from. So, I 
would hope we err on the side of keeping ebuilds  of old codes around as 
long as possible, despite the download count. My work is liable to take 
another year or two to bear fruit, but that's not even the point. I 
would be excited if we could just move these old packages to an overlay, 
if/when they do have to be pruned from the gentoo-proper tree. Perhaps 
the new GLEP on formalizing forking gentoo, will lead to a gentoo-legacy 
fork, just for historical and nostalgic reasons?


I'm betting that these old codes are much more useful than most have 
figured, but it's going to take some time to establish this performance 
and superior security  postulate, as I use 'old-fart' methodologies.....


hth,
James

[1] http://unikernel.org/blog/2015/unikernels-meet-docker

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Matthew Thode]

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

On 01/03/2017 09:11 AM, Damien LEVAC wrote:
> But routine auditing, while being wishful thinking in the open-source
> world (even when the projects are alive), are not meant to find those
> kind of bugs anyway (and wouldn't be effective at doing so either).
> 

I think it's wishful thinking in every world :P

> I would argue that those concerns apply to every packages to different
> degree and you might not be safer (on the contrary) with a maintained
> but more experimental package...
> 
> Even if just for the sake of stability, shouldn't there be a policy of
> inertia? I.e. if it is not broken it does not need fixing, or something
> like that? Like you said, this topic comes every once in a while and
> every time it is a waste of time. Unless there is an unknown maintaining
> cost in having it in the tree unmaintained?


-- 
Matthew Thode (prometheanfire)


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Matthew Thode]

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

On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote:
> On 01/03/2017 03:57 PM, Michael Mol wrote:
>> For security's sake, even mature software needs, at minimum, routine auditing. 
>> Unless someone's doing that work, the package should be considered for 
>> removal. (Call that reason #	π, in honor of TeX.)
> 
> A distinction here likely needs to be made between actively maintained
> upstream and actively Gentoo maintained as well. Actively maintained
> upstream might not be an issue for a feature complete package, but if it
> lacks a Gentoo-maintainer in addition it is worrying.
> 

Agreed, the main thing a package needs is a responsive packager.  If the
packager finds an issue with a package that they can't fix and upstream
is non-responsive then the packager is probably responsible for
tree-cleaning themselves.

-- 
Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Mart Raudsepp]

Ühel kenal päeval, T, 03.01.2017 kell 09:34, kirjutas Damien LEVAC:
> 
> On 01/03/2017 09:31 AM, M. J. Everitt wrote:
> > 
> > On 03/01/17 11:05, Michał Górny wrote:
> > > 
> > > On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> > > grozin@gentoo.org wrote:
> > > 
> > > > 
> > > > On Mon, 2 Jan 2017, Brian Evans wrote:
> > > > > 
> > > > > IMO, this one should be given last-rites as upstream is dead
> > > > > and it
> > > > > heavily depends on wireless-tools and WEXT.
> > > > I use it on 2 notebooks. It works fine, and is (from my point
> > > > of view) the
> > > > most convenient tool to control ethernet and wifi connections
> > > > on a
> > > > notebook. Why lastrite it when it works?
> > > This is the Gentoo Way™. Having a working software is not a goal.
> > > Gentoo focuses on the best bleeding edge experience and therefore
> > > highly relies on software packages that are under active
> > > development
> > > and require active maintenance. The packages in early stages of
> > > development are especially interesting since they can supply
> > > users
> > > and developers with variety of interesting bugs and unpredictable
> > > issues.
> > > 
> >  From your response I infer the following, please discuss:
> > 1) "working software is not a goal" .. so we can have a tree full
> > of
> > broken and/or unstable packages. What is the point of any QA/CI
> > system
> > if this is applicable?
> > 2) "require active maintainance" .. by whom exactly? Where are the
> > flood
> > of keen developers bringing their bleeding edge code (with their
> > ludicrous packaging requirements and language demands) to Gentoo?
> > 3) "interesting bugs and unpredictable isssue" .. WTF?
> > 
> > Michal .. are you (once again...) High .. or is your email (once
> > again)
> > so soaked in sarcasm we can't tell any useful content from the
> > complete
> > drivel ...
> > 
> It was obviously sarcasm... The "Gentoo Way™" was the hint... It is
> a 
> cynical criticism of younger generation of developers mixing 
> intellectual curiosity with what should be an ultra-stable platform.
> (Or 
> this is how I interpreted it...)


I believe with this mgorny has given ample proof that he is just a
ciaranm sock puppet account.
Now where did I leave my pitchfork at...

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Thomas Kahle]

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



On 03/01/2017 15:24, Damien LEVAC wrote:
> 
> 
> On 01/03/2017 09:14 AM, Michael Mol wrote:
>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
>>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>>>
>>> grozin@gentoo.org wrote:
>>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>>> heavily depends on wireless-tools and WEXT.
>>>> I use it on 2 notebooks. It works fine, and is (from my point of
>>>> view) the
>>>> most convenient tool to control ethernet and wifi connections on a
>>>> notebook. Why lastrite it when it works?
>>> This is the Gentoo Way™. Having a working software is not a goal.
>>> Gentoo focuses on the best bleeding edge experience and therefore
>>> highly relies on software packages that are under active development
>>> and require active maintenance. The packages in early stages of
>>> development are especially interesting since they can supply users
>>> and developers with variety of interesting bugs and unpredictable
>>> issues.
>> Do we have detailed treatise documenting the points and counterpoints
>> to "Why
>> lastrite it when it works?" It's a question that comes up every month
>> or two,
>> and the reasons, for and against, are probably mature enough to get
>> numbers,
>> now.
>>
>> Reason #3 in favor: "It works for me" may only be valid from a particular
>> perspective. Without active maintenance, there may be subtle bugs that
>> aren't
>> immediately obvious. Bugs that aren't immediately obvious aren't always
>> innocuous; sometimes they're insidious background data loss. Other
>> times, they
>> might be security vulnerabilities no good guy has yet noticed.
> ...and sometimes a package just stop being "actively" maintained because
> it is feature-complete (as far as the goals of the project were
> concerned) and just works.

Certainly not the case here.  wicd generates lots of complaints from
users and upstream does not exist.  Sometimes distro maintainers float a
patch, but it is definitely in a problematic situation.


> The minimum conditions to lastrite something should be not actively
> maintained _and_ with open bugs that either compromise security or
> affect normal usage subject to the condition that it is not still used
> by users. I do not think at this point in time Gentoo devs have any mean
> to know the popularity of different packages, but that would be a must
> to take proper decision as far as retiring packages goes.
> 
> -- Just a random Gentoo user.
> 

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Kent Fredric]

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

On Tue, 3 Jan 2017 10:23:02 -0500
Rich Freeman <rich0@gentoo.org> 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.




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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Kent Fredric]

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

On Wed, 04 Jan 2017 05:11:18 +0200
Mart Raudsepp <leio@gentoo.org> wrote:

> I believe with this mgorny has given ample proof that he is just a
> ciaranm sock puppet account.

<fake-conspiracy-hat>
One neat trick is to have *two* sock puppet accounts, and then have one
accuse the other of being a sock puppet, which typically leads people
to not suspect the accuser is also a sock puppet, and instead trust the
second account more!

Now, Imagine what you could achieve with *three* sock puppet accounts.

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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Daniel Campbell]

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

On 01/03/2017 06:31 AM, M. J. Everitt wrote:
> On 03/01/17 11:05, Michał Górny wrote:
>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>> grozin@gentoo.org wrote:
>>
>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>> heavily depends on wireless-tools and WEXT.  
>>> I use it on 2 notebooks. It works fine, and is (from my point of view) the 
>>> most convenient tool to control ethernet and wifi connections on a 
>>> notebook. Why lastrite it when it works?
>> This is the Gentoo Way™. Having a working software is not a goal.
>> Gentoo focuses on the best bleeding edge experience and therefore
>> highly relies on software packages that are under active development
>> and require active maintenance. The packages in early stages of
>> development are especially interesting since they can supply users
>> and developers with variety of interesting bugs and unpredictable
>> issues.
>>
> From your response I infer the following, please discuss:
> 1) "working software is not a goal" .. so we can have a tree full of
> broken and/or unstable packages. What is the point of any QA/CI system
> if this is applicable?
> 2) "require active maintainance" .. by whom exactly? Where are the flood
> of keen developers bringing their bleeding edge code (with their
> ludicrous packaging requirements and language demands) to Gentoo?
> 3) "interesting bugs and unpredictable isssue" .. WTF?
> 
> Michal .. are you (once again...) High .. or is your email (once again)
> so soaked in sarcasm we can't tell any useful content from the complete
> drivel ...
> 
Maybe I'm weird but I thought it was funny...

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

Thanks for the laugh Michał. :)

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


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

Re: [gentoo-dev] Packages up for grabs due to retirement

[Mart Raudsepp]

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

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

On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> 
> Rich Freeman <rich0@gentoo.org> 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.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric <kentnl@gentoo.org> 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)

[Alec Warner]

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

On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric <kentnl@gentoo.org> wrote:

> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman <rich0@gentoo.org> 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, allowing them to contravene the hard
> masks if they're feeling like they want to be adults.

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner <antarus@gentoo.org> 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)

[William L. Thomson Jr.]

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

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[William L. Thomson Jr.]

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

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[M. J. Everitt]

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

On 06/01/17 04:27, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman <rich0@gentoo.org> 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 ;)


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[M. J. Everitt]

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

On 06/01/17 15:01, Rich Freeman wrote:
> On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric <kentnl@gentoo.org> 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 !


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[M. J. Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 2178 bytes --]

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

[-- Attachment #1.1.2: Type: text/html, Size: 3270 bytes --]

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Daniel Campbell]

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

On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> 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.
> 

There's a nice trick around that, actually: let's assume the overlay is
called "foo-overlay".

In package.mask:

    */*::foo-overlay

will mask all packages in the overlay. You can then add packages to
package.unmask:

    pkg-cat/foobar::foo-overlay

That should alleviate most issues, though it can make dependencies a
PITA if those deps are also in the overlay. In that case, emerge should
yell at you and suggest adding lines to package.unmask.

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


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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Sam Jorna]

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

On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote:
> On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> > 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.
> > 
> 
> There's a nice trick around that, actually: let's assume the overlay is
> called "foo-overlay".
> 
> In package.mask:
> 
>     */*::foo-overlay
> 
> will mask all packages in the overlay. You can then add packages to
> package.unmask:
> 
>     pkg-cat/foobar::foo-overlay
> 
> That should alleviate most issues, though it can make dependencies a
> PITA if those deps are also in the overlay. In that case, emerge should
> yell at you and suggest adding lines to package.unmask.

Another option would be to set the priority of the overlay to -1001 (one
less than gentoo.git) and explicitly emerge the package from the
overlay:

emerge -a pkg-cat/foobar::foo-overlay

Dependencies will by default be drawn from gentoo.git (if it has equal
or better version(s)), and overlay-only dependencies won't need to be
explicitly unmasked.

You may end up with gentoo.git-provided packages coming from the overlay
if they have newer versions, though when talking about graveyard, that
shouldn't be an issue.

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26


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