[gentoo-dev] taking a break from arches stabilization

[gentoo-dev] taking a break from arches stabilization

[Agostino Sarubbo]

Hi all.

every time that I attach my tmux session to see what happens on irc, I always 
see the same discussion about the 'minor' arches status.
Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
effort in amd64 and less where I saw other people work on it (arm,alpha)
But every time the magic phrase is that those arches are unmaintained.

Now, since I work on these arches just to help, i.e. I don't have any business 
and I do non have any installation of those arches and the work I'm doing is 
not appreciated at all I decided to stop for now.
If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
objections.
I will take a break also from amd64 and x86...let's see how things will 
change.

-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-dev] taking a break from arches stabilization

[Alexis Ballier]

On Mon, 10 Jul 2017 19:22:20 +0200
Agostino Sarubbo <ago@gentoo.org> wrote:

> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc,
> I always see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put
> more effort in amd64 and less where I saw other people work on it
> (arm,alpha) But every time the magic phrase is that those arches are
> unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any
> business and I do non have any installation of those arches and the
> work I'm doing is not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things
> will change.
> 

Thanks for your work. It is appreciated. I respect your decision that
your time might be better spent by not trying to artificially maintain
some arches alive when you're clearly the only one doing the work and
caring about them.

There's an annoying side effect of open source communities that I've
came to witness a lot: When you do your work too well, nobody feels the
need to help by contributing, and you're essentially left alone.


Alexis.

Re: [gentoo-dev] taking a break from arches stabilization

[Rich Freeman]

On Mon, Jul 10, 2017 at 1:22 PM, Agostino Sarubbo <ago@gentoo.org> wrote:
>
> Now, since I work on these arches just to help, i.e. I don't have any business
> and I do non have any installation of those arches and the work I'm doing is
> not appreciated at all I decided to stop for now.

I wouldn't say that your work is unappreciated.  However, when those
are called "unmaintained" arches it reflects the fact that very few
are contributing to them.  The nature of a linux distro is that one
person could be working 24x7 with bleeding fingers and it would be
like sticking a finger in a dike.  It takes more than one contributor
(even a serious one) to make something like this viable.

> I will take a break also from amd64 and x86...let's see how things will
> change.

I'm not sure I really see the connection but you're of course welcome
to work on whatever you want to.  In the case of amd64 we already
encourage individual package maintainers to stabilize their own
packages, and I think this is much more sustainable than having an
arch team do it.  Back when amd64 was exotic and a lot of packages
needed patching to work having a focused arch team to handle this made
a lot of sense - they owned the hardware and also were accustomed to
spotting type errors and so on.  These days upstream just works on
amd64 and everybody is using it.

I'm not diminishing your contributions in any way (which have always
been tremendous).  I'm just saying that a model that depends less on
heroics would benefit everybody.

-- 
Rich

Re: [gentoo-dev] taking a break from arches stabilization

[Andrew Savchenko]

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

Hi,

On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 1:22 PM, Agostino Sarubbo <ago@gentoo.org> wrote:
> >
> > Now, since I work on these arches just to help, i.e. I don't have any business
> > and I do non have any installation of those arches and the work I'm doing is
> > not appreciated at all I decided to stop for now.
> 
> I wouldn't say that your work is unappreciated.  However, when those
> are called "unmaintained" arches it reflects the fact that very few
> are contributing to them.  The nature of a linux distro is that one
> person could be working 24x7 with bleeding fingers and it would be
> like sticking a finger in a dike.  It takes more than one contributor
> (even a serious one) to make something like this viable.
> 
> > I will take a break also from amd64 and x86...let's see how things will
> > change.
> 
> I'm not sure I really see the connection but you're of course welcome
> to work on whatever you want to.  In the case of amd64 we already
> encourage individual package maintainers to stabilize their own
> packages, and I think this is much more sustainable than having an
> arch team do it.

Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
stabilization must be carried out by arch teams, unless a special
arrangement is done between a developer and a team.

[1] https://devmanual.gentoo.org/keywording/index.html
[2] https://wiki.gentoo.org/wiki/GLEP:40

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] taking a break from arches stabilization

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
>
>> In the case of amd64 we already
>> encourage individual package maintainers to stabilize their own
>> packages
>
> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
> stabilization must be carried out by arch teams, unless a special
> arrangement is done between a developer and a team.
>

The docs are probably out of date - I'm not sure if the policy is
documented anywhere.  However it has been a fairly longstanding policy
at this point that amd64 allows individual maintainers to stabilize
their own packages.

-- 
Rich

Re: [gentoo-dev] taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/10/2017 10:02 PM, Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>>
>> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
>>
>>> In the case of amd64 we already
>>> encourage individual package maintainers to stabilize their own
>>> packages
>>
>> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
>> stabilization must be carried out by arch teams, unless a special
>> arrangement is done between a developer and a team.
>>
> 
> The docs are probably out of date - I'm not sure if the policy is
> documented anywhere.  However it has been a fairly longstanding policy
> at this point that amd64 allows individual maintainers to stabilize
> their own packages.
> 

