[gentoo-dev] rfc: stabilization policies

[gentoo-dev] rfc: stabilization policies

[William Hubbs]

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

All,

I'm not really sure what the answer to this problem is, so I want to
know what the group thinks about how we can handle it.

During the last release of OpenRC, I learned that people *do* run
production servers on ~arch. I asked about it and was told that the
reason for this is bitrot in the stable tree.

My question is, how can we improve our stabilization procedures/policies
so we can convince people not to run production servers on ~arch and
keep the stable tree more up to date?

Thanks,

William


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

Re: [gentoo-dev] rfc: stabilization policies

[Ian Stakenvicius]

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

On 20/08/13 02:19 PM, William Hubbs wrote:
> All,
> 
> I'm not really sure what the answer to this problem is, so I want
> to know what the group thinks about how we can handle it.
> 
> During the last release of OpenRC, I learned that people *do* run 
> production servers on ~arch. I asked about it and was told that
> the reason for this is bitrot in the stable tree.
> 
> My question is, how can we improve our stabilization
> procedures/policies so we can convince people not to run production
> servers on ~arch and keep the stable tree more up to date?
> 
> Thanks,
> 
> William
> 

I see a few issues with ~arch -> table migrations:

#1 - things just sit in ~arch.  The auto-stablereq script should help
with this one I think; we should give it some time to see if it works out.

#2 - the inter-related'ness of packages -- sending one package from
~arch to stable is often not sufficient, rather that package and a
whole set of (r)deps all need to go to stable at the same time, and
those packages are not necessarily managed by the same herd or team.
Because of this I can see why the solution to #1 ends up getting
blocked.  I don't have a solution for this one; we need to figure out
better ways of dev's working together to push packages to stable more
often; maybe more tracker bugs? dunno...

Of course, developer communication only improves things when there
aren't any bugs that block one package and therefore the entire set of
(r)deps.  It could be that this is the real root cause of ~arch holdbacks.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlITtT8ACgkQ2ugaI38ACPDFvQEAvMsB/0+l/upCsHF4Fo1wDcar
RWd8jh+qtRBY7vnL/0wA/0c0jNpUva5QY4VfLFlI0oO3Zyeui2yh6JaVzST6Gqar
=6AqJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Wyatt Epp]

On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> During the last release of OpenRC, I learned that people *do* run
> production servers on ~arch. I asked about it and was told that the
> reason for this is bitrot in the stable tree.
>
This right here seems strange to me.  What things in stable are
undergoing bitrot?  What manner of bitrot?  On what architectures?
Specifics or examples seem like they'll be important here because I
think this is largely a matter of perception.  Having to endure CantOS
at work, I have a hard time faulting the stable situation that I see
with my amd64 machine at home.

Regards,
Wyatt

Re: [gentoo-dev] rfc: stabilization policies

[Ian Stakenvicius]

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

On 20/08/13 02:29 PM, Wyatt Epp wrote:
> On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs
> <williamh@gentoo.org> wrote:
>> 
>> During the last release of OpenRC, I learned that people *do*
>> run production servers on ~arch. I asked about it and was told
>> that the reason for this is bitrot in the stable tree.
>> 
> This right here seems strange to me.  What things in stable are 
> undergoing bitrot?  What manner of bitrot?
> 

I think the use of the term 'bitrot' here is referring to stable
packages just being old/stale and don't have the new features/hardware
support/whatever that ~arch packages do.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlITtjkACgkQ2ugaI38ACPCyEQD/VLgm33i3cTO/1RUKY3C2k6pZ
SsAMz8Tapjvrr8q9xywBAJrj1VguEPcTnPpeipD8AOnrzpgbd23KWxJsd0D4ChyV
=ZkDX
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Dirkjan Ochtman]

On Tue, Aug 20, 2013 at 8:29 PM, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> This right here seems strange to me.  What things in stable are
> undergoing bitrot?  What manner of bitrot?  On what architectures?

Yeah, something slightly more specific would be useful here.

I run my servers with stable with just a few package.keywords lines
for things I trust/follow upstream, and it's generally fine. There
doesn't seem to be a whole lot of bitrot, and sometimes if there is I
just file stabilization requests and things get better.

Of course this also depends on your arch a lot; I only run amd64/x86
servers, so stabilization is pretty good there.

Cheers,

Dirkjan

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 13:19:10 -0500
William Hubbs <williamh@gentoo.org> wrote:

> All,
> 
> I'm not really sure what the answer to this problem is, so I want to
> know what the group thinks about how we can handle it.
> 
> During the last release of OpenRC, I learned that people *do* run
> production servers on ~arch.

While I don't, and asked it just because of the large amount; it
appears from some things lately, and not just OpenRC, that there is a
certain group that regards ~arch as some kind of new stable.

This isn't solely about versions entering ~arch, but also about
versions leaving ~arch; as ~ is for testing, people should expect their
version to break and they should also expect that they cannot rely on a
version remaining in the Portage tree, that's just wrong...

As a result, there are complaints regarding ~; while really, we should
have more complaints regarding stable instead. From the forums I see
more and more people switching to ACCEPT_KEYWORDS="arch ~arch"; so, we
are getting close to a point where stable becomes less important.

This is really not the direction we should be heading...

> I asked about it and was told that the
> reason for this is bitrot in the stable tree.

Let me dig up an example...

Our last sys-kernel/gentoo-sources stabilization was 3 months ago:

  15 May 2013; Agostino Sarubbo <ago@gentoo.org>
  gentoo-sources-3.8.13.ebuild: Stable for amd64, wrt bug #469508

This is in my opinion bitrot; and it emphasizes where the problem lies,
the arch teams simply don't have enough resources to keep up with the
stabilization that we would like to see, more than once a month. We
should crowd source testing in one way or the other; that way, we get
feedback from a larger share of users, instead of overloading 'ago'...

3.9.11-r1 was blocked (https://bugs.gentoo.org/show_bug.cgi?id=477976)
for something that shouldn't even be problematic and 3.10.7 is filed
(https://bugs.gentoo.org/show_bug.cgi?id=481522) which I am waiting
for but it seems to take some time; so, I hope we get a stabilized
kernel this time, because otherwise we might as well drop keywords...

Besides the latest stable branch, it would be nice to have stable LTS;
that is Long Term Stable, thus the older 3.0, 3.2 and 3.4 branches.

> My question is, how can we improve our stabilization
> procedures/policies so we can convince people not to run production
> servers on ~arch and keep the stable tree more up to date?

As I hinted at above; I think we really need to make it less strict and
crowd source the efforts to the users, as the strictness as well as the
limited resources slow things down a lot.

This also makes perfect sense; we are providing ~ as a means for the
users to test, but how do the users report back "success" (or failures)?

Even for failures, I often discover that a lot of users do not file
bugs; or they do file bugs, but in the wrong place (forums, FB, G+,
chat, ...) and we don't discover them in time. Those that I catch I
refer them to https://bugs.gentoo.org; but well, I can't catch them all.

It is due to the lack of such feedback that we have a too huge need
from the arch teams; if we can get more feedback, we would not have to
rely so much to the arch teams and assign them to what really needs
proper testing. For example: @system packages, popular packages, ...

Some attention on where we spend our resources as well as how much
delay there is for some packages need to be considered; otherwise we're
just wasting time on stabilizing very small and unimportant packages.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Aug 2013 14:28:15 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> I see a few issues with ~arch -> table migrations:

> #1 - things just sit in ~arch.  The auto-stablereq script should help
> with this one I think; we should give it some time to see if it works
> out.

That script has been running for long enough now. It doesn't work out...

> #2 - the inter-related'ness of packages

You can file STABLEREQ bugs for other packages, just not CC arches; if
you state you need it stable for some other package, I think the
maintainer isn't going to make a problem out of it. Unless there is one
or another problematic bug blocking it; in which case, collaboration
between the devs to get both packages stabilized indeed seems like a
nice idea. I think this already happens naturally...

Here's another point:

#3 - There is a lack of manpower and resources on the arch teams.

Recruiting more people to the arch teams is one possibility, but will
we manage to get enough people; that's hard to tell, if we don't
manage to, I responded on the main thread with a crowd sourcing idea.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQEcBAEBAgAGBQJSE8P1AAoJEJWyH81tNOV9fPsIAJoITcPXkAITg+qYiudf2jeN
9IcGbKs6F7B5VZiHlizyC5G+J6aLuHcdlYdRgkPteNbh0me/iujfsCeIpawBcY9r
UgviVkCQ39WzO7zxA9neXXHednuCQOXpfuUSHDcqtQnj3zHpMSVgdO+JWU1/CTwB
gDpxYHTbaNvHsQQX+u2cOpGkvpNAwTu/bJF6G1FEzEsdfz9KPUBaabgfwT9OacKH
FMZ4lcV/8+/olr6d8y+2+xIw5OOyYB7WS5LYpdqBX6UpikzqxTshx1PZPc1jQTIg
ZrqrovYmBndX3i4o3XtDfYeEcCVzufP71wHoOzCbOUdUX1kU0QBViswjQaIV87Q=
=E16V
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Aug 2013 14:28:15 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> #1 - things just sit in ~arch.  The auto-stablereq script should help
> with this one I think; we should give it some time to see if it works
> out.

As an alternative, how about a new keyword? Let maintainers put
stablereq directly in KEYWORDS, and let arch teams pick it out from
there.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlITxXAACgkQ96zL6DUtXhFJDQCggDsTHXBo5UDFCHOCeloCfXc8
1dUAn1DVVm7MITSa13UChGRbNrkmJDkY
=Yqlh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Rich Freeman]

On Tue, Aug 20, 2013 at 3:24 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> While I don't, and asked it just because of the large amount; it
> appears from some things lately, and not just OpenRC, that there is a
> certain group that regards ~arch as some kind of new stable.

People have been talking about that for years.  I think that years ago
there were some issues with stable breaking when ~arch did not, but
those are largely behind us.  Then there were situations like it
taking FOREVER to get openrc into stable.

I just don't see any drivers to stay away from stable now.  ~arch is
also a lot more stable than it used to be, so more are likely to run
it.  However, I don't think that is a reason that we should be timid
about breaking things there (within reason).

>
> Let me dig up an example...
>
> Our last sys-kernel/gentoo-sources stabilization was 3 months ago:

I don't really see a problem with stable package being all of 3 months
old.  Contrast that with youtube-dl which pull from ~arch and rebuild
about 3x/week.

If somebody needs a newer kernel they can run it.  I needed something
so I accepted <3.10, and it looks like I'll either have to accept
<3.11 now or just live with 3.9 until stable catches up.  I don't
really see a problem with either unless I'm looking to fix some
particular bug.

Rich

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 14:29:09 -0400
Wyatt Epp <wyatt.epp@gmail.com> wrote:

> On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs <williamh@gentoo.org>
> wrote:
> What things in stable are undergoing bitrot?

Things that are too old; see 'imlate' from app-portage/gentoolkit-dev,
this can be handy to indicate stabilization candidates. You can try to
filter it for things that haven't been stabilized for more than a
month; alternatively, it's a fun data manipulation task to try to stat
and/or grep it from the Portage tree in one or another way...

> What manner of bitrot?

They might ...

1. ... contain stability bugs which may need fixing.
2. ... contain security bugs that later versions have fixed. 
3. ... make it unable to file a bug upstream because it is old.
4. ... block libraries that should otherwise be punted.
5. ... no longer work nowadays; because some internet API changed,
       because people run a new kernel version and because ...
6. ... and so on...

In other words, it's bad QA if you keep them around for way too long.

> On what architectures?

There is the impression that happens on all architectures; while
indeed, there are some minor architectures where this is a bigger
problem, some might just benefit having no stabilization.

Statistics would be nice here, because an indication is missing...

> Specifics or examples seem like they'll be important here because I
> think this is largely a matter of perception.

+1

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 20:45:05 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Tue, Aug 20, 2013 at 8:29 PM, Wyatt Epp <wyatt.epp@gmail.com>
> wrote:
> > This right here seems strange to me.  What things in stable are
> > undergoing bitrot?  What manner of bitrot?  On what architectures?
> 
> Yeah, something slightly more specific would be useful here.
> 
> I run my servers with stable with just a few package.keywords lines
> for things I trust/follow upstream, and it's generally fine. There
> doesn't seem to be a whole lot of bitrot, and sometimes if there is I
> just file stabilization requests and things get better.
> 
> Of course this also depends on your arch a lot; I only run amd64/x86
> servers, so stabilization is pretty good there.

Well, I think the impression one gets about stable when that person
runs stable is different than the impression when that person runs ~;
so, I wouldn't consider switching to stable, if you know what I mean...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Aug 2013 20:37:17 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 20 Aug 2013 14:28:15 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> > #1 - things just sit in ~arch.  The auto-stablereq script should
> > help with this one I think; we should give it some time to see if
> > it works out.
> 
> As an alternative, how about a new keyword? Let maintainers put
> stablereq directly in KEYWORDS, and let arch teams pick it out from
> there.

Yes, +1; last time this came up on chat, I asked whether it would be a
nice idea to have something between stable and ~, what you propose
sounds similar and might make sense. Though, on the other hand, doing
it this way we don't get the advantages that filing bugs give; if we
do it this way, I'd assume we need some other implementation to
cover that (for things like the "depends on", "blocks", ... fields)...

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQEcBAEBAgAGBQJSE8gHAAoJEJWyH81tNOV91FsH/iBTPA2uUJZB7Dcjqypl5MfQ
rfb10KPYY6LBbMeyT8W0drX3tfUILWVw++aRBLa+pWDfZFpbR59PL16Nxvn2/JW/
p4zoaKeHuqFlG9cQePHpVDfAViDCGkN379r+BFKo+bUuQ7zc7/ItEKOGO/pbtuKQ
xqw47m/T4Ag8qXJQ5yZ3HmokDDKEpCaiVaXlzWYYckEpH5NeHBrrJms2/jTdfPH8
qgNx3fjrEvusw8T7NO17t8qG+6iJM42KMGk835zGf7g0i1rfHYkvxjbmLQh70BK/
JWXdiKsm5/3Ko9EKE+7SNC4eeaRqR4RxjXbkITzcwzZGebIXGsiaVfTEWE5VAqM=
=KNKd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Alan McKinnon]

On 20/08/2013 21:24, Tom Wijsman wrote:
> On Tue, 20 Aug 2013 13:19:10 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> All,
>>
>> I'm not really sure what the answer to this problem is, so I want to
>> know what the group thinks about how we can handle it.
>>
>> During the last release of OpenRC, I learned that people *do* run
>> production servers on ~arch.
> 
> While I don't, and asked it just because of the large amount; it
> appears from some things lately, and not just OpenRC, that there is a
> certain group that regards ~arch as some kind of new stable.
> 
> This isn't solely about versions entering ~arch, but also about
> versions leaving ~arch; as ~ is for testing, people should expect their
> version to break and they should also expect that they cannot rely on a
> version remaining in the Portage tree, that's just wrong...


As a long time user and citizen of -user I can tell you what the general
feeling of arch vs ~arch there is:

~arch is plenty good enough for everything except very mission critical
stuff
arch has plenty old stuff in it

~arch does not break every other day, and breakage is actually
surprisingly rare. And, it's usually confined to
openrc/udev/systemd/baselayout and other critical packages where one
just knows upfront anyway that danger may lurk ahead.

Some folks like me sync daily and accept that I deal with occasional
breakage maybe once a month. Usually I just mask an offending package
and move on. Others wait a few days and if no reported bugs, then emerge it.

I get the sense that hard masked and -9999 is the new testing, ~arch is
new stuff and arch is for fuddy duddys that can't abide breakage of any
kind (very much like debian stable actually). I also get the sense that
arch progresses too slowly for many people. How long did we wait for
MySQL-5.5 to reach arch? Folk wanted that one in stable reasonably early
and mixing arch/~arch is very very bad in real life. Hence the
recommendation to switch to ~arch, and it usually works out just fine.

Hey, maybe you guys are doing your job in ~arch *too well*, to your own
detriment :-)  Something to consider?


[snip]

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 15:41:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> > Let me dig up an example...
> >
> > Our last sys-kernel/gentoo-sources stabilization was 3 months ago:
> 
> I don't really see a problem with stable package being all of 3 months
> old.  Contrast that with youtube-dl which pull from ~arch and rebuild
> about 3x/week.

For something that releases once to twice a week, it is a problem;
we're not talking about a package that gets some slow commits here, no,
let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233

