Re: [gentoo-dev] RFC: global USE c++11

[Andrew Savchenko]

On Tue, 03 Jan 2017 06:40:44 +0700 Vadim A. Misbakh-Soloviov wrote:
> I bet it is not about ABIs, but about a vallue for '-std' flag for gcc/clang 
> compiler. Some packages allows to select between -std=c++1{1,4,7} (and some - 
> defaults with older ones otherwise).

Yes, -std and some package-related defines. Basically this flag
controls what features of the language package should be allowed to
use.

So +1 for a global USE.


Best regards,
Andrew Savchenko


pgpgiQGxl_fwf.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Global USE cuda

[Andrew Savchenko]

Hi,

On Mon, 2 Jan 2017 21:37:43 + Justin  wrote:
> Hi all
> 
> How about making USE=cuda a global USE?
> 
> Description: Enable support for nVidia CUDA

Sounds reasonable.
 
> Current Situation:
> dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC)
> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
> dev-util/VampirTrace: Enable tracing of CUDA calls and GPU kernels.
> sci-chemistry/ball: Include cuda support
> sci-chemistry/nwchem: Enable CUDA GPU support for the Tensor
> sci-libs/arrayfire: Build CUDA backend.
> sci-libs/bigdft-abi: Enable support for nVidia CUDA
> sci-libs/libgeodecomp: Enables plugins for NVIDIA GPUs (e.g.
> sci-libs/trilinos: Add support for cuda (dev-util/nvidia-cuda-toolkit)
> sci-misc/kaldi: Build with CUDA support.
> sci-physics/abinit: Enable support for nVidia CUDA
> sci-physics/bigdft: Enable support for nVidia CUDA GPU acceleration
> sys-cluster/openmpi: Add GPU direct support
> app-crypt/johntheripper: Use nvidia cuda toolkit for speeding up
> dev-libs/libdynd: Enable NVIDIA CUDA toolkit support
> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
> dev-libs/starpu: Enable NVIDIA CUDA toolkit support
> dev-util/nvidia-cuda-sdk: Build CUDA binaries.
> media-gfx/blender: Build cycles renderer with nVidia CUDA support.
> media-gfx/k3d: Use nvidia cuda toolkit for speeding up computations
> media-gfx/nvidia-texture-tools: Enable NVIDIA CUDA toolkit support
> media-libs/opencv: Enable NVIDIA Cuda computations support
> media-libs/opensubdiv: Enable NVIDIA CUDA Toolkit support through
> net-analyzer/suricata: Enable NVIDIA Cuda computations support
> net-wireless/pyrit: Enable CUDA support via net-wireless/cpyrit-cuda
> sci-chemistry/ball: Include cuda support
> sci-chemistry/gromacs: Enable cuda non-bonded kernels
> sci-chemistry/vmd: Use nvidia cuda toolkit for speeding up
> sci-libs/cholmod: Use nvidia cuda toolkit for speeding up computations
> sci-libs/flann: Enable support for nVidia CUDA
> sci-libs/pcl: Adds support for NVIDIA CUDA.
> sci-libs/suitesparse: Enable nvidia cuda toolkit for speeding up
> sci-misc/boinc: Use nvidia cuda toolkit for speeding up computations.
> sci-physics/espresso: Enable cuda support
> sci-physics/hoomd-blue: Enable cuda non-bonded kernels
> sys-apps/hwloc: Enable CUDA device discovery
> sys-cluster/openmpi: Add GPU direct support
> 
> More or less consistent in enabling CUDA support.
> 
> Best,
> Justin
> 


Best regards,
Andrew Savchenko


pgpiwcvrDgymT.pgp
Description: PGP signature

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Andrew Savchenko]

Hi,

On Mon, 26 Dec 2016 19:25:29 + Robin H. Johnson wrote:
> On Mon, Dec 26, 2016 at 10:45:26AM +0300, Andrew Savchenko wrote:
> > 8 packages are using either rbd or rados USE flag for Rados
> > Block Device support:
> RBD != RADOS.

Thanks for pointing this out.
 
> RBD is the block-device-mapper on top of Ceph/RADOS.
> 
> There are other pieces to put on top of Ceph, such as CephFS & RADOSGW
> (S3/Swift access to RADOS)
> 
> That said, I think at the growth of Ceph, we will have usage for both of
> the USE flags.
 
Then how about the following list for rbd:

app-emulation/ganeti:rbd - Enable rados block device support via 
sys-cluster/ceph
app-emulation/libvirt:rbd - Enable rados block device support via 
sys-cluster/ceph
app-emulation/qemu:rbd - Enable rados block device backend support, see 
http://ceph.newdream.net/wiki/QEMU-RBD
net-libs/xrootd:rbd - Enable rados block device support via sys-cluster/ceph
sys-block/fio:rbd - Enable Rados block device support via sys-cluster/ceph
sys-block/tgt:rbd - Add support for ceph block devices

Also it seems that USE=rados is also invalid, because according to
Ceph architecture [1] librados != rados and what these packages use
is really librados:

app-backup/bareos:rados - Enable rados storage backend
net-analyzer/rrdtool:rados - Enable support for librados from sys-cluster/ceph

So I propose to rename these USE flags to librados to be consistent.

[1] http://docs.ceph.com/docs/master/architecture/
Looks like docs.ceph.com is down right now, so here is another copy:
http://www.virtualtothecore.com/wp-content/uploads/2015/02/ceph-architecture-1.png

Best regards,
Andrew Savchenko


pgpfrCeeBI54m.pgp
Description: PGP signature

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Vadim A. Misbakh-Soloviov]

Shouldn't this
>> app-backup/bareos:rados - Enable rados storage backend
> storage backend
go to the first list?

Re: [gentoo-dev] RFC: global USE c++11

[Kristian Fiskerstrand]

On 01/02/2017 10:34 PM, Justin  wrote:
> 
> Seems to be very consistent in usage.

But I'm not convinced it is a correct approach to have use flag changing
this. First thing that springs to mind is if introducing something like
that it should be done consistently across Gentoo, so a GLEP. But
presumably a lot of packages are already built using C++11 without a use
flag given Qt5.7 requiring it etc.

If using C++11 enables different features the feature should be the use
flag rather than C++11. Couldn't this just be determined using Autotools
etc? What is the gain of the use flag? Immediately it sounds like it
adds complexity without much gain.

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Andrew Savchenko]

Hi,

On Mon, 26 Dec 2016 20:05:58 +0100 Kristian Fiskerstrand wrote:
> On 12/26/2016 08:45 AM, Andrew Savchenko wrote:
> > 8 packages are using either rbd or rados USE flag for Rados
> > Block Device support:
> 
> Are there other possibly conflicting issues of using "rados" rather than
> "rbd" as name (or "radosbd") or someting a bit more verbose than rbd.

As was pointed out by Robin, rados and rbd are different.

Considering verbose alternatives to rbd: they may be invented, but
will be non-standard and this will confuse our users: it will be
similar to "portableng" instead of "png".

Since we don't have rbd meaning conflict right now, it should be
safe to use. In case of future issues, local USE may be used for
alternative meanings.

Best regards,
Andrew Savchenko


pgpHzRVOGKwAg.pgp
Description: PGP signature

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] RFC: global USE c++11

[Justin]

On 03/01/2017 08:51, Kristian Fiskerstrand wrote:
> On 01/02/2017 10:34 PM, Justin  wrote:
>>
>> Seems to be very consistent in usage.
> 
> But I'm not convinced it is a correct approach to have use flag changing
> this. First thing that springs to mind is if introducing something like
> that it should be done consistently across Gentoo, so a GLEP. But
> presumably a lot of packages are already built using C++11 without a use
> flag given Qt5.7 requiring it etc.
> 
> If using C++11 enables different features the feature should be the use
> flag rather than C++11. Couldn't this just be determined using Autotools
> etc? What is the gain of the use flag? Immediately it sounds like it
> adds complexity without much gain.
> 

I tried to find some example usages from upstream. Two things I found

* Most upstreams dropped the flag in recent versions
* If present, it is used to append -std=c++11

Probably we should keep it local and wait until it is gone everywhere
upstream.

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Andrew Savchenko]

On Tue, 03 Jan 2017 15:43:16 +0700 Vadim A. Misbakh-Soloviov wrote:
> Shouldn't this
> >> app-backup/bareos:rados - Enable rados storage backend
> > storage backend
> go to the first list?

No, judging from its source code in uses librados directly.
Though current description is indeed ambiguous.

Best regards,
Andrew Savchenko


pgpHe3eIYMwAj.pgp
Description: PGP signature

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

[Michał Górny]

On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@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



pgpG7elOmLu5J.pgp
Description: OpenPGP digital signature

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

[Lars Wendler]

Hi,

On Tue, 3 Jan 2017 16:00:52 +0700 (+07) gro...@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


pgpETeGr0Dl2V.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Package up for grabs: media-gfx/displaycal

[Bernard Cafarelli]

Le 22/12/2016 11:56, Gokturk Yuksek a écrit :

Hi,

This a slightly delayed up for grabs notice for: media-gfx/displaycal


ArgyllCMS is already in my list, so I can help with this one too.

But co-maintainers are still welcome of course!
--
Bernard Cafarelli (Voyageur)
Gentoo developer

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

[Michael Mol]

On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> 
> gro...@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.

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)

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

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

On 03/01/17 11:05, Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> gro...@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 ...



signature.asc
Description: OpenPGP digital signature

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)
gro...@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: [gentoo-dev] RFC: global USE c++11

[Anthony G. Basile]

On 1/3/17 4:08 AM, Justin  wrote:
> On 03/01/2017 08:51, Kristian Fiskerstrand wrote:
>> On 01/02/2017 10:34 PM, Justin  wrote:
>>>
>>> Seems to be very consistent in usage.
>>
>> But I'm not convinced it is a correct approach to have use flag changing
>> this. First thing that springs to mind is if introducing something like
>> that it should be done consistently across Gentoo, so a GLEP. But
>> presumably a lot of packages are already built using C++11 without a use
>> flag given Qt5.7 requiring it etc.
>>
>> If using C++11 enables different features the feature should be the use
>> flag rather than C++11. Couldn't this just be determined using Autotools
>> etc? What is the gain of the use flag? Immediately it sounds like it
>> adds complexity without much gain.
>>
> 
> I tried to find some example usages from upstream. Two things I found
> 
> * Most upstreams dropped the flag in recent versions
> * If present, it is used to append -std=c++11
> 
> Probably we should keep it local and wait until it is gone everywhere
> upstream.
> 
> Justin
> 

Agreed.  Keep it local.

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

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

[Michael Mol]

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)
> >> 
> >> gro...@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?) 

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)

[Kristian Fiskerstrand]

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



signature.asc
Description: OpenPGP digital signature

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)

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

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)

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



signature.asc
Description: OpenPGP digital signature

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  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  wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, 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.)
>>
>
> 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 
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)

[Rich Freeman]

On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol  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)

[Michael Mol]

On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, 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.)
> 
> 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.

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)

[james]

On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:

On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman  wrote:

On Tue, Jan 3, 2017 at 9:57 AM, 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.)



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]

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)



signature.asc
Description: OpenPGP digital signature

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

[Matthew Thode]

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)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Kent Fredric]

On Mon, 2 Jan 2017 12:49:59 -0500
Rich Freeman  wrote:

> However, in this case why would we want to rule out sets, "and all the
> other shenanigans?"  We've already established that a single stable
> request bug can apply to multiple package-versions, so why not allow
> full dependency specifications?  If there is a set that describes what
> needs to be stabilized in an atomic operation, then what is the value
> in breaking it down into a million separate =-only atoms?

That rather complicates validation.

Mostly, because if you declare a list of dependencies, if any of them is a 
range,
the subgraph of that specific atom becomes variable, not constant.

Which means you may have omitted one of the possible dependencies from one of 
the possible
subgraphs that an AT/Keyworder will see.

This IMO would mostly negate the utility of submitter defined lists of 
specifications.

In that, by making the submitter resolve it all, its either "good" or "bad"

Instead of leaving the person doing the testing in a confused state about which 
packages
are expected to be used.

The sets as defined should either work, and the person doing them should get 
each and every one
working as expected, or none of them should, and it should be pushed back to 
the submitter to
fix their specification.

Levity in tester interpretation is likely to introduce side effects.



pgpm4inpuSDyM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Rich Freeman]

On Tue, Jan 3, 2017 at 6:28 PM, Kent Fredric  wrote:
>
> In that, by making the submitter resolve it all, its either "good" or "bad"
>
> Instead of leaving the person doing the testing in a confused state about 
> which packages
> are expected to be used.
>

Well, assuming that a human is actually the one figuring it out.

But, yes, I agree with your general point the way we do things today...

-- 
Rich

Re: [gentoo-dev] The changes about the stabilization process

[Andrew Savchenko]

Hi all,

On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
[...]
> Another question: do we steel need to set STABLEREQ keyword for
> stabilization bugs? Since we now have a dedicated Stabilization
> component, STABLEREQ looks redundant.

Ping here.

Best regards,
Andrew Savchenko


pgpU78phlmgfZ.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Global USE cuda

[Mart Raudsepp]

Ühel kenal päeval, T, 03.01.2017 kell 11:02, kirjutas Andrew Savchenko:
> Hi,
> 
> On Mon, 2 Jan 2017 21:37:43 + Justin  wrote:
> > 
> > Hi all
> > 
> > How about making USE=cuda a global USE?
> > 
> > Description: Enable support for nVidia CUDA
> 
> Sounds reasonable.

If this gets implemented, just please make sure to not wipe too much fo
the local descriptions. I see many of them specifying things in detail,
which is very useful to keep around as a description "override" and I
very much appreciate and encourage that.


> > 
> > Current Situation:
> > dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC)
> > dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
> > dev-util/VampirTrace: Enable tracing of CUDA calls and GPU
> > kernels.
> > sci-chemistry/ball: Include cuda support
> > sci-chemistry/nwchem: Enable CUDA GPU support for the Tensor
> > sci-libs/arrayfire: Build CUDA backend.
> > sci-libs/bigdft-abi: Enable support for nVidia CUDA
> > sci-libs/libgeodecomp: Enables plugins for NVIDIA GPUs (e.g.
> > sci-libs/trilinos: Add support for cuda (dev-util/nvidia-cuda-
> > toolkit)
> > sci-misc/kaldi: Build with CUDA support.
> > sci-physics/abinit: Enable support for nVidia CUDA
> > sci-physics/bigdft: Enable support for nVidia CUDA GPU
> > acceleration
> > sys-cluster/openmpi: Add GPU direct support
> > app-crypt/johntheripper: Use nvidia cuda toolkit for speeding
> > up
> > dev-libs/libdynd: Enable NVIDIA CUDA toolkit support
> > dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
> > dev-libs/starpu: Enable NVIDIA CUDA toolkit support
> > dev-util/nvidia-cuda-sdk: Build CUDA binaries.
> > media-gfx/blender: Build cycles renderer with nVidia CUDA
> > support.
> > media-gfx/k3d: Use nvidia cuda toolkit for speeding up
> > computations
> > media-gfx/nvidia-texture-tools: Enable NVIDIA CUDA toolkit
> > support
> > media-libs/opencv: Enable NVIDIA Cuda computations support
> > media-libs/opensubdiv: Enable NVIDIA CUDA Toolkit support
> > through
> > net-analyzer/suricata: Enable NVIDIA Cuda computations support
> > net-wireless/pyrit: Enable CUDA support via net-
> > wireless/cpyrit-cuda
> > sci-chemistry/ball: Include cuda support
> > sci-chemistry/gromacs: Enable cuda non-bonded kernels
> > sci-chemistry/vmd: Use nvidia cuda toolkit for speeding up
> > sci-libs/cholmod: Use nvidia cuda toolkit for speeding up
> > computations
> > sci-libs/flann: Enable support for nVidia CUDA
> > sci-libs/pcl: Adds support for NVIDIA CUDA.
> > sci-libs/suitesparse: Enable nvidia cuda toolkit for speeding
> > up
> > sci-misc/boinc: Use nvidia cuda toolkit for speeding up
> > computations.
> > sci-physics/espresso: Enable cuda support
> > sci-physics/hoomd-blue: Enable cuda non-bonded kernels
> > sys-apps/hwloc: Enable CUDA device discovery
> > sys-cluster/openmpi: Add GPU direct support
> > 
> > More or less consistent in enabling CUDA support.
> > 
> > Best,
> > Justin
> > 
> 
> 
> Best regards,
> Andrew Savchenko

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

[gentoo-dev] Re: The changes about the stabilization process

[Michael Palimaka]

On 04/01/17 12:57, Andrew Savchenko wrote:
> Hi all,
> 
> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
> [...]
>> Another question: do we steel need to set STABLEREQ keyword for
>> stabilization bugs? Since we now have a dedicated Stabilization
>> component, STABLEREQ looks redundant.
> 
> Ping here.
> 
> Best regards,
> Andrew Savchenko
> 

With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.

That said, it's entirely possible some arch team members are relying on
these keywords for old saved searches etc. With so many people working
in isolation, it's difficult to know who is doing what.

Re: [gentoo-dev] Re: The changes about the stabilization process

[M. J. Everitt]

On 04/01/17 07:09, Michael Palimaka wrote:
> On 04/01/17 12:57, Andrew Savchenko wrote:
>> Hi all,
>>
>> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
>> [...]
>>> Another question: do we steel need to set STABLEREQ keyword for
>>> stabilization bugs? Since we now have a dedicated Stabilization
>>> component, STABLEREQ looks redundant.
>> Ping here.
>>
>> Best regards,
>> Andrew Savchenko
>>
> With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.
>
> That said, it's entirely possible some arch team members are relying on
> these keywords for old saved searches etc. With so many people working
> in isolation, it's difficult to know who is doing what.
>
If in any doubt .. set *everything* Lol .. you maximise your chances
then !! :D



signature.asc
Description: OpenPGP digital signature