We looked after it for wg-stable (which died out as a result of rather
low participation, maybe it should be rebooted if people feel like
discussing this again), there isn't any authoritative policy allowing
it, GLEP:40 explicitly removes the possibility to do it for x86. That
said, for a number of packages maintainer stabilization can likely make
sense, the opposite view is four-eyes principle, it is always good to
have someone else build-test etc, but this is greatly helped by
tinderboxing efforts (thanks toralf) etc. So one likely output if
wg-stable is to come up with something would be a replacement GLEP for
40 that matches the current state, and also kernel auto-stabiliation (as
discussed in [section 3.2 (Kernel)]

References:
[section 3.2 (Kernel)]
https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf

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


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

Re: [gentoo-dev] taking a break from arches stabilization

[Andrew Savchenko]

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

On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote:
> On 07/10/2017 10:02 PM, Rich Freeman wrote:
> > On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> >>
> >> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
> >>
> >>> In the case of amd64 we already
> >>> encourage individual package maintainers to stabilize their own
> >>> packages
> >>
> >> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
> >> stabilization must be carried out by arch teams, unless a special
> >> arrangement is done between a developer and a team.
> >>
> > 
> > The docs are probably out of date - I'm not sure if the policy is
> > documented anywhere.  However it has been a fairly longstanding policy
> > at this point that amd64 allows individual maintainers to stabilize
> > their own packages.
> > 
> 
> We looked after it for wg-stable (which died out as a result of rather
> low participation, maybe it should be rebooted if people feel like
> discussing this again), there isn't any authoritative policy allowing
> it, GLEP:40 explicitly removes the possibility to do it for x86. That
> said, for a number of packages maintainer stabilization can likely make
> sense, the opposite view is four-eyes principle, it is always good to
> have someone else build-test etc, but this is greatly helped by
> tinderboxing efforts (thanks toralf) etc. So one likely output if
> wg-stable is to come up with something would be a replacement GLEP for
> 40 that matches the current state, and also kernel auto-stabiliation (as
> discussed in [section 3.2 (Kernel)]

So, am I understanding this correctly that right now a package
stabilization by maintainer without explicit permit from an arch
team will be the violation of active and approved policies?

Despite the maintainer-driven stabilization seems to be "a fairly
longstanding policy" I'm reluctant to do such stabilization myself,
because anyone may point out later that such action is a violation
of the written policies and I will have nothing to defend me.

Even if such stabilization is allowed, there are unanswered
questions here:
- is following seciton 4.1 from wg recommendations is sufficient?
- should developer test each stabilization candidate on an
up-to-date stable setup?

Best regards,
Andrew Savchenko

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

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
> On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote:
>> On 07/10/2017 10:02 PM, Rich Freeman wrote:
>>> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>>>>
>>>> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
>>>>
>>>>> In the case of amd64 we already
>>>>> encourage individual package maintainers to stabilize their own
>>>>> packages
>>>>
>>>> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
>>>> stabilization must be carried out by arch teams, unless a special
>>>> arrangement is done between a developer and a team.
>>>>
>>>
>>> The docs are probably out of date - I'm not sure if the policy is
>>> documented anywhere.  However it has been a fairly longstanding policy
>>> at this point that amd64 allows individual maintainers to stabilize
>>> their own packages.
>>>
>>
>> We looked after it for wg-stable (which died out as a result of rather
>> low participation, maybe it should be rebooted if people feel like
>> discussing this again), there isn't any authoritative policy allowing
>> it, GLEP:40 explicitly removes the possibility to do it for x86. That
>> said, for a number of packages maintainer stabilization can likely make
>> sense, the opposite view is four-eyes principle, it is always good to
>> have someone else build-test etc, but this is greatly helped by
>> tinderboxing efforts (thanks toralf) etc. So one likely output if
>> wg-stable is to come up with something would be a replacement GLEP for
>> 40 that matches the current state, and also kernel auto-stabiliation (as
>> discussed in [section 3.2 (Kernel)]
> 
> So, am I understanding this correctly that right now a package
> stabilization by maintainer without explicit permit from an arch
> team will be the violation of active and approved policies?

As Rich pointed out, amd64 team has long allowed maintainers to perform
their own stabilisations. I've asked x86 team about this in the past,
and they too were OK with maintainer stabilisations.

It would be nice to improve documentation of this, but it is certainly
not a policy violation just because some ancient document was never updated.

> Despite the maintainer-driven stabilization seems to be "a fairly
> longstanding policy" I'm reluctant to do such stabilization myself,
> because anyone may point out later that such action is a violation
> of the written policies and I will have nothing to defend me.
> 
> Even if such stabilization is allowed, there are unanswered
> questions here:
> - is following seciton 4.1 from wg recommendations is sufficient?
> - should developer test each stabilization candidate on an
> up-to-date stable setup?

The guidelines from that document are ripped straight out of the
devmanual and are a good starting point but rather generic. You can find
some more detailed suggestions on things to consider while testing on
the wiki: https://wiki.gentoo.org/wiki/Package_testing

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Rich Freeman]

On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>
>> Even if such stabilization is allowed, there are unanswered
>> questions here:
>> - is following seciton 4.1 from wg recommendations is sufficient?
>> - should developer test each stabilization candidate on an
>> up-to-date stable setup?
>
> The guidelines from that document are ripped straight out of the
> devmanual and are a good starting point but rather generic. You can find
> some more detailed suggestions on things to consider while testing on
> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>

I think that in practice arch teams don't do have the stuff on that
wiki page.  Maybe some people do, but back when I was an amd64 AT I
don't think anybody went testing multiple USE combinations for a
typical package.

However, to directly answer one of Andrew's questions, yes, you
definitely should test on a stable system/chroot/container.  I've seen
a few package updates over the years that wouldn't even build and it
was probably because whoever keyworded it never even tried building it
with stable dependencies.  That is pretty rare though.

-- 
Rich

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/11/2017 11:06 PM, Rich Freeman wrote:
> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>
>>> Even if such stabilization is allowed, there are unanswered
>>> questions here:
>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>> - should developer test each stabilization candidate on an
>>> up-to-date stable setup?
>>
>> The guidelines from that document are ripped straight out of the
>> devmanual and are a good starting point but rather generic. You can find
>> some more detailed suggestions on things to consider while testing on
>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>
> 
> I think that in practice arch teams don't do have the stuff on that
> wiki page.  Maybe some people do, but back when I was an amd64 AT I
> don't think anybody went testing multiple USE combinations for a
> typical package.

Everything on that page is deliberately a suggestion only, and not
necessarily specific to stabilisation testing.

In the end, we've never been able to reach any consensus on what exactly
an arch tester should do. Personally, I think we should just switch to
fully-automated, build-only testing for stabilistions unless the
maintainer opts otherwise (something that largely happens in practice
already). The main risk of breakage of a package moving from testing to
stable is always at build time anyway.

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/11/2017 03:47 PM, Michael Palimaka wrote:
> The main risk of breakage of a package moving from testing to
> stable is always at build time anyway.

citation needed

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


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>> The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> citation needed
> 

Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
happily sign a third party public keyblock's UID using signature subkey
on smartcard, which results in useless signature that doesn't have any
effect, but the application builds fine.

This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

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


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

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>> The main risk of breakage of a package moving from testing to
>>> stable is always at build time anyway.
>>
>> citation needed
>>
> 
> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
> 
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
> certainly builds fine.
> 

Stop trolling - you know perfectly well that this sort of issue would
never ever be caught during arch testing. Nor should it be - it's called
*arch* testing for a reason.

Ensuring that a package's functionality is of merchantable quality is
the maintainer's responsibility (that's you!).

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/11/2017 04:21 PM, Michael Palimaka wrote:
> On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote:
>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>>> The main risk of breakage of a package moving from testing to
>>>> stable is always at build time anyway.
>>>
>>> citation needed
>>>
>>
>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>> happily sign a third party public keyblock's UID using signature subkey
>> on smartcard, which results in useless signature that doesn't have any
>> effect, but the application builds fine.
>>
>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>> certainly builds fine.
>>
> 
> Stop trolling - you know perfectly well that this sort of issue would
> never ever be caught during arch testing. Nor should it be - it's called
> *arch* testing for a reason.

That presumes that the maintainer is the one calling for the
stabilization, and it is not an automated procedure simply due to 30
days in ~arch. In this particular case, look for the number of bug
reports filed in Gentoo for the issue.

But the main risk is certainly not built testing, it is breaking
operational live stable systems. Nowhere was it claimed that the arch
testers are responsible for it, but it certainly doesn't coincide, at
any point, with "The main risk of breakage of a package moving from
testing to stable is always at build time anyway."

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


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Thomas Deutschmann]

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

>>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>>> happily sign a third party public keyblock's UID using signature subkey
>>> on smartcard, which results in useless signature that doesn't have any
>>> effect, but the application builds fine.
>>>
>>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>>> certainly builds fine.
>>>
>>
>> Stop trolling - you know perfectly well that this sort of issue would
>> never ever be caught during arch testing. Nor should it be - it's called
>> *arch* testing for a reason.

Question is what's more a problem: Having an outdated stable package
because nobody cared about stabilizing a new version (in most cases this
will end with a rushed stabilization once a security bug was fixed in
the package) or move a package in time from ~ARCH to ARCH and deal with
the fallout sometimes.

Having a real AT doing real arch testing work would be ideal. But face
it: We don't have the required man power. Let's try Debian's testing
approach and move packages to ARCH in time and don't wait for some
magical appearing bug reports because someone really tested a package in
~ARCH. Severe problems will be reported anyways...


-- 
Regards,
Thomas


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/12/2017 12:13 AM, Thomas Deutschmann wrote:
> Question is what's more a problem: Having an outdated stable package
> because nobody cared about stabilizing a new version (in most cases this
> will end with a rushed stabilization once a security bug was fixed in
> the package) or move a package in time from ~ARCH to ARCH and deal with
> the fallout sometimes.

Easy, keep the working package any time

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


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Marek Szuba]

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

On 2017-07-12 00:26, Kristian Fiskerstrand wrote:

>> Question is what's more a problem: Having an outdated stable
>> package because nobody cared about stabilizing a new version (in
>> most cases this will end with a rushed stabilization once a
>> security bug was fixed in the package) or move a package in time
>> from ~ARCH to ARCH and deal with the fallout sometimes.
> Easy, keep the working package any time
Seconded.

That said, let me repeat something I mentioned during the last
discussion about stabilisation procedures: for me at least the problem
with stabilisation has never really been with version upgrades, it's
with packages which do not even have a single stable version. For
reference, as of right now my "version bump" keyword file lists 8 atoms
(half of them referring to GIMP-2.9, which should not be stabilised
anyway) - whereas my "not in stable" file lists 61.

-- 
MS


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Mart Raudsepp]

Ühel kenal päeval, K, 12.07.2017 kell 00:13, kirjutas Thomas
Deutschmann:
> Let's try Debian's testing
> approach and move packages to ARCH in time and don't wait for some
> magical appearing bug reports because someone really tested a package
> in
> ~ARCH. Severe problems will be reported anyways...

You should realize that this is what was happening.
The problem is, that no-one is doing keywording and stabilization queue
got stalled due to stabilization bugs depending on keywording bugs as
is due process and proper bugzilla sanity.

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that
the maintainer is the one calling for the
> stabilization, and it is not an automated procedure simply due to 30
> days in ~arch. In this particular case, look for the number of bug
> reports filed in Gentoo for the issue.

All of the past automated stabilisation request initiatives did look for
open bugs against a package before filing any request.

> 
> But the main risk is certainly not built testing, it is breaking
> operational live stable systems.

I'm not sure exactly what you mean by this. Build testing is a process
and not a risk. When ebuilds are moved to stable, there's risk of
breakage at both build time and runtime.

Most runtime issues will either be known by the maintainer (who can then
block the stabilisation) or smoked out during the usual ~arch waiting
period.

Build time issues are more tricky. One of the reasons we have arch
testers is to ensure that something that built fine in ~arch will still
build fine on an otherwise stable system.

I've encountered a number of ebuilds marked stable that failed to build
on an all-stable system but built fine on an all-testing system. I've
never encountered a single ebuild that failed to run correctly on an
all-stable system but ran fine on an all-testing system.

I don't think it's practical to demand detailed runtime testing by an
arch tester for every stabilisation request (which we know doesn't
happen in practice anyway). There's also many packages where it may be
prudent to do more than just build testing.

I think the answer lies somewhere in the middle. We need to recognise
that we have very limited arch testing resources and focus them where it
will have the most impact. We have a "runtime testing required" field on
stable bugs now - let's use it, and let's be smart about it. Looking at
the current open bugs, I see some good examples where runtime testing
was requested (eg. sys-devel/gcc-config) and some examples where I
really question what value we get from an arch tester's time (eg.
app-text/htmldoc).

> Nowhere was it claimed that the arc
> testers are responsible for it, but it certainly doesn't coincide, at
> any point, with "The main risk of breakage of a package moving from
> testing to stable is always at build time anyway."
In a previous post you stated:
> currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
>
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

If it's not a stable candidate then why do you use this as an example
against build testing-based stabilisations? If there are known issues it
should never reach the arch teams in the first place.

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

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

On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> If it's not a stable candidate then why do you use this as an example
> against build testing-based stabilisations? If there are known issues it
> should never reach the arch teams in the first place.

This might be the crux of things, as long as automatic stabilization is
not triggered by some set of rules (e.g 30 days in ~arch) , and still
requires manual trigger by, preferably, the maintainer there is likely
no issue.

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


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[William Hubbs]

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

On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote:
> On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> > If it's not a stable candidate then why do you use this as an example
> > against build testing-based stabilisations? If there are known issues it
> > should never reach the arch teams in the first place.
> 
> This might be the crux of things, as long as automatic stabilization is
> not triggered by some set of rules (e.g 30 days in ~arch) , and still
> requires manual trigger by, preferably, the maintainer there is likely
> no issue.

This doesn't make sense. If I have to trigger automatic stabilization, it
isn't automatic any more.

I think with an appropriate set of rules automatic stabilization would
be fine. For example:

- foo-2.0 has been in ~arch for 30 days
- there are no open bugs against foo-2.0
- an older version of foo is stable
- all of the dependencies of foo-2.0 are stable

If those conditions are met, in theory there shouldn't be any problem
with stabilizing foo-2.0.

If foo-2.0 is not a stabilization candidate, there probably should be an
open bug in bugzilla stating why it isn't.

Thanks,

William


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Pacho Ramos]

El mié, 12-07-2017 a las 09:13 -0500, William Hubbs escribió:
> On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote:
> > On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> > > If it's not a stable candidate then why do you use this as an example
> > > against build testing-based stabilisations? If there are known issues it
> > > should never reach the arch teams in the first place.
> > 
> > This might be the crux of things, as long as automatic stabilization is
> > not triggered by some set of rules (e.g 30 days in ~arch) , and still
> > requires manual trigger by, preferably, the maintainer there is likely
> > no issue.
> 
> This doesn't make sense. If I have to trigger automatic stabilization, it
> isn't automatic any more.
> 
> I think with an appropriate set of rules automatic stabilization would
> be fine. For example:
> 
> - foo-2.0 has been in ~arch for 30 days
> - there are no open bugs against foo-2.0
> - an older version of foo is stable
> - all of the dependencies of foo-2.0 are stable
> 
> If those conditions are met, in theory there shouldn't be any problem
> with stabilizing foo-2.0.
> 
> If foo-2.0 is not a stabilization candidate, there probably should be an
> open bug in bugzilla stating why it isn't.
> 
> Thanks,
> 
> William
> 

Also please note that, when we were filling that automatic bug reports, there
were still an additional 60 days timeout (I think it was 60 days.. but I don't
remember if even 90 days) to allow maintainers to react. Only if nothing was
noted in relevant bug reports, arches were CCed automatically by the script 

Re: [gentoo-dev] Re: taking a break from arches stabilization

[James Le Cuirot]

On Tue, 11 Jul 2017 16:15:51 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
> > On 07/11/2017 03:47 PM, Michael Palimaka wrote:  
> >> The main risk of breakage of a package moving from testing to
> >> stable is always at build time anyway.  
> > 
> > citation needed
> >   
> 
> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature
> subkey on smartcard, which results in useless signature that doesn't
> have any effect, but the application builds fine.
> 
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
> certainly builds fine.

This is a good opportunity to remind ourselves what stable means. Are
we referring exclusively to our packaging or are upstream issues taken
into account too? 30 days seems like a reasonable time for any upstream
issues to be reported. Unfortunately security issues mean that new
releases sometimes get stabilised immediately. Ideally these releases
would carry just the security fixes but that isn't always the case.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:25 AM, James Le Cuirot wrote:
> On Tue, 11 Jul 2017 16:15:51 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> 
>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:  
>>>> The main risk of breakage of a package moving from testing to
>>>> stable is always at build time anyway.  
>>>
>>> citation needed
>>>   
>>
>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>> happily sign a third party public keyblock's UID using signature
>> subkey on smartcard, which results in useless signature that doesn't
>> have any effect, but the application builds fine.
>>
>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>> certainly builds fine.
> 
> This is a good opportunity to remind ourselves what stable means. Are
> we referring exclusively to our packaging or are upstream issues taken
> into account too? 30 days seems like a reasonable time for any upstream
> issues to be reported. Unfortunately security issues mean that new
> releases sometimes get stabilised immediately. Ideally these releases
> would carry just the security fixes but that isn't always the case.
> 

I think we should consider both our packaging as well as upstream
issues, and I agree that for most packages 30 days in ~arch is enough
time to smoke out upstream issues.

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Rich Freeman]

On Tue, Jul 11, 2017 at 10:35 AM, Michael Palimaka
<kensington@gentoo.org> wrote:
> On 07/12/2017 12:25 AM, James Le Cuirot wrote:
>> On Tue, 11 Jul 2017 16:15:51 +0200
>> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>>
>>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>>>> The main risk of breakage of a package moving from testing to
>>>>> stable is always at build time anyway.
>>>>
>>>> citation needed
>>>>
>>>
>>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>>> happily sign a third party public keyblock's UID using signature
>>> subkey on smartcard, which results in useless signature that doesn't
>>> have any effect, but the application builds fine.
>>>
>>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>>> certainly builds fine.
>>
>> This is a good opportunity to remind ourselves what stable means. Are
>> we referring exclusively to our packaging or are upstream issues taken
>> into account too? 30 days seems like a reasonable time for any upstream
>> issues to be reported. Unfortunately security issues mean that new
>> releases sometimes get stabilised immediately. Ideally these releases
>> would carry just the security fixes but that isn't always the case.
>>
>
> I think we should consider both our packaging as well as upstream
> issues, and I agree that for most packages 30 days in ~arch is enough
> time to smoke out upstream issues.
>

Agree.  Arch testing is really more of a sanity test.  I think there
is some value in runtime testing, but perhaps it is a bit of a luxury
compared to build testing.

It isn't going to detect obscure bugs.  The only way to do something
like that is to have an extensive testing protocol for each package,
and almost nobody can afford to do that let alone Gentoo.  Upstream
might be able to do it in some cases, though unfortunately not in our
environment.  To the extent that upstream supplies working automated
tests we can try to leverage those.

-- 
Rich

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:13 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>> The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> citation needed
> 

Based on my experience doing package testing in stabilisation work. Feel
free to provide citations (or complete sentences) to the contrary.

Re: [gentoo-dev] Re: taking a break from arches stabilization

[William Hubbs]

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

On Tue, Jul 11, 2017 at 11:47:32PM +1000, Michael Palimaka wrote:
> On 07/11/2017 11:06 PM, Rich Freeman wrote:
> > On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> >> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
> >>>
> >>> Even if such stabilization is allowed, there are unanswered
> >>> questions here:
> >>> - is following seciton 4.1 from wg recommendations is sufficient?
> >>> - should developer test each stabilization candidate on an
> >>> up-to-date stable setup?
> >>
> >> The guidelines from that document are ripped straight out of the
> >> devmanual and are a good starting point but rather generic. You can find
> >> some more detailed suggestions on things to consider while testing on
> >> the wiki: https://wiki.gentoo.org/wiki/Package_testing
> >>
> > 
> > I think that in practice arch teams don't do have the stuff on that
> > wiki page.  Maybe some people do, but back when I was an amd64 AT I
> > don't think anybody went testing multiple USE combinations for a
> > typical package.
> 
> Everything on that page is deliberately a suggestion only, and not
> necessarily specific to stabilisation testing.
> 
> In the end, we've never been able to reach any consensus on what exactly
> an arch tester should do. Personally, I think we should just switch to
> fully-automated, build-only testing for stabilistions unless the
> maintainer opts otherwise (something that largely happens in practice
> already). The main risk of breakage of a package moving from testing to
> stable is always at build time anyway.

I would not be opposed to this. As a maintainer, I am as guilty as the
next guy of not filing stable requests or not stabilizing packages.


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

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Sam Jorna (wraeth)]

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

On 12/07/17 03:16, William Hubbs wrote:
> On Tue, Jul 11, 2017 at 11:47:32PM +1000, Michael Palimaka wrote:
>> On 07/11/2017 11:06 PM, Rich Freeman wrote:
>>> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>>>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>>>
>>>>> Even if such stabilization is allowed, there are unanswered
>>>>> questions here:
>>>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>>>> - should developer test each stabilization candidate on an
>>>>> up-to-date stable setup?
>>>>
>>>> The guidelines from that document are ripped straight out of the
>>>> devmanual and are a good starting point but rather generic. You can find
>>>> some more detailed suggestions on things to consider while testing on
>>>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>>>
>>>
>>> I think that in practice arch teams don't do have the stuff on that
>>> wiki page.  Maybe some people do, but back when I was an amd64 AT I
>>> don't think anybody went testing multiple USE combinations for a
>>> typical package.
>>
>> Everything on that page is deliberately a suggestion only, and not
>> necessarily specific to stabilisation testing.
>>
>> In the end, we've never been able to reach any consensus on what exactly
>> an arch tester should do. Personally, I think we should just switch to
>> fully-automated, build-only testing for stabilistions unless the
>> maintainer opts otherwise (something that largely happens in practice
>> already). The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> I would not be opposed to this. As a maintainer, I am as guilty as the
> next guy of not filing stable requests or not stabilizing packages.

As the next guy, I also +1 this.

As is often explained in #gentoo, "stable" and "testing" for upstream
have a different meaning to "stable" and "testing" for Gentoo - in fact,
beyond ensuring it builds, any testing performed by a downstream distro
is additional testing to what upstream have already released.

I can understand the concern with automatically stabilising a package
that has some flaw affecting users, but the two things i see are that
upstream have already released said flawed package, and Gentoo simply
doesn't have the manpower to perform comprehensive runtime testing of
all packages.

If a maintainer is aware of a significant issue with a package that
should prevent it from being marked as stable, then a bug should be
filed acting as a block to the automated stabilisation. Users aware of
an issue are just as likely to file a bug as well, also preventing
stabilisation of packages with some known issue. Therefore packages with
known issues don't get stabilised automatically.

Similarly, if the maintainer believes more comprehensive testing should
be done (eg. for critical base-system packages) a note could be made
somewhere of that requirement (metadata.xml?), meaning significantly
reduced workload for people like ago (if the maintainer doesn't
stabilise it beforehand).
-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


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

Re: [gentoo-dev] taking a break from arches stabilization

[Jonas Stein]

Hi Agostino,

at first I want to thank you for the many contributions.
There should be a "thank you" parameter in emerge for every installed
package.
It would be so motivating to see that many user are glad about a special
package. One gets rarely feedback.

I understand your decision and perhaps it is the best you can do at the
moment. It could motivate others to contribute too.
I am sure, that the discussion about the 'minor' arches status is no
criticism about you.
I am looking forward to see you back after the break.

Best,
Jonas

Re: [gentoo-dev] taking a break from arches stabilization

[Mike Pagano]

On Mon, Jul 10, 2017 at 07:22:20PM +0200, Agostino Sarubbo wrote:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 
> -- 
> Agostino Sarubbo
> Gentoo Linux Developer
> 


Agostino as far as this maintainer is concerned you are totally wrong.
:) 

Its my bad that you have no idea how much I appreciate you stablizing kernels. I submit
stablereqs and almost say out loud "Ago, please do your thing".

It's my bad if I've never thanked you but I *do* depend on you.

Thanks for the time you spend on my "stuff".

Mike



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail     : mpagano@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index

Re: [gentoo-dev] taking a break from arches stabilization

[Matt Turner]

On Mon, Jul 10, 2017 at 10:22 AM, Agostino Sarubbo <ago@gentoo.org> wrote:
> Hi all.
>
> every time that I attach my tmux session to see what happens on irc, I always
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
>
> Now, since I work on these arches just to help, i.e. I don't have any business
> and I do non have any installation of those arches and the work I'm doing is
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no
> objections.
> I will take a break also from amd64 and x86...let's see how things will
> change.

I'm really sorry to hear that, but I agree that the best way to for
people to realize how valuable you are is to take a step back and let
them see the hole left by your absence.

For what it's worth, Jack Morgan was recently getting his sparc and
ia64 systems back up, but then decided to retire instead when he saw
all of the discussions about dropping the architectures he cares
about.

Thank you for all of the work you've done.

Re: [gentoo-dev] taking a break from arches stabilization

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:09 PM, Matt Turner <mattst88@gentoo.org> wrote:
>
> For what it's worth, Jack Morgan was recently getting his sparc and
> ia64 systems back up, but then decided to retire instead when he saw
> all of the discussions about dropping the architectures he cares
> about.
>

Honestly, I don't really get this sort of thing.  The reason arches
get dropped is because they mark things stable that they can't keep up
with.  If an arch never marked a package as stable nobody would be
bothered.  If they only marked a few critical packages as stable and
then kept up with them, again nobody would be bothered.  The conflict
comes in when an arch team marks packages as stable, but then doesn't
keep up with them.

Marking a package as stable is a two-way commitment.  When an arch
team marks a package as stable they make a promise to the maintainer
to stabilize updates in a timely manner.  In return the maintainer
promises to keep older versions around to suit the needs of the arch
team for the short time it takes to do these stabilizations.

When an arch team stabilizes something that they don't have time to
maintain then they're making a promise they can't keep, and the deal
breaks down.  Eventually the maintainers complain, and the council
ends up revoking the right of the arch team to hold the maintainers to
their side of the deal which has already been broken.

There are no bad guys here.  There is just a certain amount of work it
takes to make a stable arch viable, and it either happens or it
doesn't.  Most people who use Gentoo are tinkerers by nature.  All
things being equal we'd love to see every arch supported.  However,
this requires discipline on the part of the arch team, because
otherwise an arch that few people use starts impacting work for other
arches that many more use as maintainers get buried in old bugs.

-- 
Rich

Re: [gentoo-dev] taking a break from arches stabilization

[M. J. Everitt]

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

On 10/07/17 20:53, Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 3:09 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> For what it's worth, Jack Morgan was recently getting his sparc and
>> ia64 systems back up, but then decided to retire instead when he saw
>> all of the discussions about dropping the architectures he cares
>> about.
>>
> Honestly, I don't really get this sort of thing.  The reason arches
> get dropped is because they mark things stable that they can't keep up
> with.  If an arch never marked a package as stable nobody would be
> bothered.  If they only marked a few critical packages as stable and
> then kept up with them, again nobody would be bothered.  The conflict
> comes in when an arch team marks packages as stable, but then doesn't
> keep up with them.
>
> Marking a package as stable is a two-way commitment.  When an arch
> team marks a package as stable they make a promise to the maintainer
> to stabilize updates in a timely manner.  In return the maintainer
> promises to keep older versions around to suit the needs of the arch
> team for the short time it takes to do these stabilizations.
>
> When an arch team stabilizes something that they don't have time to
> maintain then they're making a promise they can't keep, and the deal
> breaks down.  Eventually the maintainers complain, and the council
> ends up revoking the right of the arch team to hold the maintainers to
> their side of the deal which has already been broken.
>
> There are no bad guys here.  There is just a certain amount of work it
> takes to make a stable arch viable, and it either happens or it
> doesn't.  Most people who use Gentoo are tinkerers by nature.  All
> things being equal we'd love to see every arch supported.  However,
> this requires discipline on the part of the arch team, because
> otherwise an arch that few people use starts impacting work for other
> arches that many more use as maintainers get buried in old bugs.
>
I dunno where you've been lately, Rich, but for most devs, would-be
devs, and observers .. there -are- no arch teams left .. just a few Arch
devs, or arch 'people' ..

This is why stabilisation, if not for individual package maintainers on
amd64, has become a joke, save for Ago's efforts, and recent efforts by
kensington to streamline the effort for the likes of ago with his bot,
and one or two other arch stabilisers (who I know exist, but not by name
or nick).

There is no, and has not been, in the time I've been involved with
Gentoo, any "pact" or "contract" between arch teams/devs and maintainers
whatsoever, anything is only ever done as a 'favour' or if someone
nudges the AT after the appropriate bug has been filed.

Keywording, unless for your own native arch, is a worse joke .. you have
to do it yourself .. there just aren't people with the less common
arches actively seeking packages out to keyword.

So, even for me, Thank You Ago for the packages you've kindly fixed
where I have nudged you, and also maekke on the few arm packages where
you have done the same. Your efforts are noted by some, pity not by others.


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

Re: [gentoo-dev] taking a break from arches stabilization

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>
> I dunno where you've been lately, Rich, but for most devs, would-be
> devs, and observers .. there -are- no arch teams left .. just a few Arch
> devs, or arch 'people' ..

Obviously.

I was describing how the arch team process worked when there were arch teams.

The fact that most arch teams are fairly defunct is the reason that
stable keywords have steadily been dropped.

>
> This is why stabilisation, if not for individual package maintainers on
> amd64, has become a joke, save for Ago's efforts, and recent efforts by
> kensington to streamline the effort for the likes of ago with his bot,
> and one or two other arch stabilisers (who I know exist, but not by name
> or nick).

Sure.  If nobody is maintaining stable keywords on an arch, then there
shouldn't be stable keywords on that arch, unless the stable keywords
are used for a different purpose and maintainers are free to downgrade
them at any time.

>
> There is no, and has not been, in the time I've been involved with
> Gentoo, any "pact" or "contract" between arch teams/devs and maintainers
> whatsoever, anything is only ever done as a 'favour' or if someone
> nudges the AT after the appropriate bug has been filed.
>

As a formal documented arrangement, no "pact" or "contract" has ever
existed between arch teams and maintainers.

However, this is basically the implicit basis for the system and the
consequence of our documented policies, such as the policy that
maintainers may not remove the highest stable version of a package.
These policies make no sense unless arch teams are held to a standard
of timely stabilization.

There has never been a need to document such a "contract" because the
Council has been maintaining it all along.  When people complain that
an arch team is unresponsive, the Council removes stable support for
the arch.

I'm describing reality here, not written policies.

-- 
Rich

Re: [gentoo-dev] taking a break from arches stabilization

[Andrew Savchenko]

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

On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> > This is why stabilisation, if not for individual package maintainers on
> > amd64, has become a joke, save for Ago's efforts, and recent efforts by
> > kensington to streamline the effort for the likes of ago with his bot,
> > and one or two other arch stabilisers (who I know exist, but not by name
> > or nick).
> 
> Sure.  If nobody is maintaining stable keywords on an arch, then there
> shouldn't be stable keywords on that arch, unless the stable keywords
> are used for a different purpose and maintainers are free to downgrade
> them at any time.

I'm confused, again. I can't find any official policy regarding
dekeywording packages from stable to testing.

Can developers remove packages from stable on whim or only on
certain conditions? Under what conditions exactly? Should arch
teams be notified on such actions? Or even requested permissions
from?

IMO a valid reason to remove from stable is arch team failure to
stabilize this package for a long time. But how long? Month, two,
half a year?

What to do with reverse dependencies? Should they be dropped to
~arch altogether with the package in question? Or should their
maintainers be given a warning before? How long to wait after?
One more month or two, another half a year?

Maybe I should move this discussion to the wg_stable ML, but
there are few people there and gentoo-dev has much wider coverage.

A well established arch -> ~arch policy should help to keep number
of stable packages sane and manageable for arch teams. A well
established policy of doing ~arch -> arch by devs themselves will
help to lower load on arch teams as well. So for everyone be happy
(arch teams by keeping them stable and manageable, devs by solving
stabilization requests in a sane time) we need good policies!

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] taking a break from arches stabilization

[Rich Freeman]

On Mon, Jul 10, 2017 at 7:54 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote:
>> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>> > This is why stabilisation, if not for individual package maintainers on
>> > amd64, has become a joke, save for Ago's efforts, and recent efforts by
>> > kensington to streamline the effort for the likes of ago with his bot,
>> > and one or two other arch stabilisers (who I know exist, but not by name
>> > or nick).
>>
>> Sure.  If nobody is maintaining stable keywords on an arch, then there
>> shouldn't be stable keywords on that arch, unless the stable keywords
>> are used for a different purpose and maintainers are free to downgrade
>> them at any time.
>
> I'm confused, again. I can't find any official policy regarding
> dekeywording packages from stable to testing.

I tried to find the best documented answers I could to your questions,
but as has been mentioned our documentation around what really goes on
with arch keywording today is poor.  This was one of the drivers for
the stable-wg.

>
> Can developers remove packages from stable on whim or only on
> certain conditions? Under what conditions exactly? Should arch
> teams be notified on such actions? Or even requested permissions
> from?

"If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
pending STABLEREQ, for 90 days with archs CCed and otherwise ready
to be stabilized, the maintainer can remove older versions of
the package at their discretion. A package is considered ready to be
stabilized if it has been in the tree for 30 days, and has no known
major flaws on arches that upstream considers supported."  [1]

Note that this only pertains to stable arches.  For a non-stable arch
there are no restrictions on the removal of the last stable version as
far as I'm aware.

>
> IMO a valid reason to remove from stable is arch team failure to
> stabilize this package for a long time. But how long? Month, two,
> half a year?

90 days, per the above.

>
> What to do with reverse dependencies? Should they be dropped to
> ~arch altogether with the package in question? Or should their
> maintainers be given a warning before? How long to wait after?
> One more month or two, another half a year?

They need to be dropped to ~arch as well, at the same time the stable
version is removed.  In practice this is painful and this was one of
the drivers for the stable-wg.  The 90 day relief the Council provided
did not completely solve this problem.

>
> A well established arch -> ~arch policy should help to keep number
> of stable packages sane and manageable for arch teams. A well
> established policy of doing ~arch -> arch by devs themselves will
> help to lower load on arch teams as well. So for everyone be happy
> (arch teams by keeping them stable and manageable, devs by solving
> stabilization requests in a sane time) we need good policies!
>

A big problem historically is that it is much easier to go from
~arch->arch than it is to go from arch->~arch.  I think well-meaning
users of minor arches enthusiastically deal with STABLEREQ bugs so
that there are more stable packages available on the arch.  However,
once whatever itch they had was scratched they don't necessarily keep
up with future requests on the same package, causing the package to
become stale.

The intent of the 90 day policy was to make it easier to drop keywords
back.  However, without scripts/etc to make this simple for
maintainers most don't actually take advantage of this opportunity.

It has also been rightly pointed out that this is a bit of a chaotic
solution to the problem.  If the minor arch doesn't keep up with
stable keywords on a core dependency somebody running one of these
scripts might remove almost all the stable keywords for that arch in
the entire tree.  The counter argument is that these core dependencies
are the ones the arch team should be paying the most attention to, and
if they spent more time stabilizing boring libraries and less time
stabilizing applications maybe the problem wouldn't exist.

GLEP 40 has been mentioned and this is an interesting policy and the
way it is being mentioned makes it moreso.  At the time it was written
everything contained within was already being done on all the arches
EXCEPT x86, where maintainers were doing their own stabilizations.
Since the amd64 team was viewed as a model of best practice at the
time the purpose of the GLEP was to make x86 the same as the other
arches.  Since then manpower and interests have changed, and amd64
initially just gave individual maintainers a go-ahead to do their own
stabilizations and then eventually a blanket authorization for anybody
to do so.  Ironically this makes x86 the only arch with a documented
arch testing policy in a GLEP.

I can't find any documentation of the amd64 exception.  I think it
goes all the way back to kingtaco.


1 - https://projects.gentoo.org/council/meeting-logs/20131119-summary.txt

-- 
Rich

Re: [gentoo-dev] taking a break from arches stabilization

[Aaron Bauman]

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

On Monday, July 10, 2017 1:22:20 PM EDT Agostino Sarubbo wrote:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I
> always see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any
> business and I do non have any installation of those arches and the work
> I'm doing is not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no
> objections.
> I will take a break also from amd64 and x86...let's see how things will
> change.

Your efforts have not gone unnoticed from my perspective.  You were always the 
one to do the bulk of the work on most arches.

I don't believe that you going on a break will fix anything either.  The bottom 
line is that you cannot do it alone and maintain the state of stable tree that 
is expected by our users and fellow developers.

If you cannot accept that your work alone is not enough then I would ask you 
reevaluate the importance of those minor arches.  The facts are evident and 
they are a hinderance to the overall state of the distribution, in my opinion. 
There is more than just keywording and stabilization at stake here.  Security 
is a major factor as well.

Surely, you will be missed during your break and I hope you find some time to 
recuperate.  Thank you for all the work you have done and surely will do in 
the future.

-Aaron

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

Re: [gentoo-dev] taking a break from arches stabilization

[Lars Wendler]

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

On Mon, 10 Jul 2017 19:22:20 +0200 Agostino Sarubbo wrote:

>Hi all.
>
>every time that I attach my tmux session to see what happens on irc, I
>always see the same discussion about the 'minor' arches status.
>Since I joined gentoo(2011) I worked on all arches except hppa, I put
>more effort in amd64 and less where I saw other people work on it
>(arm,alpha) But every time the magic phrase is that those arches are
>unmaintained.
>
>Now, since I work on these arches just to help, i.e. I don't have any
>business and I do non have any installation of those arches and the
>work I'm doing is not appreciated at all I decided to stop for now.
>If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
>objections.
>I will take a break also from amd64 and x86...let's see how things
>will change.
>

Hi Agostino,

this is very sad news but I'm not really surprised about your
decision. It seems like every arch except amd64 and to some point
arm(64) seems to be the target of massive vilification.

On behalf of base-system team let me thank you for your awesome
stabilization work. I hope you will return at some point when your
frustration level has sufficiently decreased.

Kind regards
Lars

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

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

Re: [gentoo-dev] taking a break from arches stabilization

[Agostino Sarubbo]

Thanks all for the 'appreciation'.

I'd like to remember that I'm not going away nor I'm retiring, I will just 
avoid to touch stabilizations, unless the stable package is part of my 
interest.

I'd like also to reminder that in the past I monitored the bugs via the 
bugzilla UI, and in the recent past I used the getatoms script to monitor the 
load for each arch:

for ARCH in alpha amd64 arm ia64 ppc ppc64 sparc x86
do
        echo "${ARCH}"

        python \
                /root/getatoms.py \
                -a "${ARCH}" \
                --stablereq \
                --no-depends \
                --all-bugs > /dev/null 2>&1

        grep "=" /etc/portage/package.keywords/test | wc -l
        echo -ne "\n\n"
done


Actually we have a result like this:

alpha                                                                                                                                                
82                                                                                                                                                   
                                                                                                                                                                                                                                                                                                          
amd64                                                                                                                                                
99                                                                                                                                                   
                                                                                                                                                                                                                                                                                                          
arm                                                                                                                                                  
154                                                                                                                                                  
                                                                                                                                                                                                                                                                                                          
ia64                                                                                                                                                 
5                                                                                                                                                    
                                                                                                                                                                                                                                                                                                          
ppc                                                                                                                                                  
64                                                                                                                                                   
                                                                                                                                                                                                                                                                                                          
ppc64                                                                                                                                                
64                                                                                                                                                   
                                                                                                                                                                                                                                                                                                          
sparc                                                                                                                                                
20                                                                                                                                                   
                                                                                                                                                                                                                                                                                                          
x86                                                                                                                                                  
96

Actually the result is increased by the large number of packages in the 
gstreamer stablereq.
I worked daily-by-daily for amd64/x86 and occasionally for an arch. I always 
picked up the arch which have more bugs from the above list.
A always assured that there wasn't an arch with > 200 bugs.
Unfortunately I don't have time to work on the arch-specific. But if I can 
help with 7 arches you shouldn't bother :)
On the other side, I respect and 'share' the point of view of the maintainer 
which has some arch-specific bugs freezed with noone that take care of.
It is a fact that for those arches there are few users, so to improve the 
situation we can:
1) Don't file keywordreq, since noone work on them. File directly stablereq.
2) Reduce the number of the stable packages on those arches
3) Make a more visible list( like a list here in term of 
visibility:https://qa-reports.gentoo.org/output/gentoo-ci/output.html)  of the 
arches-dependent bugs so that everyone can contribute to maintain alive the 
exotic arches.

If is not our interest to maintain those alive, just ignore my proposal.


-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-dev] taking a break from arches stabilization

[Daniel Campbell]

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

On 07/10/2017 10:22 AM, Agostino Sarubbo wrote:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 
Thanks for your efforts in stabilization. I try to make it a point to
thank people like you and Toralf since stabilization and arch testing
are both time-consuming, and probably frustrating to get the tooling
correct.

Take some time off! I'm sure Gentoo won't implode. :)

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


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

Re: [gentoo-dev] taking a break from arches stabilization

[Sergey Popov]

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

10.07.2017 20:22, Agostino Sarubbo пишет:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 

It's sad, i wish you will return to this - you are doing great job for
all arches! I know how tedious this work could be - i was active arch
team member some time ago(but not anymore :-().

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead


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