That's a lot of commits; now you need to realize that every single
commit in this means something, a lot of them are bug fixes (stability,
security, reliability, anti corruption, ...) whereas of course a part of
it also introduces parts of new features and refactoring.

Desktop users might not care for all of these, but sysadmins will;
actually, that's what this thread is about, they are switching to ~
because of things like this. Who are we stabilizing for then?!

> If somebody needs a newer kernel they can run it.

Upstream has advised people that people must upgrade 3 months ago...

> I needed something so I accepted <3.10, and it looks like I'll either
> have to accept <3.11 now or just live with 3.9 until stable catches
> up.  I don't really see a problem with either unless I'm looking to
> fix some particular bug.

This last paragraph has nothing to do with stabilization; we shouldn't
expect users to define stable themselves, also note that not all bugs
are visible. So, we can't just be careless and wait another month...

While this is a large scale example, the same happens in smaller scale
to other packages; I don't mean to focus on the kernel, but rather use
it as an example to show the underlying problem:

    Bitrot due to a lack of resources.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Michael Orlitzky]

On 08/20/2013 02:19 PM, William Hubbs wrote:
> My question is, how can we improve our stabilization procedures/policies
> so we can convince people not to run production servers on ~arch and
> keep the stable tree more up to date?

Just delete /etc/conf.d/net with an ~arch update every once in a while,
that should convince them =)

Stable is fine for the most part. The bitrot complaint is basically "I
can't be bothered to add packages to
/etc/portage/package.accept_keywords individually."

Most of our servers have one or two packages in there, for which I've
already filed a stabilization bug. Web servers are the worst, because
we have to listen to our customers occasionally. Here is our largest
package.accept_keywords (comments added):

> =dev-php/pecl-zendopcache-7.0.2 ~amd64

PHP 5.5 is coming to stable soon, so we wanted to test this early. It
belongs in ~arch, though. Nothing to see here.

> # Should get this stabled.
> =dev-php/smarty-3.1.12 ~amd64

Just filed https://bugs.gentoo.org/show_bug.cgi?id=481780

> =sys-boot/grub-2.00-r2 ~amd64

We upgraded grub at the same time as the udev mess. The upgrade failed
on several systems (which needed to be repartitioned, ugh), but the
upgrade is opt-in since grub-legacy keeps working.

> # Our overlay
> */*::viabit-overlay ~amd64

Nothing to see here. Our company overlay.

> net-mail/postfix-logwatch ~amd64

This is stuck in Sunrise. https://bugs.gentoo.org/show_bug.cgi?id=309075

> # https://bugs.gentoo.org/show_bug.cgi?id=448558
> # https://bugs.gentoo.org/show_bug.cgi?id=475962 
> =dev-php/PEAR-Mail_Mime-1.8.8 ~amd64

This isn't even in the tree, so it doesn't count. But it does fix an
annoyance, so if anyone is listening, please bump it!

> # Redmine
> =dev-ruby/builder-3.1.4 ~amd64
> =dev-ruby/rails-3.2.13 ~amd64
> =dev-ruby/railties-3.2.13 ~amd64
> =dev-ruby/actionmailer-3.2.13 ~amd64
> =dev-ruby/builder-3.0.4 ~amd64
> =dev-ruby/arel-3.0.2-r1 ~amd64
> =dev-ruby/rack-cache-1.2 ~amd64
> =dev-ruby/rack-openid-1.3.1 ~amd64
> =dev-ruby/thor-0.15.2 ~amd64
> =dev-ruby/activemodel-3.2.13 ~amd64
> =dev-ruby/sprockets-2.2.2 ~amd64
> =dev-ruby/sass-rails-3.2.6 ~amd64
> =dev-ruby/coffee-script-source-1.6.2 ~amd64
> =dev-ruby/activerecord-3.2.13 ~amd64
> =dev-ruby/rack-ssl-1.3.2 ~amd64
> =dev-ruby/mail-2.5.3 ~amd64
> =dev-ruby/activeresource-3.2.13 ~amd64
> =net-libs/nodejs-0.10.15 ~amd64
> =dev-ruby/journey-1.0.4 ~amd64
> =dev-ruby/hike-1.2.3 ~amd64
> =dev-ruby/i18n-0.6.4 ~amd64
> =dev-ruby/coffee-rails-3.2.2 ~amd64
> =dev-ruby/treetop-1.4.10-r1 ~amd64
> =dev-ruby/activesupport-3.2.13 ~amd64
> =dev-ruby/coffee-script-2.2.0 ~amd64
> =dev-ruby/polyglot-0.3.3 ~amd64
> =dev-ruby/jquery-rails-2.3.0 ~amd64
> =dev-ruby/actionpack-3.2.13 ~amd64
> =dev-ruby/execjs-1.4.0 ~amd64
> =dev-ruby/uglifier-1.3.0 ~amd64
> =dev-ruby/rack-test-0.6.2 ~amd64
> =dev-ruby/bcrypt-ruby-3.0.1 ~amd64
> =dev-ruby/mysql2-0.3.11 ~amd64
> =dev-ruby/ruby-net-ldap-0.3.1 ~amd64

Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
3.0 was released almost exactly three years ago. Every time rails-3.x
gets bumped, I have to manually update the entire list above. I need
to do it on an x86 server as well, so I get to do it twice; I can't
even copy/paste the list.

It sucks, but it's still better than running ~arch. Problems like this
should be fixed, but if you decide it's easier to
ACCEPT_KEYWORDS="~arch" than deal with the exceptions, you're asking for
trouble.

Re: [gentoo-dev] rfc: stabilization policies

[hasufell]

On 08/20/2013 08:19 PM, William Hubbs wrote:
> 
> My question is, how can we improve our stabilization procedures/policies
> so we can convince people not to run production servers on ~arch and
> keep the stable tree more up to date?
> 

Why convince them? They have been warned and it's their own problem.

I don't see any BIG problem in our current stabilization procedure.
Scripts for auto-filing stablereqs seem wrong to me. It's not just about
"it was 30 days in the tree without a bug". The maintainer has to know
about upstream bug reports and other crap that might be going on.

Such things to speed up the procedure will only make it worse.

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 22:00:52 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> As a long time user and citizen of -user I can tell you what the
> general feeling of arch vs ~arch there is:

Thanks for jumping into the discussion.

> arch has plenty old stuff in it

Yes, it keeps me from using it; I would have to unmask too much...

> ~arch is plenty good enough for everything except very mission
> critical stuff
>
> ~arch does not break every other day, and breakage is actually
> surprisingly rare. And, it's usually confined to
> openrc/udev/systemd/baselayout and other critical packages where one
> just knows upfront anyway that danger may lurk ahead.
>
> Some folks like me sync daily and accept that I deal with occasional
> breakage maybe once a month. Usually I just mask an offending package
> and move on. Others wait a few days and if no reported bugs, then
> emerge it.

This really sounds like what would be the description of stable; I
mean, for mission critical stuff someone would plan out a migration and
"test" the upgrade prior to applying it to the server. For the rest,
except for maybe that critical packages shouldn't break; an issue once
a month is something that slips through, eg. see the stable bugs...
 
> I get the sense that hard masked and -9999 is the new testing,

Actually, hard masked is usually something that is really broken; while
there are some things masked for some other reasons, you can't really
regard it as testing. But yeah, as for -9999, it could be considered
testing; although it is often broken, because of broken patches, ...

> I also get the sense that arch progresses too slowly for many people.

+1 that's one of the points that came up on IRC; 30 days and more
being too long, because not everyone follows up with that time
schedule (we are people, not cronjobs), it even gets a bit longer...

> How long did we wait for MySQL-5.5 to reach arch? Folk wanted that
> one in stable reasonably early and mixing arch/~arch is very very bad
> in real life. Hence the recommendation to switch to ~arch, and it
> usually works out just fine.

Yes, but we don't want to end up having everyone having mixed trees or
be on ~arch; if we do, stabilization is going to become a wasted effort.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Andreas K. Huettel]

Am Dienstag, 20. August 2013, 20:19:10 schrieb William Hubbs:
> 
> I'm not really sure what the answer to this problem is, so I want to
> know what the group thinks about how we can handle it.
> 
> During the last release of OpenRC, I learned that people *do* run
> production servers on ~arch. I asked about it and was told that the
> reason for this is bitrot in the stable tree.
> 

Oh come on. 

"I'm not sure what the problem is" would probably be a better reply. 

Stable implies "not so often changing". If you really need newer packages on a 
system that has to be rock-solid, then keyword what you need and nothing else. 

There are many ways of doing that...
* --autounmask-write (imagine a time before that!)
* echo 'kde-base/*' >> /etc/portage/package.keywords
* ...

My impression is that the stable bitrot has become a lot better. Even Gnome is 
updating now... :D

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 22:16:34 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 08/20/2013 08:19 PM, William Hubbs wrote:
> > 
> > My question is, how can we improve our stabilization
> > procedures/policies so we can convince people not to run production
> > servers on ~arch and keep the stable tree more up to date?
> > 
> 
> Why convince them? They have been warned and it's their own problem.
> 
> I don't see any BIG problem in our current stabilization procedure.
> Scripts for auto-filing stablereqs seem wrong to me. It's not just
> about "it was 30 days in the tree without a bug". The maintainer has
> to know about upstream bug reports and other crap that might be going
> on.
> 
> Such things to speed up the procedure will only make it worse.

+1 at most it helps as a reminder to me; but indeed, a lot of these
reminders are false positive. What we really should do instead is look
for the worst offenders; in other words, which packages haven't been
stabilized for ages, which have a stable version of half a year ago?

See `imlate --mtime=180 -s | less`. (From app-portage/gentoolkit-dev)

I quote:

> ==============================================
> 4392 Stable candidates for 'gentoo' on 'amd64'
> ==============================================

Let's double the number to a year ago (360 instead of 180), I quote:

> ==============================================
> 2728 Stable candidates for 'gentoo' on 'amd64'
> ==============================================

And also get an impression of 3 months (90 instead of 180), I quote:

> ==============================================
> 6065 Stable candidates for 'gentoo' on 'amd64'
> ==============================================

At least the numbers for the year sound like something we will want to
deal with; from there, we could try to keep half a year low. And after
a while, we might end up ensuring stabilization within 3 months.

That's still three times more than our intended stabilization delay...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Walter Dnes]

On Tue, Aug 20, 2013 at 04:12:45PM -0400, Michael Orlitzky wrote
> On 08/20/2013 02:19 PM, William Hubbs wrote:
> > My question is, how can we improve our stabilization
> > procedures/policies so we can convince people not to run production
> > servers on ~arch and keep the stable tree more up to date?
> 
> Just delete /etc/conf.d/net with an ~arch update every once in a while,
> that should convince them =)
> 
> Stable is fine for the most part. The bitrot complaint is basically "I
> can't be bothered to add packages to
> /etc/portage/package.accept_keywords individually."

  What he said.

> Most of our servers have one or two packages in there, for which I've
> already filed a stabilization bug.

  From a regular user POV, I occasionally have one or 2 packages that I
keyword, because I want their specific feature; e.g. a ~ version of UFRAW
that will read the RAW format from my new camera, which stable won't.

  I can see giving up on vanilla-sources kernels.  See
http://gentoo.2317880.n4.nabble.com/newsitem-Kernel-Team-vanilla-sources-policy-td266519.html
Executive summary... the releases are so fast+furious, that keeping up
with stabilization is not possible, so it'll always be ~.

> It sucks, but it's still better than running ~arch. Problems like this
> should be fixed, but if you decide it's easier to
> ACCEPT_KEYWORDS="~arch" than deal with the exceptions, you're asking for
> trouble.

  Wise words.  That level of laziness *ON A PRODUCTION SERVER* is
unacceptable.

  Are there any other packages that get updated as often as vanilla
sources?  Maybe they should be considered for a similar policy.

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

Re: [gentoo-dev] rfc: stabilization policies

[Wyatt Epp]

On Tue, Aug 20, 2013 at 5:05 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> At least the numbers for the year sound like something we will want to
> deal with; from there, we could try to keep half a year low. And after
> a while, we might end up ensuring stabilization within 3 months.
>
> That's still three times more than our intended stabilization delay...
>
I think it'd be more interesting to know how many of these stable
requests DON'T have blockers or other issues attached that prevent(ed)
them from getting stabled.

Also, at the older ages, how many of them are obsoleted by a newer
version in the tree and should be closed (or even how many have been
treecleaned)?

-Wyatt

Re: [gentoo-dev] rfc: stabilization policies

[Rich Freeman]

On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> Stable implies "not so often changing". If you really need newer packages on a
> system that has to be rock-solid, then keyword what you need and nothing else.

++

30 days is too long?  How can something new be stable?  Stable doesn't
mean "I don't think this is broken."  Stable means "lots of others
have already been using this and so far there aren't many reports of
breakage."

According to distrowatch RHEL is at 2.6.32.  I'm sure it has a
bazillion backports, but that is what I'd call stable.  Running stable
means starting to use the stuff everybody else is about ready to stop
using.  When an upstream releases a new stable release, that means
that it is just now ready for testing, and chances are they'll have
another stable release before their previous release really is stable.

If you need the release two days after it comes out, you're not really
looking for a stable release.

At work we typically buy stuff about a year after it comes out, and by
the time we're done doing integration and testing it is probably two
years old and we've gotten 27 patches in the meantime.  That's stable.

Gentoo is one of the few distros that really lets you mix and match,
so run stable on the stuff you don't care about, and if the purpose of
the box is to serve apps on Rails then by all means use ~arch on Ruby.
 You can do that and not worry about whether it is going to be broken
by the latest glibc or coreutils or whatever.

Rich

Re: [gentoo-dev] rfc: stabilization policies

[Doug Goldstein]

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

On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> >
> > Stable implies "not so often changing". If you really need newer
> packages on a
> > system that has to be rock-solid, then keyword what you need and nothing
> else.
>
> ++
>
> 30 days is too long?  How can something new be stable?  Stable doesn't
> mean "I don't think this is broken."  Stable means "lots of others
> have already been using this and so far there aren't many reports of
> breakage."
>

Stable also means this is less broken than current stable. In the past I've
gotten push back from arch teams on all sorts of items I consider to be
unrelated to the stabilization request. Yes it'd be great if the world was
black and white and 30 days was a magical cut off but many times its not.
If current stable is causing a crash or some bad user case, I'll ask for a
quick stabilization of a revbump that contains a small scope patch that a
user can confirm it fixes the issue.


>
> According to distrowatch RHEL is at 2.6.32.  I'm sure it has a
> bazillion backports, but that is what I'd call stable.  Running stable
> means starting to use the stuff everybody else is about ready to stop
> using.  When an upstream releases a new stable release, that means
> that it is just now ready for testing, and chances are they'll have
> another stable release before their previous release really is stable.
>

Apples and oranges. Its 2.6.32 for the kabi, which they maintain and
support. They have plenty of things that landed in 3.7 in RHEL 6.4. They
have a solid QA procedure to vet their kernels and they're not afraid to
turn the crank on small targeted fixes and pushing those out to resolve
issues as the release matures.


>
> If you need the release two days after it comes out, you're not really
> looking for a stable release.
>
> At work we typically buy stuff about a year after it comes out, and by
> the time we're done doing integration and testing it is probably two
> years old and we've gotten 27 patches in the meantime.  That's stable.
>

Correlation is not causation. Just because software or hardware sat of the
shelf for a year doesn't mean its any more or less stable when it was
originally shipped. If a vendor has a high level of QA with multi-layed
test processes that product will probably more stable out the door than a
vendor with no QA that kicked the product out the door and let their early
adopters find the bugs over the past year. I say probably because again the
world isn't black and white. Your use case with both products could be
exposing a corner case that no user before you and no QA engineer before
you had tried and both products will go boom.


>
> Gentoo is one of the few distros that really lets you mix and match,
> so run stable on the stuff you don't care about, and if the purpose of
> the box is to serve apps on Rails then by all means use ~arch on Ruby.
>  You can do that and not worry about whether it is going to be broken
> by the latest glibc or coreutils or whatever.
>
> Rich
>
>
Its also precisely that mix and match that might cause instability due to
people not testing things. Case in point QEMU 1.6.0 just came out and it
went through a number of release candidates but no one ever saw that it
depends only on Python 2.4 but actually needs Python 2.6. That's kind of
like Gentoo, a package says it depends on libfoo 1.0 or higher and the dev
that tested stable baz 0.8 confirmed it worked with libfoo 1.0, but baz 0.9
in ~arch still depends on libfoo 1.0 but really needs libfoo 1.1 and libfoo
1.1 is ~arch as well. So the developer running ~arch believed that baz 0.9
works fine since he has ~arch libfoo.

My point is what Gentoo calls "stable" is just something that usually 2 or
more people have compiled and installed vs ~arch which 1 or more people
have compiled and installed.

-- 
Doug Goldstein

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

Re: [gentoo-dev] rfc: stabilization policies

["Paweł Hajdan, Jr."]

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

On 8/20/13 11:19 AM, William Hubbs wrote:
> During the last release of OpenRC, I learned that people *do* run
> production servers on ~arch. I asked about it and was told that the
> reason for this is bitrot in the stable tree.

People frequently point to lack of manpower as reason for this, but I
don't think it's true.

First, the rate arch teams (at least mainstream, amd64/x86) deal with
stabilization queues has improved. I'm not aware of any severe backlogs
in terms of stabilization bugs filed but not handled (on amd64/x86).

Second: people maintain list of packages to unmask, or maintain ~arch
servers... I hope they have some kind of testing/staging environment
before unleashing ~arch on production servers. Well, this is exactly
what stable can be - this effort could easily be shared with the rest of
the community by these people stabilizing things. I'm in favor of policy
changes if needed to make this happen.

Furthermore, it'd be great to have people who actually run servers help
with stabilizations. Arch teams could be doing their best, but they
probably don't run postgres/apache/ruby/whatever in production, and so
it's pretty much if it compiles and reverse dependencies don't explode
it's perfect. People running servers in production can actually test
these pretty thoroughly in staging environment and either vet them with
higher confidence or file good blocking bugs.

Paweł



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

Re: [gentoo-dev] rfc: stabilization policies

[Ben de Groot]

On 21 August 2013 04:12, Michael Orlitzky <michael@orlitzky.com> wrote:
> [snip]
> Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
> 3.0 was released almost exactly three years ago. Every time rails-3.x
> gets bumped, I have to manually update the entire list above. I need
> to do it on an x86 server as well, so I get to do it twice; I can't
> even copy/paste the list.

Yes you can. Just leave out the actual keyword. It will assume ~arch.

-- 
Cheers,

Ben | yngwin
Gentoo developer

[gentoo-dev] Re: rfc: stabilization policies

[Jonathan Callen]

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

On 08/20/2013 04:12 PM, Michael Orlitzky wrote:
>> # Redmine =dev-ruby/builder-3.1.4 ~amd64 =dev-ruby/rails-3.2.13 ~amd64 
>> =dev-ruby/railties-3.2.13 ~amd64 =dev-ruby/actionmailer-3.2.13 ~amd64 =dev-ruby/builder-3.0.4
>> ~amd64 =dev-ruby/arel-3.0.2-r1 ~amd64 =dev-ruby/rack-cache-1.2 ~amd64 
>> =dev-ruby/rack-openid-1.3.1 ~amd64 =dev-ruby/thor-0.15.2 ~amd64 =dev-ruby/activemodel-3.2.13
>> ~amd64 =dev-ruby/sprockets-2.2.2 ~amd64 =dev-ruby/sass-rails-3.2.6 ~amd64 
>> =dev-ruby/coffee-script-source-1.6.2 ~amd64 =dev-ruby/activerecord-3.2.13 ~amd64 
>> =dev-ruby/rack-ssl-1.3.2 ~amd64 =dev-ruby/mail-2.5.3 ~amd64 =dev-ruby/activeresource-3.2.13
>> ~amd64 =net-libs/nodejs-0.10.15 ~amd64 =dev-ruby/journey-1.0.4 ~amd64 =dev-ruby/hike-1.2.3
>> ~amd64 =dev-ruby/i18n-0.6.4 ~amd64 =dev-ruby/coffee-rails-3.2.2 ~amd64 
>> =dev-ruby/treetop-1.4.10-r1 ~amd64 =dev-ruby/activesupport-3.2.13 ~amd64 
>> =dev-ruby/coffee-script-2.2.0 ~amd64 =dev-ruby/polyglot-0.3.3 ~amd64 
>> =dev-ruby/jquery-rails-2.3.0 ~amd64 =dev-ruby/actionpack-3.2.13 ~amd64 =dev-ruby/execjs-1.4.0
>> ~amd64 =dev-ruby/uglifier-1.3.0 ~amd64 =dev-ruby/rack-test-0.6.2 ~amd64 
>> =dev-ruby/bcrypt-ruby-3.0.1 ~amd64 =dev-ruby/mysql2-0.3.11 ~amd64 
>> =dev-ruby/ruby-net-ldap-0.3.1 ~amd64
> 
> Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and 3.0 was released almost
> exactly three years ago. Every time rails-3.x gets bumped, I have to manually update the entire
> list above. I need to do it on an x86 server as well, so I get to do it twice; I can't even
> copy/paste the list.
> 
> It sucks, but it's still better than running ~arch. Problems like this should be fixed, but if
> you decide it's easier to ACCEPT_KEYWORDS="~arch" than deal with the exceptions, you're asking
> for trouble.
> 

If you want a list that you can copy and paste between x86/amd64 systems, just drop the keywords
completely from the line, so only the atom remains.  This will cause portage to use the ~arch
keyword *for the current host*, so the same file works on all architectures.

- -- 
Jonathan Callen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJSFEdaAAoJELHSF2kinlg4cTsQAJeeN3LV9O4zZUwCGF8ttb7F
X8oi+y6rL7hCvnsVqincnTA81pmlphHDViZ+kkIROFEzvrvpWbXrXHK0t9HvmaT1
q1rvmlZzpfXV4nHQRsUxZzUFGiFv8iKhpS5NhRtQyf13PFxPwq3pybnSnpMJcJ5m
O6Co/+NkxF5ynYOeyLLHlpAHzwnJILTcz1H0SK5wFNUt34aROJRPRtJJfAjWJlDv
oP4lsv2VvnoBc4MWEylV/HjuWQ41yRGxulRZMEtNspTT60QB3VCP1BctDF8FZU3G
u48zAM2bkVnppzggtsBycdVSVTsn7gB/zfpd3ESnL9MfJkg9pw8mpzkvZMw691Lq
7jK7I1mYAbRfAaCad3qA7fxRWe/8taTuHQvzku9nKe6qJY/OGZScDunjh4ezukEb
YWFMr8E/i8EnruxeuEghpwL22nIEXqScWJuP457IvQ2oNz6Pj6qzoJ4l1RD81uHl
vE99kt04KbsXBdt0o6DCCRpxbPgi2G+qh4K/4hDp4tHubOcZ/1AYqQay1Eqjkfhi
ozZGSOAnQ4ujI1KXuaKhM6QR3BdgPOb3iYNr7Wb6wGBRDKOvgPgPeieY5gEh/mvj
lOSC5c1dY29TdLco+N7Dyx/xBCErxTON+2av2Cdav+kvZw5c0u7zKJXCVBQATfD1
ZQ4V/ueUr9PdUqwcfgaU
=VwWr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Alan McKinnon]

On 20/08/2013 22:25, Tom Wijsman wrote:
> On Tue, 20 Aug 2013 22:00:52 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> As a long time user and citizen of -user I can tell you what the
>> general feeling of arch vs ~arch there is:
> 
> Thanks for jumping into the discussion.
> 
>> arch has plenty old stuff in it
> 
> Yes, it keeps me from using it; I would have to unmask too much...
> 
>> ~arch is plenty good enough for everything except very mission
>> critical stuff
>>
>> ~arch does not break every other day, and breakage is actually
>> surprisingly rare. And, it's usually confined to
>> openrc/udev/systemd/baselayout and other critical packages where one
>> just knows upfront anyway that danger may lurk ahead.
>>
>> Some folks like me sync daily and accept that I deal with occasional
>> breakage maybe once a month. Usually I just mask an offending package
>> and move on. Others wait a few days and if no reported bugs, then
>> emerge it.
> 
> This really sounds like what would be the description of stable; I
> mean, for mission critical stuff someone would plan out a migration and
> "test" the upgrade prior to applying it to the server. For the rest,
> except for maybe that critical packages shouldn't break; an issue once
> a month is something that slips through, eg. see the stable bugs...
>  
>> I get the sense that hard masked and -9999 is the new testing,
> 
> Actually, hard masked is usually something that is really broken; while
> there are some things masked for some other reasons, you can't really
> regard it as testing. But yeah, as for -9999, it could be considered
> testing; although it is often broken, because of broken patches, ...
> 
>> I also get the sense that arch progresses too slowly for many people.
> 
> +1 that's one of the points that came up on IRC; 30 days and more
> being too long, because not everyone follows up with that time
> schedule (we are people, not cronjobs), it even gets a bit longer...
> 
>> How long did we wait for MySQL-5.5 to reach arch? Folk wanted that
>> one in stable reasonably early and mixing arch/~arch is very very bad
>> in real life. Hence the recommendation to switch to ~arch, and it
>> usually works out just fine.
> 
> Yes, but we don't want to end up having everyone having mixed trees or
> be on ~arch; if we do, stabilization is going to become a wasted effort.

Perhaps the area to be clarified is "what is the intended risk profile
for arch and ~arch?"

stable and unstable mean very different things to different people, they
are quite overloaded terms, so a proper definition is in order. Then
users can also accurately just what they are going to get in arch as
well as the intended level of stability.

We already have a good beginning with the usual description of ~arch as
"works pretty much OK most of the time but new ebuilds go in here first
so expect some breakage sometimes". Let's express that in terms of risk.

Something else we should also keep in mind - binary distros often
recommend that autoupdates be enabled. If people do this it changes the
game play as they really don't know what is coming down the wire at all.
Gentoo is different - nothing changes until you sync and emerge world
and this really does require that the sysadmin eyeballs the output. This
removes a lot of the risk from the devs (you can't really know what my
USE will do on my end so I must assume some responsibility for my
choices). I do believe this gives the devs a lot of wiggle room to get
things into arch quicker without having to test and verify every little
thing.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 05:31, Tom Wijsman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 20 Aug 2013 14:28:15 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>
>> I see a few issues with ~arch -> table migrations:
>
>> #1 - things just sit in ~arch.  The auto-stablereq script should help
>> with this one I think; we should give it some time to see if it works
>> out.
>
> That script has been running for long enough now. It doesn't work out...

What do you mean when you say it doesn't work out?

Re: [gentoo-dev] rfc: stabilization policies

[Alan McKinnon]

On 21/08/2013 03:54, Doug Goldstein wrote:
> Its also precisely that mix and match that might cause instability due
> to people not testing things. Case in point QEMU 1.6.0 just came out and
> it went through a number of release candidates but no one ever saw that
> it depends only on Python 2.4 but actually needs Python 2.6. That's kind
> of like Gentoo, a package says it depends on libfoo 1.0 or higher and
> the dev that tested stable baz 0.8 confirmed it worked with libfoo 1.0,
> but baz 0.9 in ~arch still depends on libfoo 1.0 but really needs libfoo
> 1.1 and libfoo 1.1 is ~arch as well. So the developer running ~arch
> believed that baz 0.9 works fine since he has ~arch libfoo.
> 
> My point is what Gentoo calls "stable" is just something that usually 2
> or more people have compiled and installed vs ~arch which 1 or more
> people have compiled and installed.
> 

+1

I think comparisons with the RHELs of this world to find what stable
means are invalid. Gentoo does not play in RHELs space, and anyone who
tries to deploy Gentoo where RHEL is a good fit is somewhat of a fool
[Aside: I'm a huge Gentoo fan, all my personal machines are Gentoo or
FreeBSD and yet I have banned Gentoo outright at work: juniors cause me
too much headaches, and Centos fixed all of that]

Gentoo simply cannot offer the same guarantees about stable that RHEL
can, mostly for reasons of manpower. The best we can do is to state that
we are confident stuff works pretty much mostly OK and doesn't break for
everyone, so the user can now do their own tests and decide.

Let's also keep in mind that Gentoo is a meta-distribution - it lets you
build your own distro. So all the heavy QA lifting that RHEL does for
you, you now have to do yourself (that role bumps one run down the
ladder). The classic meaning of "stable" just doesn't quite fit in that
scenario.

And, a truly stable mission-critical system is one that has all the
required features and emerge is never run again except for bug and
security fixes. A rolling release will never be truly "stable"

What I'm saying is let's not set the bar for stable too high. Our
targeted userbase is somewhat unique in the world.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: stabilization policies

[joshua saddler]

On Aug 20, 2013, at 11:19 AM, William Hubbs <williamh@gentoo.org> wrote:
> 
> My question is, how can we improve our stabilization procedures/policies
> so we can convince people not to run production servers on ~arch and
> keep the stable tree more up to date?

do the Arch Linux thing…keep just one version of a package in the tree, as a general rule.

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 05:24, Tom Wijsman wrote:
> On Tue, 20 Aug 2013 13:19:10 -0500
> William Hubbs <williamh@gentoo.org> wrote:
>
>> All,
>>
>> I'm not really sure what the answer to this problem is, so I want to
>> know what the group thinks about how we can handle it.
>>
>> During the last release of OpenRC, I learned that people *do* run
>> production servers on ~arch.
>
> While I don't, and asked it just because of the large amount; it
> appears from some things lately, and not just OpenRC, that there is a
> certain group that regards ~arch as some kind of new stable.
>
> This isn't solely about versions entering ~arch, but also about
> versions leaving ~arch; as ~ is for testing, people should expect their
> version to break and they should also expect that they cannot rely on a
> version remaining in the Portage tree, that's just wrong...
We would probably benefit from formalising a clearer definition of 
arch/~arch - it seems to mean a lot of different things to different people.

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

20.08.2013 22:28, Ian Stakenvicius пишет:
> I see a few issues with ~arch -> table migrations:
> 
> #1 - things just sit in ~arch.  The auto-stablereq script should help
> with this one I think; we should give it some time to see if it works out.

My personal opinion on this - there is some package, that should not go
into stable. Do not get me wrong, but i presumes that stable gives user
ability to run well-working applications.

If package can fail in some stupid untrivial ways and maintainer can
reproduce this - then this version should not go into stable.

And you know that some packages can be in such state, well, for years of
active development. But it does not mean that some subset of users needs
them. That's why - ~arch(or, if they are broken in some security-related
things - hardmasked).

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

20.08.2013 23:48, Tom Wijsman пишет:
> Yes, +1; last time this came up on chat, I asked whether it would be a
> nice idea to have something between stable and ~, what you propose
> sounds similar and might make sense. Though, on the other hand, doing
> it this way we don't get the advantages that filing bugs give; if we
> do it this way, I'd assume we need some other implementation to
> cover that (for things like the "depends on", "blocks", ... fields)...

Why we should bring new half-stable, half-testing keyword for this? I
think that this is no way to go. We should improve current situation
with arches by some other ways(e.g., recruiting people). Maybe drop some
damn-bad understaffed arches to unstable only(i do not point finger on
anyone, they know, who they are... :-))

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

20.08.2013 23:42, Tom Wijsman пишет:
> On Tue, 20 Aug 2013 14:29:09 -0400
> Wyatt Epp <wyatt.epp@gmail.com> wrote:
>> What manner of bitrot?
> 
> They might ...
> 
> 2. ... contain security bugs that later versions have fixed. 

There should be security bug on our bugzilla with quick stabilization on
it and(probably) GLSA.


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 00:06, Tom Wijsman пишет:
> On Tue, 20 Aug 2013 15:41:42 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>>> Let me dig up an example...
>>>
>>> Our last sys-kernel/gentoo-sources stabilization was 3 months ago:
>>
>> I don't really see a problem with stable package being all of 3 months
>> old.  Contrast that with youtube-dl which pull from ~arch and rebuild
>> about 3x/week.
> 
> For something that releases once to twice a week, it is a problem;
> we're not talking about a package that gets some slow commits here, no,
> let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233

And you are dead sure that shiny new versions does not need testing in
Gentoo for a reasonable amount of time(30 days)? If yes, then we have a
problem in definitions here(thus, i am not talking about security
stabilizations, they should be done as quickly, as bug reveals)

> That's a lot of commits; now you need to realize that every single
> commit in this means something, a lot of them are bug fixes (stability,
> security, reliability, anti corruption, ...) whereas of course a part of
> it also introduces parts of new features and refactoring.
> 
> Desktop users might not care for all of these, but sysadmins will;
> actually, that's what this thread is about, they are switching to ~
> because of things like this. Who are we stabilizing for then?!

You should undestand that stabilizing new kernel should also imply that
some important modules, presenting in tree will also work with them. I
really do not like slow upstreams and situations like with
nvidia-drivers, but i understand that this is not kernel team matter, it
is upstream problem.

And that fact, that you can successfully build and run kernel for a
couple of hours, does not make it "good, well tested stable candidate"

> 
>     Bitrot due to a lack of resources.
> 

Such problem is exists, yeah, i agree. But do not overcomplicate things.
We should fight with lack of resources, not with turning stable into
"just more old, but also breakable testing"

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 17:54, Sergey Popov wrote:
> Why we should bring new half-stable, half-testing keyword for this? I
> think that this is no way to go. We should improve current situation
> with arches by some other ways(e.g., recruiting people). Maybe drop some
> damn-bad understaffed arches to unstable only(i do not point finger on
> anyone, they know, who they are... :-))
>
I agree, I don't think adding a new keyword will help. I am also a big 
fan of dropping understaffed archs to unstable (or if that is too much, 
only keeping stable keywords for important system packages).

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 00:00, Alan McKinnon пишет:
> Hey, maybe you guys are doing your job in ~arch *too well*, to your own
> detriment :-)  Something to consider?

~arch should not break every day, yeah(we have hardmasked for that :-P),
but it means that breakages are ALLOWED and it is NORMAL if they are not
severe.


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 16:51:37 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> On 21/08/2013 05:31, Tom Wijsman wrote:
>
> > On Tue, 20 Aug 2013 14:28:15 -0400
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> >
> > That script has been running for long enough now. It doesn't work
> > out...
> 
> What do you mean when you say it doesn't work out?

If it did, as we waited quite a while; we wouldn't have this thread.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 11:54:48 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> by some other ways(e.g., recruiting people).

Recruiting shows to be a hard task; so, the suggestions I am doing are
assuming that that doesn't work out. In which case, I wonder what "by
some other ways" you would think of...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 11:57:22 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 20.08.2013 23:42, Tom Wijsman пишет:
> > On Tue, 20 Aug 2013 14:29:09 -0400
> > Wyatt Epp <wyatt.epp@gmail.com> wrote:
> >> What manner of bitrot?
> > 
> > They might ...
> > 
> > 2. ... contain security bugs that later versions have fixed. 
> 
> There should be security bug on our bugzilla with quick stabilization
> on it and(probably) GLSA.

Not all security bugs are visible; the older a piece of software, the
higher the chance that some people know about one or another exploit
that the rest of the world does not know about.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 12:17, Tom Wijsman пишет:
> On Wed, 21 Aug 2013 11:57:22 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> 20.08.2013 23:42, Tom Wijsman пишет:
>>> On Tue, 20 Aug 2013 14:29:09 -0400
>>> Wyatt Epp <wyatt.epp@gmail.com> wrote:
>>>> What manner of bitrot?
>>>
>>> They might ...
>>>
>>> 2. ... contain security bugs that later versions have fixed. 
>>
>> There should be security bug on our bugzilla with quick stabilization
>> on it and(probably) GLSA.
> 
> Not all security bugs are visible; the older a piece of software, the
> higher the chance that some people know about one or another exploit
> that the rest of the world does not know about.
> 

True. But blindly bringing new versions into stable(without testing)
cause it POSSIBLY(without ChangeLog notes or CVES or whatever) contains
LESS security problems is not an option. Stable should be reasonable

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Pacho Ramos]

El mié, 21-08-2013 a las 18:08 +1000, Michael Palimaka escribió:
> On 21/08/2013 17:54, Sergey Popov wrote:
> > Why we should bring new half-stable, half-testing keyword for this? I
> > think that this is no way to go. We should improve current situation
> > with arches by some other ways(e.g., recruiting people). Maybe drop some
> > damn-bad understaffed arches to unstable only(i do not point finger on
> > anyone, they know, who they are... :-))
> >
> I agree, I don't think adding a new keyword will help. I am also a big 
> fan of dropping understaffed archs to unstable (or if that is too much, 
> only keeping stable keywords for important system packages).
> 

I would also like to know concrete cases of packages lacking stable
keywords on new enough versions. Maybe some of them comes from packages
maintained by understaffed teams and, then, the solution would be
different :/

Regarding the kernel... well, I don't think having a 3.8.x kernel as
stable one is so old, what are current kernel versions in stable Fedora,
OpenSuSE, Mageia... last time I checked we weren't so ahead on this
(thanks to kernel team ;))

About Gnome, situation should improve soon, regarding KDE looks like we
are OK.

Also, with Phajdan Jr automated bug reports situation improved and,
usually, the blocker is slow feedback from package maintainers in that
bug reports. But once arches are CC, arch teams usually do the job
really fast (specially thanks to Ago)

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 18:10, Tom Wijsman wrote:
> On Wed, 21 Aug 2013 16:51:37 +1000
> Michael Palimaka <kensington@gentoo.org> wrote:
>
>> On 21/08/2013 05:31, Tom Wijsman wrote:
>>
>>> On Tue, 20 Aug 2013 14:28:15 -0400
>>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>>
>>> That script has been running for long enough now. It doesn't work
>>> out...
>>
>> What do you mean when you say it doesn't work out?
>
> If it did, as we waited quite a while; we wouldn't have this thread.
>
As per your other post, it would be interesting to see who/what the 
worst offenders are.

At least in the areas I usually work, I have found a combination of the 
automatic stabilisation requests and imlate have definitely cut back on 
the bitrot.

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 12:07:16 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 00:06, Tom Wijsman пишет:
> > On Tue, 20 Aug 2013 15:41:42 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > 
> >>> Let me dig up an example...
> >>>
> >>> Our last sys-kernel/gentoo-sources stabilization was 3 months ago:
> >>
> >> I don't really see a problem with stable package being all of 3
> >> months old.  Contrast that with youtube-dl which pull from ~arch
> >> and rebuild about 3x/week.
> > 
> > For something that releases once to twice a week, it is a problem;
> > we're not talking about a package that gets some slow commits here,
> > no, let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233
> 
> And you are dead sure that shiny new versions does not need testing in
> Gentoo for a reasonable amount of time(30 days)? If yes, then we have
> a problem in definitions here(thus, i am not talking about security
> stabilizations, they should be done as quickly, as bug reveals)

3.10 is not a shiny new version, it has been in the Portage tree for 7
weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's
almost double the time you are suggesting.

> > That's a lot of commits; now you need to realize that every single
> > commit in this means something, a lot of them are bug fixes
> > (stability, security, reliability, anti corruption, ...) whereas of
> > course a part of it also introduces parts of new features and
> > refactoring.
> > 
> > Desktop users might not care for all of these, but sysadmins will;
> > actually, that's what this thread is about, they are switching to ~
> > because of things like this. Who are we stabilizing for then?!
> 
> You should undestand that stabilizing new kernel should also imply
> that some important modules, presenting in tree will also work with
> them. I really do not like slow upstreams and situations like with
> nvidia-drivers, but i understand that this is not kernel team matter,
> it is upstream problem.

Why should an external proprietary module that does not fix what is
broken for 7 weeks now block stabilization; it has never blocked
stabilization before, and I do not see a reason it should now...

> And that fact, that you can successfully build and run kernel for a
> couple of hours, does not make it "good, well tested stable candidate"

Having people run it for 7 weeks is not a couple of hours.

> > 
> >     Bitrot due to a lack of resources.
> > 
> 
> Such problem is exists, yeah, i agree. But do not overcomplicate
> things. We should fight with lack of resources, not with turning
> stable into "just more old, but also breakable testing"

Well, my thoughts is that the way we are doing it now we aren't going to
be able to deal with the lack of resources; so, a different approach is
necessary and I don't see how it is "old, but also breakable"...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 17:04:45 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> We would probably benefit from formalising a clearer definition of 
> arch/~arch - it seems to mean a lot of different things to different
> people.

http://devmanual.gentoo.org/keywording lists a definition; so, now I
wonder what it could be misinterpreted as. It states ~ is "believed" to
work, doesn't contain "serious" bugs but "more testing" is "required"...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 12:13, Tom Wijsman пишет:
> Recruiting shows to be a hard task; so, the suggestions I am doing are
> assuming that that doesn't work out. In which case, I wonder what "by
> some other ways" you would think of...

Dropping some keywords to unstable on minor arches. And about
recruiting, it is the only way we can keep moving with getting distro,
which makes bigger and bigger all the time.

I would have joined recruiters unless i knew how difficult job they are
doing.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Tue, 20 Aug 2013 20:42:57 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> >
> > Stable implies "not so often changing". If you really need newer
> > packages on a system that has to be rock-solid, then keyword what
> > you need and nothing else.
> 
> ++
> 
> 30 days is too long?  How can something new be stable?  Stable doesn't
> mean "I don't think this is broken."  Stable means "lots of others
> have already been using this and so far there aren't many reports of
> breakage."
> 
> According to distrowatch RHEL is at 2.6.32.  I'm sure it has a
> bazillion backports, but that is what I'd call stable.  Running stable
> means starting to use the stuff everybody else is about ready to stop
> using.  When an upstream releases a new stable release, that means
> that it is just now ready for testing, and chances are they'll have
> another stable release before their previous release really is stable.

"The latest distros seemed to be just a bunch of same old stuff.
Nothing new -- nothing innovative." ~ Larry's frustration. :(

"Then Larry tried Gentoo Linux. He was just impressed. ... He
discovered lots of up-to-date packages ..." ~ Larry's happiness. :)

http://www.gentoo.org/images/poster.jpg

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 12:25, Tom Wijsman пишет:
> 
> 3.10 is not a shiny new version, it has been in the Portage tree for 7
> weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's
> almost double the time you are suggesting.
> 

Current stabilization target(3.10.7) was added to tree:

*gentoo-sources-3.10.7 (15 Aug 2013)

  15 Aug 2013; Tom Wijsman <TomWij@gentoo.org>
+gentoo-sources-3.0.91.ebuild,
  +gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild,
  -gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild,
  -gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild,
  -gentoo-sources-3.4.54.ebuild:
  Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip)


So it is definitely NOT 7 weeks(30 days period counting from time when
ordinary user can install it through portage, thus - after hitting
portage tree). You know, that we can lighten stabilization requirements
of 30 days sometimes, but let's be honest.

> Why should an external proprietary module that does not fix what is
> broken for 7 weeks now block stabilization; it has never blocked
> stabilization before, and I do not see a reason it should now...
> 
>> And that fact, that you can successfully build and run kernel for a
>> couple of hours, does not make it "good, well tested stable candidate"
> 
> Having people run it for 7 weeks is not a couple of hours.
> 

First of all, as i said early - it is NOT 7 weeks(thus - not a couple of
hours either). And example with Nvidia drivers is not point of beginning
a flamewar. We ARE a distro. Then, we should propose INTEGRATION of some
kind.

If some open-source modules with active upstreams, included in portage,
do not support yet 3.10.* which will lead to unbootable system for some
stable users - what you should say? "Oops, sorry, guys?" That's not how
stable should work. We should either mark such modules as forever
unstable(or even mask?), saying "guys, shit happens, do not use this in
Gentoo, unless you are dead sure, that you can handle problems with
updates" or slowing down stabilization(i am not talking about security
stabilization right now). And as for security stabilization, if you say
that version bump BRINGS security fixes, you KNOW what they are, and you
do NOT file a security bug about old stable(and now - vulnerable!)
kernel on Gentoo bugzilla, then current stabilization bug has no
relation to security(as Gentoo Security team does not know about
security problems), period.


> Well, my thoughts is that the way we are doing it now we aren't going to
> be able to deal with the lack of resources; so, a different approach is
> necessary and I don't see how it is "old, but also breakable"...
> 

I undestand your disturbance as Gentoo Kernel team member. But your
proposal does not seem good to me.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 12:39, Tom Wijsman пишет:
> "The latest distros seemed to be just a bunch of same old stuff.
> Nothing new -- nothing innovative." ~ Larry's frustration. :(
> 
> "Then Larry tried Gentoo Linux. He was just impressed. ... He
> discovered lots of up-to-date packages ..." ~ Larry's happiness. :)
> 
> http://www.gentoo.org/images/poster.jpg
> 

And how that regards about stable, huh? If you want to raise problem
that ~arch has too less version bumps, well, that's other topic(but with
same reason - lack of manpower :-().

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 18:23:33 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> On 21/08/2013 18:10, Tom Wijsman wrote:
> > On Wed, 21 Aug 2013 16:51:37 +1000
> > Michael Palimaka <kensington@gentoo.org> wrote:
> >
> >> On 21/08/2013 05:31, Tom Wijsman wrote:
> >>
> >>> On Tue, 20 Aug 2013 14:28:15 -0400
> >>> Ian Stakenvicius <axs@gentoo.org> wrote:
> >>>
> >>> That script has been running for long enough now. It doesn't work
> >>> out...
> >>
> >> What do you mean when you say it doesn't work out?
> >
> > If it did, as we waited quite a while; we wouldn't have this thread.
> >
> As per your other post, it would be interesting to see who/what the 
> worst offenders are.

Well, they are listed there; but it's quite some work to actually go
through that list, that is, manually check the bugs of ~2000 packages
as well as file a STABLEREQ bug, takes quite a while...

> At least in the areas I usually work, I have found a combination of
> the automatic stabilisation requests and imlate have definitely cut
> back on the bitrot.

A single unimportant bug can prevent the automatic STABLEREQ bug from
getting filed; as for imlate, not everyone seems to know that tool, not
everyone seems to run it. Attention for some stabilizations is lost...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 10:22:39 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> Regarding the kernel... well, I don't think having a 3.8.x kernel as
> stable one is so old, what are current kernel versions in stable
> Fedora, OpenSuSE, Mageia... last time I checked we weren't so ahead
> on this (thanks to kernel team ;))

Don't compare apples and eggs. In other distros, heavy backporting of
fixes and so on happens; but on Gentoo, we instead want to keep our
genpatches minimal and therefore follow upstream stable more closely. If
we have a kernel version stable that is stable on other distros, it is
merely a sign that our stabilization currently is in a severe state...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 18:30, Tom Wijsman wrote:
> On Wed, 21 Aug 2013 17:04:45 +1000
> Michael Palimaka <kensington@gentoo.org> wrote:
>
>> We would probably benefit from formalising a clearer definition of
>> arch/~arch - it seems to mean a lot of different things to different
>> people.
>
> http://devmanual.gentoo.org/keywording lists a definition; so, now I
> wonder what it could be misinterpreted as. It states ~ is "believed" to
> work, doesn't contain "serious" bugs but "more testing" is "required"...
>
To me, this means something like: after carefully writing or updating 
the ebuild, and testing of the ebuild and application, there were no 
serious bugs. That is, I have in general found it to be as good as, or 
an improvement ("no serious bugs") on the previous version and it's 
suitable for wider consumption. Putting in the tree as ~arch will allow 
wider testing with configuration and usage that I didn't think of.

To some people it means something like this: if it doesn't immediately 
rm -rf / for most users (if you have a "funny" configuration and this 
happens, too bad don't use ~arch), it's fine.

I'm sure others have many different ideas, too.

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 12:32:35 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 12:13, Tom Wijsman пишет:
> > Recruiting shows to be a hard task; so, the suggestions I am doing
> > are assuming that that doesn't work out. In which case, I wonder
> > what "by some other ways" you would think of...
> 
> Dropping some keywords to unstable on minor arches.

If we grow (like you said below), then doing less seems like a decision
that we shouldn't take; it is rather about "doing it different" to use
our resources in a better way. Crowd sourcing users is an option here...

> And about recruiting, it is the only way we can keep moving with
> getting distro, which makes bigger and bigger all the time.

Yes, but apart from recruiting you can make the resources used better;
if the current way of using our resources isn't sufficient, we can
improve that as well. Improving both is going to make the difference.

> I would have joined recruiters unless i knew how difficult job they
> are doing.

Yes, I am interested in both mentoring and recruiting and I need to
contact them again; but I do not really intend to point at "recruiters"
here or how hard that is, what I intend to point at with recruiting is
finding those users that are willing to learn to write better ebuilds
and are willing to become a Gentoo Developer. They are hard to find;
and in order for them to be found, a mentor has to find them somewhere.

Came across three types of people already trying to find a mentee:

1. The first one doesn't want to go through the amount of time it takes;
   this depends a bit on the queue, but it can take months.

2. The second one's interest to become a Gentoo Developer depends from
   time to time; so, tries to start over and over to become one.

3. The third one writes a lot of ebuilds (and has an overlay that
   looks like a gold mine), but there is a language barrier that keeps
   the user from contributing; so, we take things slowly instead...

4. The fourth one leaves a message on IRC and quits before you return.

5. ...

So, recruiting in the terms of "finding recruits" appears to be hard.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 12:21:41 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 12:17, Tom Wijsman пишет:
> > On Wed, 21 Aug 2013 11:57:22 +0400
> > Sergey Popov <pinkbyte@gentoo.org> wrote:
> > 
> >> 20.08.2013 23:42, Tom Wijsman пишет:
> >>> On Tue, 20 Aug 2013 14:29:09 -0400
> >>> Wyatt Epp <wyatt.epp@gmail.com> wrote:
> >>>> What manner of bitrot?
> >>>
> >>> They might ...
> >>>
> >>> 2. ... contain security bugs that later versions have fixed. 
> >>
> >> There should be security bug on our bugzilla with quick
> >> stabilization on it and(probably) GLSA.
> > 
> > Not all security bugs are visible; the older a piece of software,
> > the higher the chance that some people know about one or another
> > exploit that the rest of the world does not know about.
> > 
> 
> True. But blindly bringing new versions into stable(without testing)
> cause it POSSIBLY(without ChangeLog notes or CVES or whatever)
> contains LESS security problems is not an option. Stable should be
> reasonable

That's not what I am suggesting.

It is not about bringing in new versions, but about getting rid of
OLD versions which LIKELY contain MORE security problems than you
imagine. Keeping them around for too long time isn't reasonable...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Manuel Rüger]

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

On 08/21/2013 09:57 AM, Sergey Popov wrote:
> 20.08.2013 23:42, Tom Wijsman пишет:
>> On Tue, 20 Aug 2013 14:29:09 -0400
>> Wyatt Epp <wyatt.epp@gmail.com> wrote:
>>> What manner of bitrot?
>>
>> They might ...
>>
>> 2. ... contain security bugs that later versions have fixed. 
> 
> There should be security bug on our bugzilla with quick stabilization on
> it and(probably) GLSA.
> 
> 

Security team could maintain its own p.accept_keywords in profiles/ and
add testing keyworded ebuilds that fix security issues there.
Users who are interested skipping the stabilization process could link
it into their /etc/portage/p.accept_keywords directory.

Kind regards

Manuel


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

Re: [gentoo-dev] rfc: stabilization policies

[Andreas K. Huettel]

Am Mittwoch, 21. August 2013, 10:39:23 schrieb Tom Wijsman:
>
> "The latest distros seemed to be just a bunch of same old stuff.
> Nothing new -- nothing innovative." ~ Larry's frustration. :(
> 
> "Then Larry tried Gentoo Linux. He was just impressed. ... He
> discovered lots of up-to-date packages ..." ~ Larry's happiness. :)
> 
> http://www.gentoo.org/images/poster.jpg

Yes. And most of the KDE team is acutally running live (master branch) 
ebuilds. Yay!

Having something stable too is a service and advantage, not a burden. 
Remember, stable means stable, and Gentoo is about choice!

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 12:46:17 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 12:25, Tom Wijsman пишет:
> > 
> > 3.10 is not a shiny new version, it has been in the Portage tree
> > for 7 weeks now (upstream release at 2013-06-30 22:13:42 (GMT));
> > so, that's almost double the time you are suggesting.
> > 
> 
> Current stabilization target(3.10.7) was added to tree:
> 
> *gentoo-sources-3.10.7 (15 Aug 2013)
> 
>   15 Aug 2013; Tom Wijsman <TomWij@gentoo.org>
> +gentoo-sources-3.0.91.ebuild,
>   +gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild,
>   -gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild,
>   -gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild,
>   -gentoo-sources-3.4.54.ebuild:
>   Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip)
> 
> 
> So it is definitely NOT 7 weeks(30 days period counting from time when
> ordinary user can install it through portage, thus - after hitting
> portage tree). You know, that we can lighten stabilization
> requirements of 30 days sometimes, but let's be honest.

That is 3.10.7, not 3.10; please look into how kernel releases work,
minor releases are merely a small number of "backported" "known" fixes.

What you propose, waiting 30 days for a minor; simply doesn't work
when there are one to two minors a week, it puts us even more behind...

> > Why should an external proprietary module that does not fix what is
> > broken for 7 weeks now block stabilization; it has never blocked
> > stabilization before, and I do not see a reason it should now...
> > 
> >> And that fact, that you can successfully build and run kernel for a
> >> couple of hours, does not make it "good, well tested stable
> >> candidate"
> > 
> > Having people run it for 7 weeks is not a couple of hours.
> > 
> 
> First of all, as i said early - it is NOT 7 weeks(thus - not a couple
> of hours either).

It is 7 weeks.

> And example with Nvidia drivers is not point of beginning a flamewar.
> We ARE a distro. Then, we should propose INTEGRATION of some kind.

Well, by bringing it up on the ML it will become one; I'm simply not
interested in this, decisions were taken a very long time ago anyway.

> If some open-source modules with active upstreams, included in
> portage, do not support yet 3.10.* which will lead to unbootable
> system for some stable users - what you should say? "Oops, sorry,
> guys?" That's not how stable should work.

That's how it has always worked, we do not see a need to change this.

> We should either mark such modules as forever unstable (or even
> mask?), saying "guys, shit happens, do not use this in Gentoo, unless
> you are dead sure, that you can handle problems with updates" or
> slowing down stabilization(i am not talking about security
> stabilization right now).

Tell them, I am interested if this will cause a change; I guess not...

> And as for security stabilization, if you
> say that version bump BRINGS security fixes, you KNOW what they are,
> and you do NOT file a security bug about old stable(and now -
> vulnerable!) kernel on Gentoo bugzilla, then current stabilization
> bug has no relation to security(as Gentoo Security team does not know
> about security problems), period.

Actually, those are constantly filed by ago; please look at the picture
first before you describe it, because you are drawing assumptions here.

> > Well, my thoughts is that the way we are doing it now we aren't
> > going to be able to deal with the lack of resources; so, a
> > different approach is necessary and I don't see how it is "old, but
> > also breakable"...
> > 
> 
> I undestand your disturbance as Gentoo Kernel team member. But your
> proposal does not seem good to me.

There is not a proposal in that quote; and through this thread, I and
others have made multiple proposals, I'm not sure what you refer to...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 12:49:03 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 12:39, Tom Wijsman пишет:
> > "The latest distros seemed to be just a bunch of same old stuff.
> > Nothing new -- nothing innovative." ~ Larry's frustration. :(
> > 
> > "Then Larry tried Gentoo Linux. He was just impressed. ... He
> > discovered lots of up-to-date packages ..." ~ Larry's happiness. :)
> > 
> > http://www.gentoo.org/images/poster.jpg
> > 
> 
> And how that regards about stable, huh?

Users that install Gentoo Linux will get their impression from "stable".

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 13:28, Tom Wijsman пишет:
> That is 3.10.7, not 3.10; please look into how kernel releases work,
> minor releases are merely a small number of "backported" "known" fixes.
> 
> What you propose, waiting 30 days for a minor; simply doesn't work
> when there are one to two minors a week, it puts us even more behind...
> 

We considered stabilizing package relying on it's version. Policy says
that we should wait reasonable amount of time, no matter which version
it is. And yes, minor release MAY bring breakages, do not tell me that
they are not, i hit such breakages at least 4 times for kernel(no matter
gentoo or vanilla, so problem is NOT genpatches) for past 5 years.

And do you really want to stabilize EVERY minor release of some upstream
stable branch? Maybe you want to bring some stable well tested version
for some period and let unstable users choose another if they want to?
And then - jump to next stable branch.

>>> Why should an external proprietary module that does not fix what is
>>> broken for 7 weeks now block stabilization; it has never blocked
>>> stabilization before, and I do not see a reason it should now...
>>>
>>>> And that fact, that you can successfully build and run kernel for a
>>>> couple of hours, does not make it "good, well tested stable
>>>> candidate"
>>>
>>> Having people run it for 7 weeks is not a couple of hours.
>>>
>>
>> First of all, as i said early - it is NOT 7 weeks(thus - not a couple
>> of hours either).
> 
> It is 7 weeks.

As i said early - it is not. Kernel team may have different policies on
stabilization, that's OK IMO, but do not bend facts. This is release,
and it should be considered as release, no matter minor or major. And
stabilizations counts from it, not from 3.10.0. Following your logic i
can say that KDE 4 is major release, and 4.1, 4.2 etc are "minor". They
are not.

>> If some open-source modules with active upstreams, included in
>> portage, do not support yet 3.10.* which will lead to unbootable
>> system for some stable users - what you should say? "Oops, sorry,
>> guys?" That's not how stable should work.
> 
> That's how it has always worked, we do not see a need to change this.

No it is not. We considered such things as serious flaws. At least - i
consider.

>> And as for security stabilization, if you
>> say that version bump BRINGS security fixes, you KNOW what they are,
>> and you do NOT file a security bug about old stable(and now -
>> vulnerable!) kernel on Gentoo bugzilla, then current stabilization
>> bug has no relation to security(as Gentoo Security team does not know
>> about security problems), period.
> 
> Actually, those are constantly filed by ago; please look at the picture
> first before you describe it, because you are drawing assumptions here.
> 

I do not see any dependant bugs in your current stable request, but you
keep telling me about security, so i do not drawing any assumptions - it
is not security stabilization in terms of Gentoo(probably it becomes so
if you can find apropriate security flaws).

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 13:17, Manuel Rüger пишет:
> 
> Security team could maintain its own p.accept_keywords in profiles/ and
> add testing keyworded ebuilds that fix security issues there.
> Users who are interested skipping the stabilization process could link
> it into their /etc/portage/p.accept_keywords directory.

No, it is not an option. Masking current stable because it is broken was
not successful also(i heard, that this was usual practice earlier).
Please, let's not reinvent the wheel around evident problem: lack of
manpower.

Easing stabilization procedure makes stable more, well, unstable.
Bringing some workarounds like this brokes consistency of keywording.
Keywords are things, that chosen by user. Overlays maintains keywords
lists, yeah, but that can be reasonable only on vast amount of
packages(like KDE).

As i said earlier, we should recruit more people -> then problem will go
away. Both for security(that have a VAST amount of work, that i am
saying as a rookie security developer :-)) and arch teams.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 13:13, Tom Wijsman пишет:
> On Wed, 21 Aug 2013 12:32:35 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> 21.08.2013 12:13, Tom Wijsman пишет:
>>> Recruiting shows to be a hard task; so, the suggestions I am doing
>>> are assuming that that doesn't work out. In which case, I wonder
>>> what "by some other ways" you would think of...
>>
>> Dropping some keywords to unstable on minor arches.
> 
> If we grow (like you said below), then doing less seems like a decision
> that we shouldn't take; it is rather about "doing it different" to use
> our resources in a better way. Crowd sourcing users is an option here...

What crowd sourcing do you talking about? We have Arch Tester for that.
Do you see vast interest in this initiative? I think not(thus, for major
arches we have some amount of testers, some of them are became
developers lately).
And if you want to move stabilization checks to unqualified users, then
it is way to nowhere.

> Came across three types of people already trying to find a mentee:
> 
> 1. The first one doesn't want to go through the amount of time it takes;
>    this depends a bit on the queue, but it can take months.
> 
> 2. The second one's interest to become a Gentoo Developer depends from
>    time to time; so, tries to start over and over to become one.
> 
> 3. The third one writes a lot of ebuilds (and has an overlay that
>    looks like a gold mine), but there is a language barrier that keeps
>    the user from contributing; so, we take things slowly instead...
> 
> 4. The fourth one leaves a message on IRC and quits before you return.
> 
> 5. ...
> 
> So, recruiting in the terms of "finding recruits" appears to be hard.
> 

But, at my POV, it is only one way that we can improve current situation.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 07:05, Tom Wijsman wrote:
> See `imlate --mtime=180 -s | less`. (From app-portage/gentoolkit-dev)
>
> I quote:
>
>> ==============================================
>> 4392 Stable candidates for 'gentoo' on 'amd64'
>> ==============================================
>
> Let's double the number to a year ago (360 instead of 180), I quote:
>
>> ==============================================
>> 2728 Stable candidates for 'gentoo' on 'amd64'
>> ==============================================
>
> And also get an impression of 3 months (90 instead of 180), I quote:
>
>> ==============================================
>> 6065 Stable candidates for 'gentoo' on 'amd64'
>> ==============================================
>
> At least the numbers for the year sound like something we will want to
> deal with; from there, we could try to keep half a year low. And after
> a while, we might end up ensuring stabilization within 3 months.
>
> That's still three times more than our intended stabilization delay...
>
For those not familiar with imlate, please note that these numbers 
include packages that have never been stabilised.

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 13:42:56 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> So it is definitely NOT 7 weeks

Let me clarify this again, our last stable kernel is from 7 weeks ago.

> 21.08.2013 13:28, Tom Wijsman пишет:
> > That is 3.10.7, not 3.10; please look into how kernel releases work,
> > minor releases are merely a small number of "backported" "known"
> > fixes.
> > 
> > What you propose, waiting 30 days for a minor; simply doesn't work
> > when there are one to two minors a week, it puts us even more
> > behind...
> > 
> 
> We considered stabilizing package relying on it's version.

We consider that as well, and for all the past releases it worked out.

> Policy says that we should wait reasonable amount of time, no matter
> which version it is.

It does not state anything about versions in the policy, AFAIK; please
refer me to it, and also note that on top of that we have the permission
from the arch teams to auto stable minor releases when necessary.

> And yes, minor release MAY bring breakages, do not tell me that they
> are not, i hit such breakages at least 4 times for kernel(no matter
> gentoo or vanilla, so problem is NOT genpatches) for past 5 years.

If you run ~, a breakage that you and some others experience less than
once a year is to be expected; so, what you state here does not reflect
our way of stabilization. In most of the cases, a later minor is better.

> And do you really want to stabilize EVERY minor release of some
> upstream stable branch? Maybe you want to bring some stable well
> tested version for some period and let unstable users choose another
> if they want to? And then - jump to next stable branch.

No, what you propose is what we have been doing for a long while.

> As i said early - it is not. Kernel team may have different policies
> on stabilization, that's OK IMO, but do not bend facts. This is
> release, and it should be considered as release, no matter minor or
> major. And stabilizations counts from it, not from 3.10.0. Following
> your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc
> are "minor". They are not.

Okay, then feel free to propose which versions we should pick for
stabilization? At which times? As you will see, it doesn't work out...

The kernel releases are not to be confused with that of another
package; if I take a look at KDE's 4.1 announcement [1] I see that it
is a "feature release", which is not what a minor kernel release does.

 [1]: http://www.kde.org/announcements/4.1/

> >> If some open-source modules with active upstreams, included in
> >> portage, do not support yet 3.10.* which will lead to unbootable
> >> system for some stable users - what you should say? "Oops, sorry,
> >> guys?" That's not how stable should work.
> > 
> > That's how it has always worked, we do not see a need to change
> > this.
> 
> No it is not. We considered such things as serious flaws. At least - i
> consider.

So do I, but why should it block stabilization?

Why do the stability and security of other users have to suffer by that?

There are other ways to deal with this:

 - Keep nvidia-drivers unstable, though they likely don't want to.

 - Clearly state that they don't work together, users should read that;
   but well, do we really want to account for the users that don't read?

 - Dep block the packages, *ugh*, let's not do this if we don't need to.

 - ...

> >> And as for security stabilization, if you
> >> say that version bump BRINGS security fixes, you KNOW what they
> >> are, and you do NOT file a security bug about old stable(and now -
> >> vulnerable!) kernel on Gentoo bugzilla, then current stabilization
> >> bug has no relation to security(as Gentoo Security team does not
> >> know about security problems), period.
> > 
> > Actually, those are constantly filed by ago; please look at the
> > picture first before you describe it, because you are drawing
> > assumptions here.
> > 
> 
> I do not see any dependant bugs in your current stable request, but
> you keep telling me about security, so i do not drawing any
> assumptions - it is not security stabilization in terms of
> Gentoo (probably it becomes so if you can find apropriate security
> flaws).

You do draw assumptions, because you don't take a look; please do:

https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org

Sort by "Changed" such that the newest appear on top.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 20:13:00 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> For those not familiar with imlate, please note that these numbers 
> include packages that have never been stabilised.

True, this brings up two questions:

 1. How do we filter out those that were never stabilized?

 2. How much of those actually don't need stabilization? How much do?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 13:54:51 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 13:13, Tom Wijsman пишет:
> > On Wed, 21 Aug 2013 12:32:35 +0400
> > Sergey Popov <pinkbyte@gentoo.org> wrote:
> > 
> >> 21.08.2013 12:13, Tom Wijsman пишет:
> >>> Recruiting shows to be a hard task; so, the suggestions I am doing
> >>> are assuming that that doesn't work out. In which case, I wonder
> >>> what "by some other ways" you would think of...
> >>
> >> Dropping some keywords to unstable on minor arches.
> > 
> > If we grow (like you said below), then doing less seems like a
> > decision that we shouldn't take; it is rather about "doing it
> > different" to use our resources in a better way. Crowd sourcing
> > users is an option here...
> 
> What crowd sourcing do you talking about? We have Arch Tester for
> that. Do you see vast interest in this initiative? I think not(thus,
> for major arches we have some amount of testers, some of them are
> became developers lately).

Yes, it is a large share of users that run ~, they "want to test".

> And if you want to move stabilization checks to unqualified users,
> then it is way to nowhere.

No, because there would be much more users giving feedback.

> > So, recruiting in the terms of "finding recruits" appears to be
> > hard.
> 
> But, at my POV, it is only one way that we can improve current
> situation.

Sorry, I do not understand (language barrier), do you mean that 1) that
should be the way to improve it or do you mean that 2) this is just one
approach and that we should look at different ones?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

[gentoo-dev] Re: rfc: stabilization policies

[Michael Palimaka]

On 21/08/2013 20:31, Tom Wijsman wrote:
> On Wed, 21 Aug 2013 20:13:00 +1000
> Michael Palimaka <kensington@gentoo.org> wrote:
>
>> For those not familiar with imlate, please note that these numbers
>> include packages that have never been stabilised.
>
> True, this brings up two questions:
>
>   1. How do we filter out those that were never stabilized?
I don't see any option, perhaps imlate could use that improvement.

>
>   2. How much of those actually don't need stabilization? How much do?
>
Someone said to me once "everything in ~arch is a candidate for 
stabilisation. if it should never be stabilised, it shouldn't be in the 
tree."
I'm not sure if I agree with that statement or not, but I suspect most 
things in the tree that have never been stabilised are that way simply 
because nobody every asked. There really is a large number of packages 
just rotting in ~arch though.

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 13:50:22 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> Easing stabilization procedure makes stable more, well, unstable.

It doesn't have to be easier; it just has to be done differently, in
which way we can benefit from the users whom are actively testing it.
Currently we use "no bugs were filed lately" as a measure; but not all
bugs get filed downstream, so that's a problematic measurement.

If we bring in another measure, that is, users that state if it is
stable or broken; then we have another measure that help determine
whether to stabilize, because then you wouldn't have cases where 1) a
package ends up being stabilized although it doesn't work for 33% of
the users because the GUI wasn't tested thoroughly and also not have
cases where 2) a package works for almost anyone but not for the arch
tester for some blocker that nobody else experiences at all. It
clarifies that the arch tester's system is broken, which we then fix.

> Bringing some workarounds like this brokes consistency of keywording.

It does not, when replacing the current way things are done we do not
aim for it to be easier but rather for it to be different in that more
users can contribute to the effort; the effort doesn't get easier, and
should not result in a less consistent way of keywording. This should
not be "let's ask some users" but rather "let's set up a carefully
designed framework to properly deal with this".

> As i said earlier, we should recruit more people -> then problem will
> go away.

There is no guarantee of that; years from now, we might have this
discussion again. Yeah, maybe we might not; let's see what comes...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Pacho Ramos]

El mié, 21-08-2013 a las 11:16 +0200, Tom Wijsman escribió:
[...]
> That's not what I am suggesting.
> 
> It is not about bringing in new versions, but about getting rid of
> OLD versions which LIKELY contain MORE security problems than you
> imagine. Keeping them around for too long time isn't reasonable...
> 

I agree with seeing this problem, I guess it occurs because we
(maintainers) usually forget about dropping old versions once last arch
is done (probably because usually it takes long time to get all arches
done). Maybe allowing all parties (maintainers, security and last arch
team) cleanup old version could help :/ (I guess, there is no way to
automatically notify maintainers about last arch doing the stabilization
and, then, letting us drop it)

Re: [gentoo-dev] Re: rfc: stabilization policies

[Pacho Ramos]

El mié, 21-08-2013 a las 10:57 +0200, Tom Wijsman escribió:
> On Wed, 21 Aug 2013 10:22:39 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > Regarding the kernel... well, I don't think having a 3.8.x kernel as
> > stable one is so old, what are current kernel versions in stable
> > Fedora, OpenSuSE, Mageia... last time I checked we weren't so ahead
> > on this (thanks to kernel team ;))
> 
> Don't compare apples and eggs. In other distros, heavy backporting of
> fixes and so on happens; but on Gentoo, we instead want to keep our
> genpatches minimal and therefore follow upstream stable more closely. If
> we have a kernel version stable that is stable on other distros, it is
> merely a sign that our stabilization currently is in a severe state...
> 

In that case, probably the way to go would be to provide different
versions tagged as "stable":
1. The last one (would be 3.10.x now, I think)
2. The last one supporting that drivers used widely (nvidia comes to my
mind now, no idea about ATI drivers status)

But, does the kernel stabilization policy apply to the rest? Isn't it a
"bit special case"? I mean, I would like to know what exact pieces are
missing that people running testing in "production servers". I doubt
it's because of "old toolchain". Isn't easier (and less risky) to report
the bug and add the package to package.keywords instead of switching all
to "testing".

Maybe the question is why that people don't report that bugs. I guess
it's because, some times, stabilization bugs are ignored for a long time
by maintainer. Maybe the situation could be improved if some of us could
review that bugs periodically and directly CC arches if maintainer
doesn't disagree (we usually need to do that manually... not sure if
could be done in a more "automatic" way, I guess Phajdan will have
something for that as he does it for his automated reports)

Re: [gentoo-dev] rfc: stabilization policies

[Michael Orlitzky]

On 08/21/2013 12:35 AM, Ben de Groot wrote:
> On 21 August 2013 04:12, Michael Orlitzky <michael@orlitzky.com> wrote:
>> [snip]
>> Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
>> 3.0 was released almost exactly three years ago. Every time rails-3.x
>> gets bumped, I have to manually update the entire list above. I need
>> to do it on an x86 server as well, so I get to do it twice; I can't
>> even copy/paste the list.
> 
> Yes you can. Just leave out the actual keyword. It will assume ~arch.
> 

(also in reply to Jonathan)

I would rather not do this because I'd like to have as few lines as
possible in package.accept_keywords, and things get stabled on x86 and
amd64 at a different rate.

So, for example, if I have,

  =dev-ruby/thor-0.15.2 ~amd64

in package.accept_keywords, and tomorrow it goes stable on amd64, I can
remove it from the list. Running eix-test-obsolete will alert me to this
fact if I have the version in the atom. If it's *not* stable on x86 yet,
then I can't make the same change there.

If I have instead,

  dev-ruby/thor

It'll just pull in the latest ~amd64 version, and eix won't let me know
that I can drop the keyword.

Re: [gentoo-dev] rfc: stabilization policies

[Rich Freeman]

On Wed, Aug 21, 2013 at 4:39 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> "The latest distros seemed to be just a bunch of same old stuff.
> Nothing new -- nothing innovative." ~ Larry's frustration. :(
>
> "Then Larry tried Gentoo Linux. He was just impressed. ... He
> discovered lots of up-to-date packages ..." ~ Larry's happiness. :)
>

I'm not suggesting that we should be backporting bugfixes for two
years.  I'm just suggesting that it isn't a big deal if stable
packages are ~90 days behind in general.  Plus, Larry can always run
the just-released KDE or whatever by accepting ~arch for that package
and get a system where nothing other than KDE is likely to break.

I have nothing against improvements that help us keep up though.  If a
package gets held up because of actual regressions (go read Ago's blog
RE definition of a regression) that is one thing.  If things get held
up simply because nobody notices they're late, that is another.

Plus, the innovation Larry was talking about doesn't mean having
chrome-29 in the tree two days sooner than some other distro.  What is
innovative about Gentoo at its heart is letting the user have his cake
and eat it too, like running a stable system but still getting
chrome-29 near release day.  I do firmly believe that Gentoo is a
great distro for getting neat things done.

Manpower will still always be an issue.  I requested stable on mythtv
on x86 a few weeks ago, but I can completely understand that
client-server apps that typically involve hardware just aren't going
to get turned around on a dime (FYI - if anybody wants to volunteer
test that on x86 feel free to contact me and we can probably work
something out with the x86 arch team together).

Rich

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 14:36, Tom Wijsman пишет:
> On Wed, 21 Aug 2013 13:54:51 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> 21.08.2013 13:13, Tom Wijsman пишет:
>>> On Wed, 21 Aug 2013 12:32:35 +0400
>>> Sergey Popov <pinkbyte@gentoo.org> wrote:
>>>
>>>> 21.08.2013 12:13, Tom Wijsman пишет:
>>>>> Recruiting shows to be a hard task; so, the suggestions I am doing
>>>>> are assuming that that doesn't work out. In which case, I wonder
>>>>> what "by some other ways" you would think of...
>>>>
>>>> Dropping some keywords to unstable on minor arches.
>>>
>>> If we grow (like you said below), then doing less seems like a
>>> decision that we shouldn't take; it is rather about "doing it
>>> different" to use our resources in a better way. Crowd sourcing
>>> users is an option here...
>>
>> What crowd sourcing do you talking about? We have Arch Tester for
>> that. Do you see vast interest in this initiative? I think not(thus,
>> for major arches we have some amount of testers, some of them are
>> became developers lately).
> 
> Yes, it is a large share of users that run ~, they "want to test".

But it seems that they do not want to become Arch testers and bring
things to stable, do not you think?

>> And if you want to move stabilization checks to unqualified users,
>> then it is way to nowhere.
> 
> No, because there would be much more users giving feedback.

Feedback is good. But if it simple "works for me" without tests on
CFLAGS/LDFLAGS respect regression, cross-compile breakage regression or
any other regressions, than it is pointless. I would suggest increase
number of arch testers... Or, i repeat myself(in infinite time),
"recruit more people"

>>> So, recruiting in the terms of "finding recruits" appears to be
>>> hard.
>>
>> But, at my POV, it is only one way that we can improve current
>> situation.
> 
> Sorry, I do not understand (language barrier), do you mean that 1) that
> should be the way to improve it or do you mean that 2) this is just one
> approach and that we should look at different ones?
> 

Yeah, my grammar sucks, i know. So, let's summarize what i mean. To deal
with our current problems with arches we have only two ways:

1) drop some arches to unstable -> lower the burden to arch teams;
2) recruit more arch testers/arch team members;

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 14:29, Tom Wijsman пишет:
> On Wed, 21 Aug 2013 13:42:56 +0400
> You do draw assumptions, because you don't take a look; please do:
> 
> https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org
> 
> Sort by "Changed" such that the newest appear on top.
> 

And how should i must knew that these bugs related to particular
versions if they do not contain affected versions(i know that ALL
versions may be affected in particular time, but we are talking about
new stable kernel which bring fixes) and no dependant bugs in stable
request? How can i, not beeing member of Gentoo Kernel Team, discover
that it is security stabilization and which security bugs, registered in
our bugzilla, will gone when i will upgrad to it?

Honestly, we should revive Kernel Security subproject somehow, cause
this mess may confuse even ordinary developers.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 16:16:53 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> >> And if you want to move stabilization checks to unqualified users,
> >> then it is way to nowhere.
> > 
> > No, because there would be much more users giving feedback.
> 
> Feedback is good. But if it simple "works for me" without tests on
> CFLAGS/LDFLAGS respect regression, cross-compile breakage regression
> or any other regressions, than it is pointless.

Sounds like Tinderbox covers those; so, it has a point for the rest.

> I would suggest increase number of arch testers... Or, i repeat
> myself(in infinite time), "recruit more people"

That I agree with; but, will that be enough?

> >>> So, recruiting in the terms of "finding recruits" appears to be
> >>> hard.
> >>
> >> But, at my POV, it is only one way that we can improve current
> >> situation.
> > 
> > Sorry, I do not understand (language barrier), do you mean that 1)
> > that should be the way to improve it or do you mean that 2) this is
> > just one approach and that we should look at different ones?
> > 
> 
> Yeah, my grammar sucks, i know. So, let's summarize what i mean. To
> deal with our current problems with arches we have only two ways:
> 
> 1) drop some arches to unstable -> lower the burden to arch teams;

This didn't come up until recently; so, yes, that might work! :)

> 2) recruit more arch testers/arch team members;

Same point as before, let's see if that will be enough.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Wed, 21 Aug 2013 16:22:28 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 21.08.2013 14:29, Tom Wijsman пишет:
> > On Wed, 21 Aug 2013 13:42:56 +0400
> > You do draw assumptions, because you don't take a look; please do:
> > 
> > https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org
> > 
> > Sort by "Changed" such that the newest appear on top.
> > 
> 
> And how should i must knew that these bugs related to particular
> versions if they do not contain affected versions(i know that ALL
> versions may be affected in particular time, but we are talking about
> new stable kernel which bring fixes) and no dependant bugs in stable
> request? How can i, not beeing member of Gentoo Kernel Team, discover
> that it is security stabilization and which security bugs, registered
> in our bugzilla, will gone when i will upgrad to it?

Our dev 'ago' is on top of all that, but we really shouldn't rely on a
single person; the lack of manpower causes uncertainty here, and it is
because of that that we have to regard any stabilization as security.

Given the kernel volume, I think even CVE's don't cover everything...

> Honestly, we should revive Kernel Security subproject somehow, cause
> this mess may confuse even ordinary developers.

+1 The latest kernel related discussion(s) also make it clear there is
a need for more documentation on how things currently work; because
people that are not aware what happens upstream are making assumptions
that don't reflect reality, and this makes it harder to reach consensus.

With the hope of one or two people wanting to help out on genpatches
(although I haven't heard from them lately); I'll try to document
upstream's release cycle as well as how our current maintenance is
done as part of the move to Gentoo Wiki, together with the rest we
could then also clarify some kernel team policies and guidelines...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Pacho Ramos]

El mié, 21-08-2013 a las 14:25 +0200, Tom Wijsman escribió:
[...]
> > 2) recruit more arch testers/arch team members;
> 
> Same point as before, let's see if that will be enough.
> 

Well, ago has being doing a great work getting more Arch Testers (at
least for amd64), maybe some of them could give the step of becoming
real devs with commit access to help him... probably Ago will know about
them and their situation :)

Re: [gentoo-dev] rfc: stabilization policies

[Wyatt Epp]

On Wed, Aug 21, 2013 at 5:50 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>
> As i said earlier, we should recruit more people -> then problem will go
> away.

This is a point most of the people in this thread seem to be dancing
around that's sort of problematic.  You can talk about recruiting
until you're blue in the face, but the simple fact is Gentoo DOESN'T
have adequate manpower.  And has it ever, really?  Can you honestly
say we've ever had a solid surplus of devs with time [0]?  We've
gotten where we are, by and large, because Gentoo works smarter.

Fundamentally, I see this as a problem of tooling.

Let's turn the question around; try thinking about it like this: What
tools have historically allowed relatively few active developers
handle stablisation and integration of upstream patch flow IN SPITE of
not having a lot of recruits?  What tools could be added to assist
with, if not outright _remove_ steps of the process?

I'd like to point out something that jumped out to me as a red flag
earlier (not to pick on you specifically, Tom; this is just the
cleanest example I saw), and turn it into an example:

On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> Well, they are listed there; but it's quite some work to actually go
> through that list, that is, manually check the bugs of ~2000 packages
> as well as file a STABLEREQ bug, takes quite a while...
>
This right here is a real problem.  Any time you're talking about
doing anything on this scale "manually", you've already lost the
battle.  You need a tool to minimise the overhead of time and
cognitive load.  What would that tool look like?  Think about the
steps involved and how you can reduce them to only the parts that
absolutely require decisions on your part.

>> At least in the areas I usually work, I have found a combination of
>> the automatic stabilisation requests and imlate have definitely cut
>> back on the bitrot.
>
> A single unimportant bug can prevent the automatic STABLEREQ bug from
> getting filed; as for imlate, not everyone seems to know that tool, not
> everyone seems to run it. Attention for some stabilizations is lost...
>
First off, why do developers not know about the tools?  How can this
be addressed?  For a start, I'd suggest making sure the tools are at
least mentioned in the docs.  Somewhere other than the amd64 Arch
Testing guide from 2006. [1] That's the only concrete (i.e. actually
in the DOCS rather than the ML archives) documentation I've found so
far, and it only references the file, rather than the tool.  Maybe in
the devmanual Tools Reference? [2]

But, imlate is a good example of a tool that could ease the time cost
of grindy crap.  You showed before that it can get an ordinary count
bounded on n days.  That's handy, but only a little.  Build out:
- How many of those stablereq bugs reference versions no longer in the
tree?  Those can probably get closed.
- How many have newer STABLE versions in the tree in the same slot?
Probably fine to close those, too.
- Of the remaining, how many have patches or ebuilds attached?  Those
may be solved problems waiting for closure; shortlist them.
- How many are packages with newer versions that have been in the tree
for >30 days?  Consider changing the target version, then.
- How many have open blockers, and what are those blockers (w/link and
summary)?  Scan for low-hanging fruit jumping out in that list.
- Get views by category; are there categories where updates are more
important?  Things in @system, and things with security concerns
(stuff in net-*) should probably get higher priority; games...
probably less so.
- Are there bugs with certain keywords in the body that should raise
priority?  Things like "security" or "overflow" might be good
candidates.
- Are there bugs with certain keywords in the body that indicate it'll
be really easy to decide? e.g. "trivial" or "minor" might turn up some
of those super-small version bumps that you pretty much know aren't
going to affect stability.

These are just examples off the top of my head, and by no means
bulletproof, but these are in the class of improvements that have ROI
because they reduce a task that previously took developer time to one
that takes CPU time.  CPU time is essentially free compared to the
value of dev time.

And I'm not saying more recruiting shouldn't happen, but relying on it
is no better than hoping at $deity for bugs to close themselves. ;)

Cheers,
Wyatt

[0] Okay, maybe in the "glory days" when we were higher up on
Distrowatch and thing were really kicking. (I know, I know, "DW isn't
representative", but really? Sabayon is doing better than we are,
now?)
[1] http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1&chap=2
[2] http://devmanual.gentoo.org/tools-reference/index.html

Re: [gentoo-dev] rfc: stabilization policies

[Ian Stakenvicius]

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

On 21/08/13 08:36 AM, Tom Wijsman wrote:
> 
> Given the kernel volume, I think even CVE's don't cover
> everything...
> 

Kernel is really a special case here, imo -- emerge doesn't install
kernels, it just provides their sources.  End-users still need to
build the kernel to use them and I expect there are plenty that don't,
at least, not as soon as the sources are installed.  And really,
portage is just providing kernel sources for convenience; anybody can
download a kernel by hand, extract it to /usr/src, and build it with
no ill effect on portage or the rest of their system.

That's not to say that gentoo-sources shouldn't follow the regular
overall stabilization policies, but focusing on the kernel as the
impetus for adjusting the stabilization policy or pointing out what's
wrong with the policy as a whole seems to be a bad use-case for this
discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIUzmcACgkQ2ugaI38ACPB07gD+Ps0gTO/gqgZQXMUCtcmXWw1/
Bv6n5HeDQD21qo59rxoA/21DZ8zUkpGSJIOldB8uL+zXTUhzbadvtdhrCJoelT4Q
=69yu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 21 Aug 2013 10:27:51 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 21/08/13 08:36 AM, Tom Wijsman wrote:
> > 
> > Given the kernel volume, I think even CVE's don't cover
> > everything...
> > 
> 
> Kernel is really a special case here, imo -- emerge doesn't install
> kernels, it just provides their sources.  End-users still need to
> build the kernel to use them and I expect there are plenty that don't,
> at least, not as soon as the sources are installed.  And really,
> portage is just providing kernel sources for convenience; anybody can
> download a kernel by hand, extract it to /usr/src, and build it with
> no ill effect on portage or the rest of their system.

That doesn't make it a special case here, imo; especially not, since
we are designing and implementing ebuilds that _build_ the kernel.
Whether it provides the sources, or build it; what does that matter?

We're talking here in terms of Gentoo QA and Stability; so, other
people building the kernel on their own (which you could do with most
packages in the tree, just install it to /usr/local or something), has
nothing at all to do with this entire thread.

I don't understand what you try to say with that paragraph.

> That's not to say that gentoo-sources shouldn't follow the regular
> overall stabilization policies, but focusing on the kernel as the
> impetus for adjusting the stabilization policy or pointing out what's
> wrong with the policy as a whole seems to be a bad use-case for this
> discussion.

It's a good example to demonstrate bit rot due to lack of manpower,
that's it sole intention; don't assume it as an example for change of
policies, that's not what's being shown here. And for a change in
policies proper statistics would be the least a person should base on.

The sub thread, to clarify some matters, is indeed long enough as it is;
and at some point we should have probably switched to gentoo-kernel ML.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQEcBAEBAgAGBQJSFNU5AAoJEJWyH81tNOV93yQH/3vZZRfnbbrmtc9AuTq8cHLj
q4fNQtsdhAcF5hT/VSLCODSlxt1+7g3j+jnIHTbKpxAwI/sALJO7ojNi5VYDK8zq
LxgjEy91yVBVq2v974HyA4Snolo236cxZVwaT8g+GVrzDk2NAT8pAFV+QIubS/Gs
nsmN5XPZPXIr027ZrH0k6eM+OjCBnKT4uqQIaRRHNSjkxAki611yIj9XsLn3yyiH
Yc9kmKcGtjuc/daLyvFWmQIAaXxGhFug6YYpmb1fU3/i2Tn0fBqYnesN5DW85WYB
cjd8eqGDIA/yS7MXX6Lx9V1Zd4gPvmZINHzhFUZ0i4dums+cyXM9b2bxvrRLM2g=
=zVwU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Rich Freeman]

On Wed, Aug 21, 2013 at 10:27 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> That's not to say that gentoo-sources shouldn't follow the regular
> overall stabilization policies, but focusing on the kernel as the
> impetus for adjusting the stabilization policy or pointing out what's
> wrong with the policy as a whole seems to be a bad use-case for this
> discussion.

++

I track ~arch on a few packages and few get anywhere near the kernel
in terms of update frequency.  The ones that do are usually little
niche utilities that cause little issue if they break (calibre,
youtube-dl, etc).

The kernel also benefits from an unusually robust quality system
outside of Gentoo.  I'm not saying that this is the only project that
has strong quality upstream, but few packages that update so often do.

That said, kernel updates are not without issue either.  There are
certainly have been changes in behavior that impact other system deps
in the past.  So if for whatever reason we do stabilize kernels more
often we'll have to make sure the kernel team is extra vigilant for
these kinds of changes and that they coordinate accordingly (the fact
that ~arch doesn't break often suggests that this is likely already
happening).

Rich

Re: [gentoo-dev] rfc: stabilization policies

[Sergey Popov]

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

21.08.2013 17:38, Wyatt Epp пишет:
> Fundamentally, I see this as a problem of tooling.


I think that no tool can cover all cases of checking that software
WORKS. I mean - in generic, for all kinds of software. You can guarantee
if it builds, if it follow some QA rules about CFLAGS/LDFLAGS/whatever,
but there is only one 100% way to guarantee that software works - run
and do something useful :-).

Yeah, i know about testsuites, that can help in that case. Unfortunately:

1) they do not cover all cases, but that's not so important;
2) often they are badly broken;
3) not every program carries test suite.

So, we stuck at automation in run-time checks right at the beginning :-).

But yeah, we could automate build-time checks, surely.


> 
> I'd like to point out something that jumped out to me as a red flag
> earlier (not to pick on you specifically, Tom; this is just the
> cleanest example I saw), and turn it into an example:
> 
> On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>
>> Well, they are listed there; but it's quite some work to actually go
>> through that list, that is, manually check the bugs of ~2000 packages
>> as well as file a STABLEREQ bug, takes quite a while...
>>
> This right here is a real problem.  Any time you're talking about
> doing anything on this scale "manually", you've already lost the
> battle.  You need a tool to minimise the overhead of time and
> cognitive load.  What would that tool look like?  Think about the
> steps involved and how you can reduce them to only the parts that
> absolutely require decisions on your part.
> 
>>> At least in the areas I usually work, I have found a combination of
>>> the automatic stabilisation requests and imlate have definitely cut
>>> back on the bitrot.
>>
>> A single unimportant bug can prevent the automatic STABLEREQ bug from
>> getting filed; as for imlate, not everyone seems to know that tool, not
>> everyone seems to run it. Attention for some stabilizations is lost...
>>
> First off, why do developers not know about the tools?  How can this
> be addressed?  For a start, I'd suggest making sure the tools are at
> least mentioned in the docs.  Somewhere other than the amd64 Arch
> Testing guide from 2006. [1] That's the only concrete (i.e. actually
> in the DOCS rather than the ML archives) documentation I've found so
> far, and it only references the file, rather than the tool.  Maybe in
> the devmanual Tools Reference? [2]
> 

Good point, i agree.

> But, imlate is a good example of a tool that could ease the time cost
> of grindy crap.  You showed before that it can get an ordinary count
> bounded on n days.  That's handy, but only a little.  Build out:
> - How many of those stablereq bugs reference versions no longer in the
> tree?  Those can probably get closed.
> - How many have newer STABLE versions in the tree in the same slot?
> Probably fine to close those, too.
> - Of the remaining, how many have patches or ebuilds attached?  Those
> may be solved problems waiting for closure; shortlist them.
> - How many are packages with newer versions that have been in the tree
> for >30 days?  Consider changing the target version, then.
> - How many have open blockers, and what are those blockers (w/link and
> summary)?  Scan for low-hanging fruit jumping out in that list.
> - Get views by category; are there categories where updates are more
> important?  Things in @system, and things with security concerns
> (stuff in net-*) should probably get higher priority; games...
> probably less so.
> - Are there bugs with certain keywords in the body that should raise
> priority?  Things like "security" or "overflow" might be good
> candidates.
> - Are there bugs with certain keywords in the body that indicate it'll
> be really easy to decide? e.g. "trivial" or "minor" might turn up some
> of those super-small version bumps that you pretty much know aren't
> going to affect stability.
> 
> These are just examples off the top of my head, and by no means
> bulletproof, but these are in the class of improvements that have ROI
> because they reduce a task that previously took developer time to one
> that takes CPU time.  CPU time is essentially free compared to the
> value of dev time.

That's what i called constuctive criticism. Congratulations :-)

> And I'm not saying more recruiting shouldn't happen, but relying on it
> is no better than hoping at $deity for bugs to close themselves. ;)
> 
> Cheers,
> Wyatt
> 
> [0] Okay, maybe in the "glory days" when we were higher up on
> Distrowatch and thing were really kicking. (I know, I know, "DW isn't
> representative", but really? Sabayon is doing better than we are,
> now?)
> [1] http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1&chap=2
> [2] http://devmanual.gentoo.org/tools-reference/index.html
> 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-dev] rfc: stabilization policies

[Rich Freeman]

On Wed, Aug 21, 2013 at 10:56 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> That doesn't make it a special case here, imo; especially not, since
> we are designing and implementing ebuilds that _build_ the kernel.
> Whether it provides the sources, or build it; what does that matter?

Yes and no.  I don't think the kernel needs a separate
QA/stabilization policy per-se.

However, it probably isn't a good barometer of the state of the tree.
On the one hand, it is probably one of the most popular and
looked-after packages in the tree.  On the other hand it has releases
with both high frequency and impact.  There really isn't a single FOSS
project like the Linux kernel anywhere.

So this isn't about making up different rules for the kernel.  The
issue is more that I wouldn't use the kernel as my main example of the
state of the tree.  I'm not sure it even makes sense to have single
examples so much as categories.

It might be interesting to see how up-to-date stable packages are when
looking at system vs non-system (glibc vs mplayer), package popularity
(firefox vs baobab), desktop vs server (vlc vs mysql), and so on.  I
suspect though that it has as much to do with maintainer philosophy as
the package itself - some maintainers pay more attention to stable.

Rich

Re: [gentoo-dev] rfc: stabilization policies

[Hans de Graaff]

On Tue, 2013-08-20 at 16:12 -0400, Michael Orlitzky wrote:

> > # Redmine
> > =dev-ruby/builder-3.1.4 ~amd64
> > =dev-ruby/rails-3.2.13 ~amd64

> Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
> 3.0 was released almost exactly three years ago. Every time rails-3.x
> gets bumped, I have to manually update the entire list above. I need
> to do it on an x86 server as well, so I get to do it twice; I can't
> even copy/paste the list.

Apologies for that. This is a case of lack of man-power combined with a
nasty set of dependencies to get stable (e.g. circular dependencies,
packages outside of ruby also needing to go stable). Unfortunately not
the most motivating work, especially compared to a lot of other tasks in
the ruby herd. I've been making some inroads a month ago, and I should
really push this through to stable.

Fun fact: no one ever filed a stable bug for a Rails 3 version. I think
users could help out with the overall problem being discussed here as
well by filing STABLEREQ bugs for things they need from ~arch.

BTW, you can drop "~amd64" and have the same meaning, leaving you with a
copy/pasteable list.

> It sucks, but it's still better than running ~arch. Problems like this
> should be fixed, but if you decide it's easier to
> ACCEPT_KEYWORDS="~arch" than deal with the exceptions, you're asking for
> trouble.

+1.

Hans

Re: [gentoo-dev] rfc: stabilization policies

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/21/2013 05:13 AM, Tom Wijsman wrote:
> On Wed, 21 Aug 2013 12:32:35 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> 21.08.2013 12:13, Tom Wijsman пишет:
>>> Recruiting shows to be a hard task; so, the suggestions I am doing
>>> are assuming that that doesn't work out. In which case, I wonder
>>> what "by some other ways" you would think of...
>>
>> Dropping some keywords to unstable on minor arches.
> 
> If we grow (like you said below), then doing less seems like a decision
> that we shouldn't take; it is rather about "doing it different" to use
> our resources in a better way. Crowd sourcing users is an option here...
> 
>> And about recruiting, it is the only way we can keep moving with
>> getting distro, which makes bigger and bigger all the time.
> 
> Yes, but apart from recruiting you can make the resources used better;
> if the current way of using our resources isn't sufficient, we can
> improve that as well. Improving both is going to make the difference.
> 
>> I would have joined recruiters unless i knew how difficult job they
>> are doing.
> 
> Yes, I am interested in both mentoring and recruiting and I need to
> contact them again; but I do not really intend to point at "recruiters"
> here or how hard that is, what I intend to point at with recruiting is
> finding those users that are willing to learn to write better ebuilds
> and are willing to become a Gentoo Developer. They are hard to find;
> and in order for them to be found, a mentor has to find them somewhere.
> 
> Came across three types of people already trying to find a mentee:
> 
> 1. The first one doesn't want to go through the amount of time it takes;
>    this depends a bit on the queue, but it can take months.
> 
> 2. The second one's interest to become a Gentoo Developer depends from
>    time to time; so, tries to start over and over to become one.
> 
> 3. The third one writes a lot of ebuilds (and has an overlay that
>    looks like a gold mine), but there is a language barrier that keeps
>    the user from contributing; so, we take things slowly instead...
> 
> 4. The fourth one leaves a message on IRC and quits before you return.
> 
> 5. ...
I know we are a little OT here but the fifth type of recruit is someone
who is very excited, very dedicated, and completely unable to find a
mentor.  That is where I was for a long time, no one seemed to have the
time to mentor me.  Personally I think that is a big issue in the growth
of gentoo, if we all take a little time out to be mentors there will be
more gentoo devs and we will get more done.

- -ZC
> 
> So, recruiting in the terms of "finding recruits" appears to be hard.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSIhvmAAoJEKXdFCfdEflKwykP/32wuUhRfcwYZsq5pZDMhj3e
KVDrODlnNt9gsLU3nWj4CuOil5IecWzaODmrejN9bWjW9xEPHGYhs6WfUkGL+8Bm
wVg7yun1v/ACNynraLi9F3YimDeFruFSLMeYttaxb04KJVGdCETXQN4/qiKGqRl5
p4o1kEQUAWie0DURKm1rO1z7zdBOJczdk70QAcwO/5t80gCyrIlWFor/jZ1Nvk05
TASTs25Jxd5hQ+FZsqeIem458eQj3j+OvuJBgcBT34+7ka1nsP7ZWmLBVBEvejGC
If3D0xaDQD0Rjxf6jtnt8vILSzQTq7UUkGLIvRGlxiA7fFSLxMrQHz2UDo1pxKfg
BbQZ4ftm7icjum/DE5XyGWRHlbVE5Zvi/joV+pKoLw2BaDZrxTqGgDjqLGPpP5W4
P7/+3+PH8x9GZKgco1d34eFA9oXdGVorRDybuOb33Hy/CgUvAr+n9tLfPOjHW1Ye
U09BTRzlceJQmp3KLHvdmYLIm9THsdI7YfjlSxPyaDKykiFNwRCfRPMvp2FTqBNr
doVm8dyX8+4FqtW+BkwdUZjTVEv5AQv9jdqx/rfNy9UJ8qWfLTPXWcHrJWu8gOsv
3G+mAGvqKMXkJWarguydGf3q8QJzmPXscps4vPq9AcTpWldPLQW8lxPzic4IpYjN
O3TUqhO0KX9NejKTO6Ef
=yG20
-----END PGP SIGNATURE-----

How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies

[Jeroen Roovers]

On Sat, 31 Aug 2013 12:37:58 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> I know we are a little OT here but the fifth type of recruit is

Yes.

> someone who is very excited, very dedicated, and completely unable to
> find a mentor.  That is where I was for a long time, no one seemed to
> have the time to mentor me.

Your recruitment bug disagrees with you here in that you had a mentor
right from the start.

The netmon@g.o alias never saw mail from you before your recruitment
bug was openend, so how could anyone have known you were trying to
attract a mentor and do netmon stuff?

I don't see any mail on gentoo-dev or gentoo-project either.

There are exactly *nill* bugs that you reported and were (subsequently)
CC'd or Assigned to netmon@g.o.

You have only yourself to blame.


     jer

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 31 Aug 2013 12:37:58 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> I know we are a little OT here but the fifth type of recruit is
> someone who is very excited, very dedicated, and completely unable to
> find a mentor.  That is where I was for a long time, no one seemed to
> have the time to mentor me.

It can indeed be though to find someone with time. But there are
certainly people that do have time and are willing to mentor; it's just
that, you've got to find each other at the right time and place.

Which makes me think we should have some way to list people that are
willing to become Gentoo Developers as well as Gentoo Developers that
are willing to mentor people. Perhaps on the Gentoo Wiki?

That would turn the easy to miss "anyone want to mentor me?" or random
probing "do _you_ want to be my mentor?" into an approach where it's a
matter of looking at a list, contacting someone and you are set.

> Personally I think that is a big issue
> in the growth of gentoo, if we all take a little time out to be
> mentors there will be more gentoo devs and we will get more done.

+1

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQEcBAEBAgAGBQJSIjWiAAoJEJWyH81tNOV99Z4H/RqrSRQFZ2GtXhp/3cDJkulP
+gxYk2kdWxfoPRCzn4Yv9rLELEkvrrcSEN2u0HM6kP+Br9rOVwY0n5MjFlQbu6+t
I0xN372l9I489tjj9THMB3NjgTnyFqFRzTv07xu9oeiw1OtbmII4JDMyEmsyUMmC
MgfgSEMyd1CgsYF9lTp9nJLIMoRym+o9d6PrjoFgGKIhBKL//JGxMIdAdixQotCo
r7aOXpO0mf0sOLI3m5JdIp4wm12uTjBtkSpuOkCUeKz16F23M4fwd8l+v+lLQ1G+
cqjnPs1QHUos8W/wzSw5gohCnc0anF9D1mkiwmnd4qhblg1jRzwNm271zD7hv+k=
=HByi
-----END PGP SIGNATURE-----

Re: How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Sat, 31 Aug 2013 19:29:30 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> > someone who is very excited, very dedicated, and completely unable
> > to find a mentor.  That is where I was for a long time, no one
> > seemed to have the time to mentor me.
> 
> Your recruitment bug disagrees with you here in that you had a mentor
> right from the start.

The recruitment bug is filed by the mentor; the bug on it own marks the
time at which a mentor is willing to mentor the mentee, but it does
not reflect the time at which he started to look for a mentor.

> I don't see any mail on gentoo-dev or gentoo-project either.

This makes me wonder if that is a good or bad idea; on the one hand, it
would be nice to see a mentee step up and look for a mentor on the MLs
but on the other hand that might result in some noise. After all, the
relation between a mentor and a mentee is from person to person; and
not from person to list. It's not really a discussion; so, I don't
feel like it necessarily belongs on the MLs, unless as announcement.

Even if this were considered a good idea, then how would we get people
to advertise themselves on the mailing lists?

There seem to be two things we need to think about:

1. Where do people find the information on how to find a mentor?

2. Where do we want people to look for a mentor?

But that's one side of the story; the other side has the same
questions, but at least has an answer. Mentors find the a mentee (eg.
nice bug reporter) between a lot of people (eg. all bug reporters); so,
it's like finding signal in a lot of noise. What we need on this other
side, might be better tools to find outstanding users; but that on
their own take some time to implement and might not gain much.

So, I'm rooting for having a central list where mentors and mentees can
find each other; I think that that would give the best of both worlds.

> The netmon@g.o alias never saw mail from you before your recruitment
> bug was openend, so how could anyone have known you were trying to
> attract a mentor and do netmon stuff?
>
> ...
>
> There are exactly *nill* bugs that you reported and were
> (subsequently) CC'd or Assigned to netmon@g.o.

Not everyone wants to immediately start out on a herd.

> You have only yourself to blame.

Since when did this become a game of blame with him?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] rfc: stabilization policies

[Pacho Ramos]

El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina escribió:
[...]
> I know we are a little OT here but the fifth type of recruit is someone
> who is very excited, very dedicated, and completely unable to find a
> mentor.  That is where I was for a long time, no one seemed to have the
> time to mentor me.  Personally I think that is a big issue in the growth
> of gentoo, if we all take a little time out to be mentors there will be
> more gentoo devs and we will get more done.
> 
> -ZC

I guess we should have a official contact or mail alias to let them
contact. If they don't even contact me, I cannot know about them and
then mentor them :/

Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

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

On Sat, 31 Aug 2013 20:45:00 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina
> escribió: [...]
> > I know we are a little OT here but the fifth type of recruit is
> > someone who is very excited, very dedicated, and completely unable
> > to find a mentor.  That is where I was for a long time, no one
> > seemed to have the time to mentor me.  Personally I think that is a
> > big issue in the growth of gentoo, if we all take a little time out
> > to be mentors there will be more gentoo devs and we will get more
> > done.
> > 
> > -ZC
> 
> I guess we should have a official contact or mail alias to let them
> contact. If they don't even contact me, I cannot know about them and
> then mentor them :/

Ah, I like this idea better than the "list on Gentoo Wiki" I was trying
to approach; the only downside I can imagine if it were a single person
that might not respond in time (busy / devaway / MIA), so I think we
should at least aim to make it a mail alias with multiple persons.

We could then list people on some project page; but, only their
forenames or nicknames and not their actual full name and e-mail such
that their private details can stay private if they wish to.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2013 01:29 PM, Jeroen Roovers wrote:
> On Sat, 31 Aug 2013 12:37:58 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> I know we are a little OT here but the fifth type of recruit is
> 
> Yes.
> 
>> someone who is very excited, very dedicated, and completely unable to
>> find a mentor.  That is where I was for a long time, no one seemed to
>> have the time to mentor me.
> 
> Your recruitment bug disagrees with you here in that you had a mentor
> right from the start.
> 
> The netmon@g.o alias never saw mail from you before your recruitment
> bug was openend, so how could anyone have known you were trying to
> attract a mentor and do netmon stuff?
> 
> I don't see any mail on gentoo-dev or gentoo-project either.
> 
> There are exactly *nill* bugs that you reported and were (subsequently)
> CC'd or Assigned to netmon@g.o.
> 
> You have only yourself to blame.
> 
Always a pleasure my friend.

- -ZC
> 
>      jer
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSImbCAAoJEKXdFCfdEflKi1sP/1lXGfpuM6u55OcAtvhiQFE4
CL5Zff1vHdLXv1/3JOz9WyVn6D5cmo2zF0Da3IIVYfbnEIU7TDTkdGUrGz/xnTJi
wjbmbLQqxIrB5HYMMHVoa7JFsotkV8c4Tnwg2J81HcuQOQpJMb19xlkLHI0fNbrh
8r8Ac2MPGDdx3kwlq7K5zi85scYXGBJN7rR4Ok4y01AGZlrKLan2GH473/eoE8DD
8iLcm9tc2fvN/PWtAO2J0UvpqPbQOx9DF0ttWzVCA/RV/KAtf90p3Exf+uWCy8ru
HHCxlo4hG9q3q5ehuJMYXw6cqql5RIB7s6HeJKM9lFXukaOxmW7+xiqo0ne22ePD
Novpuip4rd5Brir2QKDLMPu8feQ+PJwkQU+U/q/K6KsSrTT2AYVnZR3SuiykjxG6
4AjBMF4KLVWLhOcYlmtCTg0XWBwqyN7+KBfiAVOKBwX0NZcUp8ILnd0C34I/Cqp+
YGPlY2JCpeWCU4XVJo++RhOtNZP9pnPFATcW+a2bdjMfTOQ9Z7Sjy3bn8r9d1TMe
PMLEwVWKQkoreK8w1MNKoxU1x2UGkj82Fal/WEf8OLXev6hdzZOZ1tb/S91KRZT6
OoN7zQy8TpkFqqbNWRsIao4J6V9kW+4RKMCTAJKSqH/Ere1AoJje/WSkly+vuL++
SIVKdElbXczHu482qm6W
=aN4N
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2013 03:57 PM, Tom Wijsman wrote:
> On Sat, 31 Aug 2013 20:45:00 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
>> El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina
>> escribió: [...]
>>> I know we are a little OT here but the fifth type of recruit is
>>> someone who is very excited, very dedicated, and completely unable
>>> to find a mentor.  That is where I was for a long time, no one
>>> seemed to have the time to mentor me.  Personally I think that is a
>>> big issue in the growth of gentoo, if we all take a little time out
>>> to be mentors there will be more gentoo devs and we will get more
>>> done.
>>>
>>> -ZC
>>
>> I guess we should have a official contact or mail alias to let them
>> contact. If they don't even contact me, I cannot know about them and
>> then mentor them :/
> 
> Ah, I like this idea better than the "list on Gentoo Wiki" I was trying
> to approach; the only downside I can imagine if it were a single person
> that might not respond in time (busy / devaway / MIA), so I think we
> should at least aim to make it a mail alias with multiple persons.
> 
> We could then list people on some project page; but, only their
> forenames or nicknames and not their actual full name and e-mail such
> that their private details can stay private if they wish to.
> 

I remember actively seeking out mentors and recruiters on irc for a
while and not getting very far.  I think that exposing recruitment to a
wider audience than just the recruiters is a good idea, why limit
ourselves to their bandwidth?  This isn't a remark on the performance of
the recruiters, just a note that more people means more bandwidth.

I like the idea of having a wiki page of people willing to be mentors
for each area (or in general).

- -ZC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSImdFAAoJEKXdFCfdEflKq+cP+gIhD2zAR6CnVFVx7hmYvPKa
n8Jkg5oCPgchqVPN3AtDqPXwTELSPXTasRJCToaembKYuhPiyO6py/dpo6nIeg/P
4WiLZb+ehCSWAUBMmAemsDoL3WftwrV9w6h1bWBytpbrJ6YZEyumVvHNqMi3r7vI
+k54LZc+uurUEHFtPP6SC6kCHj9n0lD/4Biq1lsY/vwZFViHzuBhnTHBYBohy4lo
rkB2/k/KvrJ6F9MXfc87A/PUxkU29+WKiul9A9te/X97QheeXXWptI4gEYFevVgT
aUP8AfaY0YAD1+RpjyxDPxJ4cTqcL38Wic8ql6pzlV9nwAnN3/fHFQEKJ477UWO4
YLGkdQ0BX4y0WkJH0H5fi3zuU80iHvLw0I0U1rVOP861IrlYxKMPuXUn6F1vGCpq
Huzx7pbLcLE0GTYU6Sq5Li4zdMxW7Lre2oqIAD9smj1Fx2VpQp35lFI01TKfAbdb
dP08EBfI/c15C6O8v1UooDYjwM7JV1EjoZW+OcPO8rLdahakzS6VhTs6JRMKH+UM
X1xqX1Grj5dRUIt2KHGPtCxHAI9VuMQqWDNEv8qmDCzenL4WOcd2TCYL5HNofAbH
lWJdKYL3m6OhEVH8e7qaOIbm0hShJBqY90kJWbyowJgbPSllaPepbBNuys3iq4dM
eToDKW2TXa4ELG6Xc5vl
=eFsz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: stabilization policies

[Thomas Sachau]

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

Rick "Zero_Chaos" Farina schrieb:
> On 08/31/2013 03:57 PM, Tom Wijsman wrote:
>> On Sat, 31 Aug 2013 20:45:00 +0200
>> Pacho Ramos <pacho@gentoo.org> wrote:
> 
>>> El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina
>>> escribió: [...]
>>>> I know we are a little OT here but the fifth type of recruit is
>>>> someone who is very excited, very dedicated, and completely unable
>>>> to find a mentor.  That is where I was for a long time, no one
>>>> seemed to have the time to mentor me.  Personally I think that is a
>>>> big issue in the growth of gentoo, if we all take a little time out
>>>> to be mentors there will be more gentoo devs and we will get more
>>>> done.
>>>>
>>>> -ZC
>>>
>>> I guess we should have a official contact or mail alias to let them
>>> contact. If they don't even contact me, I cannot know about them and
>>> then mentor them :/
> 
>> Ah, I like this idea better than the "list on Gentoo Wiki" I was trying
>> to approach; the only downside I can imagine if it were a single person
>> that might not respond in time (busy / devaway / MIA), so I think we
>> should at least aim to make it a mail alias with multiple persons.
> 
>> We could then list people on some project page; but, only their
>> forenames or nicknames and not their actual full name and e-mail such
>> that their private details can stay private if they wish to.
> 
> 
> I remember actively seeking out mentors and recruiters on irc for a
> while and not getting very far.  I think that exposing recruitment to a
> wider audience than just the recruiters is a good idea, why limit
> ourselves to their bandwidth?  This isn't a remark on the performance of
> the recruiters, just a note that more people means more bandwidth.

Please keep in mind, that recruiters in Gentoo usually only point to
possible places with mentors, they dont search for recruits, they dont
know, which dev may match as mentor and they dont assign someone. They
are mainly involved, when someone found a mentor and got prepared.

From my experience, the best way to get started is helping out in the
area you are interested in. When you have worked in some area for some
time, you likely get noticed, already worked with some devs and have
good chances, that someone offers himself as mentor.

On the other side, if you just join some places and ask things like "Who
will be my mentor, i want to join", it is pretty unlikely, that someone
will instantly step up.

Keep in mind, that proper mentoring includes a good amount of time to
invest, so when someone notices that you are already around for some
time and did not quickly disappear again, they may be more willing to
assist you in your task of becoming a dev.

So with this said, i am not sure, if such a central contact point will
really improve the situation, it may instead result in a lot of churn,
since people loose interest on their way to dev or shortly after.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] rfc: stabilization policies

[hasufell]

On 09/01/2013 12:30 PM, Thomas Sachau wrote:
> they dont search for recruits

why not?

Re: [gentoo-dev] rfc: stabilization policies

[Markos Chandras]

On 1 September 2013 11:42, hasufell <hasufell@gentoo.org> wrote:
> On 09/01/2013 12:30 PM, Thomas Sachau wrote:
>> they dont search for recruits
>
> why not?
>

Will you please ready Thomas e-mail again as a whole? You only
"extract" a single sentence
and you redirect the other part of it to /dev/null.
We (recruiters) only point people to the appropriate places.
We can't just go ahead an find a recruit for the eg Gnome team. The
Gnome team will have to find good
recruits for their team and then "give" them to us to recruit them properly.
It's impossible for us to find all the "good" people out there and
bring them on board.
The individual projects/team need to do that for us.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang