[gentoo-dev] dropping redundant stable keywords

[gentoo-dev] dropping redundant stable keywords

["Paweł Hajdan, Jr."]

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

Here's a proposal that may address concerns from the long "rfc:
revisiting our stabilization policy" thread.

It seems at least one of the problems is that with old ebuilds being
stable on slow arches but not the more recent ebuilds, it is a
maintenance burden to keep supporting the old ebuilds even on fast
arches where it's still stable.

Why not allow maintainers to drop redundant stable and even ~arch
keywords from their packages?

Then these old ebuilds will stay with _only_ slow arch keywords. If they
were working back then, they will continue to work now, since there are
not that many changes to break things as opposed to faster-moving arches.

What do you think? Please let me know if I should clarify this.

Paweł


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

Re: [gentoo-dev] dropping redundant stable keywords

[Alex Xu]

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

On 28/01/14 11:33 AM, "Paweł Hajdan, Jr." wrote:
> Here's a proposal that may address concerns from the long "rfc:
> revisiting our stabilization policy" thread.
> 
> It seems at least one of the problems is that with old ebuilds being
> stable on slow arches but not the more recent ebuilds, it is a
> maintenance burden to keep supporting the old ebuilds even on fast
> arches where it's still stable.
> 
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
> 
> Then these old ebuilds will stay with _only_ slow arch keywords. If they
> were working back then, they will continue to work now, since there are
> not that many changes to break things as opposed to faster-moving arches.
> 
> What do you think? Please let me know if I should clarify this.
> 
> Paweł
> 

I thought there was a general consensus that only the latest stable on a
given arch is considered actually-stable.


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

Re: [gentoo-dev] dropping redundant stable keywords

[Tom Wijsman]

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

On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?

We already do that to a great extent; only removing the last keyword
present is a bad idea, because in that case the package would need to
be masked to indicate its brokenness. Otherwise repoman will warn... ;)

> Then these old ebuilds will stay with _only_ slow arch keywords.

We're already doing this too, that's not the problem in that thread; the
problem is that ebuilds stay behind (regardless of dropping keywords),
because they block progress as well as require extra maintenance.

> If they were working back then, they will continue to work now, since
> there are not that many changes to break things as opposed to
> faster-moving arches.

That's a generalization, I can just as well claim here that if a change
does break something that it takes longer for that change to be fixed;
especially when we're talking about slow architectures.

-- 
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] dropping redundant stable keywords

[Jeroen Roovers]

On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?

This is standard practice already.


     jer

Re: [gentoo-dev] dropping redundant stable keywords

[Rich Freeman]

On Tue, Jan 28, 2014 at 12:23 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Tue, 28 Jan 2014 08:33:05 -0800
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
>
>> Why not allow maintainers to drop redundant stable and even ~arch
>> keywords from their packages?
>
> This is standard practice already.

If there is still pain then maybe we need to re-communicate this, or clarify.

To me if a package is in the tree and is outdated, but kept for only
the benefit of a few lagging archs, then maintainers can close bugs as
WONTFIX if they don't pertain to newer versions.  If that is the case
then there is no cost to keeping the old packages around.

The main concern is around maintenance burden.  The only way to reduce
maintenance burden is to do less maintenance (I haven't heard any
suggestions that will somehow make bugs go away).  If maintainers are
doing more maintenance than they are required to do, then simply
reinforcing existing policy could solve the problem.  We just need to
align around expectations.

Rich

Re: [gentoo-dev] dropping redundant stable keywords

[Sergey Popov]

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

28.01.2014 20:33, "Paweł Hajdan, Jr." пишет:
> Here's a proposal that may address concerns from the long "rfc:
> revisiting our stabilization policy" thread.
> 
> It seems at least one of the problems is that with old ebuilds being
> stable on slow arches but not the more recent ebuilds, it is a
> maintenance burden to keep supporting the old ebuilds even on fast
> arches where it's still stable.
> 
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
> 
> Then these old ebuilds will stay with _only_ slow arch keywords. If they
> were working back then, they will continue to work now, since there are
> not that many changes to break things as opposed to faster-moving arches.
> 
> What do you think? Please let me know if I should clarify this.
> 
> Paweł
> 

We have some discussion about stabilization practices on past QA team
meeting yesterday. Please, bear with us.

-- 
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: dropping redundant stable keywords

[Steven J. Long]

Rich Freeman wrote:
> Jeroen Roovers wrote:
> > "Paweł Hajdan" wrote:
> >
> >> Why not allow maintainers to drop redundant stable and even ~arch
> >> keywords from their packages?
> >
> > This is standard practice already.
> 
> If there is still pain then maybe we need to re-communicate this, or
> clarify.
> 
> To me if a package is in the tree and is outdated, but kept for only
> the benefit of a few lagging archs, then maintainers can close bugs as
> WONTFIX if they don't pertain to newer versions.  If that is the case
> then there is no cost to keeping the old packages around.
> 
> The main concern is around maintenance burden.  The only way to reduce
> maintenance burden is to do less maintenance (I haven't heard any
> suggestions that will somehow make bugs go away).  If maintainers are
> doing more maintenance than they are required to do, then simply
> reinforcing existing policy could solve the problem.  We just need to
> align around expectations.

Closing those bugs as WONTFIX is more work, and in some cases the bugs
would be justified, if the user is on the slow arch in question. The
arguments and headaches at the user, bug and AT sides are causing more
work (or detracting from real work) too.

I don't think it should be general policy to drop stable keywords; as
someone said, the latest stable in the tree /is/ the stable one, and
there's no real point in adding work, *unless* the maintainer
actually wants to drop the ebuild, but cannot due to the holdup with
slower archs.

Just keep the old ebuilds as useful metadata, subject to the usual
version-control cycle, but iff it's causing you problems and you want
to drop it, mark it with: "-* slowe rarch" so we can script off it and
automate bug-handling etc. so your life is easier, as well as the
archs in question (and their users.)

Regards,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: dropping redundant stable keywords

[Tom Wijsman]

On Mon, 3 Feb 2014 06:25:24 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Closing those bugs as WONTFIX is more work, and in some cases the bugs
> would be justified, if the user is on the slow arch in question.

They are less work; since it lets the slower arches move their work to
bugs of important packages that need their attention, instead of bugs
of non-important packages were the stabilization isn't really necessary.

> The arguments and headaches at the user, bug
> and AT sides are causing more work (or detracting from real work) too.

Yes, the less work that we can do, the more work the user has to do as
a natural consequence; discussions like these are there to prevent
those headaches way in advance, as we can proper adapt and/or respond
to the situation. And if needed, bring out news such that the user is
well informed. Not sure which argumentation this is about though.

> I don't think it should be general policy to drop stable keywords; as
> someone said, the latest stable in the tree /is/ the stable one, and
> there's no real point in adding work, *unless* the maintainer
> actually wants to drop the ebuild, but cannot due to the holdup with
> slower archs.

The policy[1] that was formed on this requires this to be at least 90
days after the stabilization for the new version was filed and the arch
team doesn't respond within that time; the old stable version is even
much older than that, if you assume it was stabilized after 30 days,
we're talking about versions that are at least 4 months old.

Knowing not everyone follows stabilization of their packages that well,
you can add a bit more time to that. If an arch team can't stabilize a
package every half year, then one can't expect that package to remain
stable; but in general, yes, dropping it unconditionally would be bad.

 [1] Quality Assurance / Policies / Dropping Stable KEYWORDs
 https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs

> Just keep the old ebuilds as useful metadata, subject to the usual
> version-control cycle, but iff it's causing you problems and you want
> to drop it, mark it with: "-* slowe rarch" so we can script off it and
> automate bug-handling etc. so your life is easier, as well as the
> archs in question (and their users.)

As stated before, -* means something way different; it is a suggestion
that does not fit this thread. Like before, did you mean "slower arch"?

And even if you did, we have then already been using this practice for
a long while; it is different from the problem that was brought up here.

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

[gentoo-dev] Re: Re: dropping redundant stable keywords

[Steven J. Long]

Tom Wijsman wrote:
> "Steven J. Long" wrote:
> 
> > Closing those bugs as WONTFIX is more work, and in some cases the bugs
> > would be justified, if the user is on the slow arch in question.
> 
> They are less work; since it lets the slower arches move their work to
> bugs of important packages that need their attention, instead of bugs
> of non-important packages were the stabilization isn't really necessary.

Huh? The slower arch is not keeping up with stabilisation. How can the
stabilisation suddenly be unnecessary? If it is not needed, there is no
problem, and we wouldn't be having this discussion.

Much better for the arch in question to field the bug, than tell the
user there is no problem, and we don't care. That way you can get the
user involved in stabilisation and AT via that bug, instead of turning
them away with priggishness.

No wonder you're short of manpower.

> > The arguments and headaches at the user, bug
> > and AT sides are causing more work (or detracting from real work) too.
> 
> Yes, the less work that we can do, the more work the user has to do as
> a natural consequence; discussions like these are there to prevent
> those headaches way in advance, as we can proper adapt and/or respond
> to the situation. And if needed, bring out news such that the user is
> well informed. Not sure which argumentation this is about though.

Perfectly simple: instead of having this row repeatedly, or borking
archs, let's use the solution proposed by the ARM AT: provide a technical
reason why it won't work, rather than a conceptual problem with the
"hack".

The history of computing is littered with hacks that turned out to shed
new light on a problem: it's called exploring the problem domain. It's
only when you have idiomatic knowledge of the language/tools *and* the
specific domain, that you can envision oddball solutions and more
importantly _know_ that they will work (perhaps with a bit of tweaking.)

<snip>
>  [1] Quality Assurance / Policies / Dropping Stable KEYWORDs
>  https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs

That's not a policy: it's a two-line statement of intent. Further, the
solution steev brought up is much much better than simply dropping the
ebuild.

> > Just keep the old ebuilds as useful metadata, subject to the usual
> > version-control cycle, but iff it's causing you problems and you want
> > to drop it, mark it with: "-* slowe rarch" so we can script off it and
> > automate bug-handling etc. so your life is easier, as well as the
> > archs in question (and their users.)
> 
> As stated before, -* means something way different; it is a suggestion
> that does not fit this thread. Like before, did you mean "slower arch"?

No, it's an example, like foo bar, but indicating that we're talking
about slower archs, and likely more than one in some instances. As before
did you mean to raise a technical objection with clear explanation of
what and why it would break?

> And even if you did, we have then already been using this practice for
> a long while; it is different from the problem that was brought up here.

Yes, yes, you can keep going on about the "conceptual difficulty", but
the simple fact is the solution works, or it wouldn't have been raised.
steev's idiomatic knowledge and solution wins, IMNSHO.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 4 Feb 2014 21:03:20 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Tom Wijsman wrote:
> 
> > They are less work; since it lets the slower arches move their work
> > to bugs of important packages that need their attention, instead of
> > bugs of non-important packages were the stabilization isn't really
> > necessary.
> 
> Huh? The slower arch is not keeping up with stabilisation. How can the
> stabilisation suddenly be unnecessary? If it is not needed, there is
> no problem, and we wouldn't be having this discussion.

It is still necessary, as clear from the difference in importance.

> Much better for the arch in question to field the bug, than tell the
> user there is no problem, and we don't care. That way you can get the
> user involved in stabilisation and AT via that bug, instead of turning
> them away with priggishness.

Problems should be visible instead of hidden, as well as resolved. A
move in work means a move in work, further implications are yours...

> > > The arguments and headaches at the user, bug
> > > and AT sides are causing more work (or detracting from real work)
> > > too.
> > 
> > Yes, the less work that we can do, the more work the user has to do
> > as a natural consequence; discussions like these are there to
> > prevent those headaches way in advance, as we can proper adapt
> > and/or respond to the situation. And if needed, bring out news such
> > that the user is well informed. Not sure which argumentation this
> > is about though.
> 
> Perfectly simple: instead of having this row repeatedly, or borking
> archs, let's use the solution proposed by the ARM AT: provide a
> technical reason why it won't work, rather than a conceptual problem
> with the "hack".

Searching for such technical reasoning is a leeway for hacking & hoping.

Solutions were provided, a policy has been made; we are exactly
avoiding to row repeatedly, and this is yet another solution I propose:

Provide a technical reason why it will work?

You further demonstrate this solution that I propose we should use:

> The history of computing is littered with hacks that turned out to
> shed new light on a problem: it's called exploring the problem
> domain. It's only when you have idiomatic knowledge of the
> language/tools *and* the specific domain, that you can envision
> oddball solutions and more importantly _know_ that they will work
> (perhaps with a bit of tweaking.)

It is called prototyping.

> <snip>
> >  [1] Quality Assurance / Policies / Dropping Stable KEYWORDs
> >  https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs
> 
> That's not a policy: it's a two-line statement of intent. 

It is policy, as it permits implementation of that intent; at the very
least, it is a policy change that allows you something you were disallowed.

> Further, the solution steev brought up is much much better than
> simply dropping the ebuild.
>
> > > Just keep the old ebuilds as useful metadata, subject to the usual
> > > version-control cycle, but iff it's causing you problems and you
> > > want to drop it, mark it with: "-* slowe rarch" so we can script
> > > off it and automate bug-handling etc. so your life is easier, as
> > > well as the archs in question (and their users.)
> > 
> > As stated before, -* means something way different; it is a
> > suggestion that does not fit this thread. Like before, did you mean
> > "slower arch"?
> 
> No, it's an example, like foo bar, but indicating that we're talking
> about slower archs, and likely more than one in some instances. As
> before did you mean to raise a technical objection with clear
> explanation of what and why it would break?
>
> > And even if you did, we have then already been using this practice
> > for a long while; it is different from the problem that was brought
> > up here.
> 
> Yes, yes, you can keep going on about the "conceptual difficulty", but
> the simple fact is the solution works, or it wouldn't have been
> raised. steev's idiomatic knowledge and solution wins, IMNSHO.

"The -* keyword is special. It is used to indicate package versions
which are not worth trying to test on unlisted archs." [1]

You can keep rehashing about "winning", but all it does is break policy.

 [1]: http://devmanual.gentoo.org/keywording

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

On Wed, 2014-02-05 at 01:08 +0100, Tom Wijsman wrote:

> "The -* keyword is special. It is used to indicate package versions
> which are not worth trying to test on unlisted archs." [1]
> 
> You can keep rehashing about "winning", but all it does is break policy.
> 
>  [1]: http://devmanual.gentoo.org/keywording
> 

I would say, this is exactly that.  We are saying it is not for use on
any but the listed arch, so don't try to.  No?  Or are we going to hinge
this all on the definition of "test" in that statement?

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 04 Feb 2014 18:23:28 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> On Wed, 2014-02-05 at 01:08 +0100, Tom Wijsman wrote:
> 
> > "The -* keyword is special. It is used to indicate package versions
> > which are not worth trying to test on unlisted archs." [1]
> > 
> > You can keep rehashing about "winning", but all it does is break
> > policy.
> > 
> >  [1]: http://devmanual.gentoo.org/keywording
> > 
> 
> We are saying it is not for use on any but the listed arch, so don't
> try to.  No?  Or are we going to hinge this all on the definition of
> "test" in that statement?

It has already been tested; and thus, it would be a policy breach to use
-* over dropping a keyword. It is also worth trying, when man power
allows; or are we going to hinge on the definition of "worth" as well?

Looks like we are playing word games; I'll pick one, "unlisted" archs.

The appropriate way to say that "it is not for use" on a particular
arch is to mask the package, a less appropriate way which is still
valid but less appreciated is to remove the keyword; but using the
wording "not for use" as "not worth trying to test" is bending policy.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

On Wed, 2014-02-05 at 02:07 +0100, Tom Wijsman wrote:
> On Tue, 04 Feb 2014 18:23:28 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > On Wed, 2014-02-05 at 01:08 +0100, Tom Wijsman wrote:
> > 
> > > "The -* keyword is special. It is used to indicate package versions
> > > which are not worth trying to test on unlisted archs." [1]
> > > 
> > > You can keep rehashing about "winning", but all it does is break
> > > policy.
> > > 
> > >  [1]: http://devmanual.gentoo.org/keywording
> > > 
> > 
> > We are saying it is not for use on any but the listed arch, so don't
> > try to.  No?  Or are we going to hinge this all on the definition of
> > "test" in that statement?
> 
> It has already been tested; and thus, it would be a policy breach to use
> -* over dropping a keyword. It is also worth trying, when man power
> allows; or are we going to hinge on the definition of "worth" as well?
> 
> Looks like we are playing word games; I'll pick one, "unlisted" archs.
> 
> The appropriate way to say that "it is not for use" on a particular
> arch is to mask the package, a less appropriate way which is still
> valid but less appreciated is to remove the keyword; but using the
> wording "not for use" as "not worth trying to test" is bending policy.
> 

Alright, well, I've tried my best, I give up.  Instead of having
something working we should just remove ebuilds of working packages.

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 04 Feb 2014 19:35:22 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> Alright, well, I've tried my best, I give up.  Instead of having
> something working we should just remove ebuilds of working packages.

s/should/could/ s/ebuilds/stable keyword or last stable version/

It is at the maintainer's discretion; and such decision is to make
it possible for a maintainer to move on when he or she can no longer
guarantee a working ebuild, to stop being progress-blocked by it.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
> On Tue, 04 Feb 2014 19:35:22 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > Alright, well, I've tried my best, I give up.  Instead of having
> > something working we should just remove ebuilds of working packages.
> 
> s/should/could/ s/ebuilds/stable keyword or last stable version/
> 
> It is at the maintainer's discretion; and such decision is to make
> it possible for a maintainer to move on when he or she can no longer
> guarantee a working ebuild, to stop being progress-blocked by it.
> 

You know what - this is pure and utter bullshit.  Keeping it around for
"slower" arches does NOT block progress.  I have intimate knowledge with
what ACTUALLY happens when people pull this bullshit - and that is a
system that I can no longer actually work on.  And instead of working
towards a fix that actually works for people who are ACTUALLY affected
by the shitty policy, you hide behind definitions and pedantry.  

I'm now going to take a break from Gentoo development because this
thread has seriously caused my blood to boil based on comments from the
peanut gallery (you) where things don't actually affect your day to day
work, but your actions do affect mine.

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Matt Turner]

On Tue, Feb 4, 2014 at 7:15 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
> On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
>> On Tue, 04 Feb 2014 19:35:22 -0600
>> Steev Klimaszewski <steev@gentoo.org> wrote:
>>
>> > Alright, well, I've tried my best, I give up.  Instead of having
>> > something working we should just remove ebuilds of working packages.
>>
>> s/should/could/ s/ebuilds/stable keyword or last stable version/
>>
>> It is at the maintainer's discretion; and such decision is to make
>> it possible for a maintainer to move on when he or she can no longer
>> guarantee a working ebuild, to stop being progress-blocked by it.
>>
>
> You know what - this is pure and utter bullshit.  Keeping it around for
> "slower" arches does NOT block progress.  I have intimate knowledge with
> what ACTUALLY happens when people pull this bullshit - and that is a
> system that I can no longer actually work on.  And instead of working
> towards a fix that actually works for people who are ACTUALLY affected
> by the shitty policy, you hide behind definitions and pedantry.
>
> I'm now going to take a break from Gentoo development because this
> thread has seriously caused my blood to boil based on comments from the
> peanut gallery (you) where things don't actually affect your day to day
> work, but your actions do affect mine.

I'm with you. I've drafted and thrown away so many replies to Tom in
this thread. Thanks for putting up with it, but it's a huge waste of
your time.

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 04 Feb 2014 21:15:47 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
> > On Tue, 04 Feb 2014 19:35:22 -0600
> > Steev Klimaszewski <steev@gentoo.org> wrote:
> > 
> > > Alright, well, I've tried my best, I give up.  Instead of having
> > > something working we should just remove ebuilds of working
> > > packages.
> > 
> > s/should/could/ s/ebuilds/stable keyword or last stable version/
> > 
> > It is at the maintainer's discretion; and such decision is to make
> > it possible for a maintainer to move on when he or she can no longer
> > guarantee a working ebuild, to stop being progress-blocked by it.
> > 
> 
> You know what - this is pure and utter bullshit.

Why is this pure and utter bullshit?

> Keeping it around for "slower" arches does NOT block progress.

Why is keeping it around for "slower" arches not blocking progress?

> I have intimate knowledge with what ACTUALLY happens when people pull
> this bullshit - and that is a system that I can no longer actually
> work on.

That is also what happens when a maintainer keeps around old versions,
as well as old bugs and support for those old versions; as by doing so,
the attention towards newer versions is lost which causes much huger
breakage than the one you have just brought up. Manpower is limited.

> And instead of working towards a fix that actually works
> for people who are ACTUALLY affected by the shitty policy, you hide
> behind definitions and pedantry.  

Why do you think this about the current and/or suggested solution(s)?

> I'm now going to take a break from Gentoo development because this
> thread has seriously caused my blood to boil based on comments from
> the peanut gallery (you) where things don't actually affect your day
> to day work, but your actions do affect mine.

Why? How and why are your actions affected by the QA team's actions?

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 4 Feb 2014 19:28:28 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> I've drafted and thrown away so many replies to Tom in this thread.

What do you want to tell us about this thread?

> Thanks for putting up with it, but it's a huge waste of your time.

Why? This discussion has a goal which we are trying to fulfill; if the
current solution the QA team has formed is insufficient, feel free to
let us know why such that we can reshape it to fit the situation better.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Rich Freeman]

On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
>
> You know what - this is pure and utter bullshit.  Keeping it around for
> "slower" arches does NOT block progress.  I have intimate knowledge with
> what ACTUALLY happens when people pull this bullshit - and that is a
> system that I can no longer actually work on.

It isn't like deleted ebuilds magically disappear.  You can always dig
them out of CVS and stick them in an overlay.  It just isn't the
maintainer's problem.  Any dev can also co-maintain a package and keep
the old version around.

Main issue I could see with that is stuff we don't stick in cvs/git,
like large patches and non-upstream distfiles.  That really does need
a better solution as has come up before on-list, but I think this is
really a different problem.

> I'm now going to take a break from Gentoo development because this
> thread has seriously caused my blood to boil based on comments from the
> peanut gallery (you) where things don't actually affect your day to day
> work, but your actions do affect mine.

Email threads really aren't the venue for decision-making.  They're a
great place to suggest ideas, and you have to look at them that way.
I've barely skimmed half the messages in this thread, mainly to look
for actual solution suggestions, and sometimes the first reply to one
contains some useful criticism.

It looks like QA has actually intervened with an intended solution.
If you don't like it anybody can ask the council to intervene (looks
like there is less than a week to the next meeting).

Simply debating the issues back and forth on an email list really
isn't like to change things much, and as you and others have pointed
out it can be an extremely frustrating activity.

Rich

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Sergey Popov]

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

05.02.2014 09:41, Tom Wijsman пишет:
> On Tue, 4 Feb 2014 19:28:28 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
> 
>> I've drafted and thrown away so many replies to Tom in this thread.
> 
> What do you want to tell us about this thread?
> 
>> Thanks for putting up with it, but it's a huge waste of your time.
> 
> Why? This discussion has a goal which we are trying to fulfill; if the
> current solution the QA team has formed is insufficient, feel free to
> let us know why such that we can reshape it to fit the situation better.
> 

Maybe we should change our sentence about dropping last stable keywords
for slow arches ONLY if version, still marked stable for them is
seriously broken? And removing old version ONLY on security issues or
maintainer discretion.

Cause it seems that not everybody agrees with policy that we are trying
to make.


-- 
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: Re: dropping redundant stable keywords

[Jeroen Roovers]

On Wed, 05 Feb 2014 15:41:58 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> Cause it seems that not everybody agrees with policy that we are
> trying to make.

Because it's impossible to create a simple policy to solve complex
problems. It's a waste of time and it's going to break more than you
set out to fix.

Use common sense => communicate => resolve issues individually.

If you can't figure things out amongst yourselves, put the matter to
this mailing list instead of bringing it to some kind of "tribunal" -
more visibility gets you more attention from volunteers and gets
actual work done more quickly. Gentoo users and developers (should) just
want to scratch their itches - not have endless arguments about them.

Can we go back to fixing bugs now?


Regards,
     jer

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

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

On Wed, 05 Feb 2014 15:41:58 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> Maybe we should change our sentence about dropping last stable
> keywords for slow arches ONLY if version, still marked stable for
> them is seriously broken?

What does "seriously broken" mean? Maintainers will see that different;
besides that, note that a part of that breakage is invisible, another
part is left unfixed in a growing pile of bug fixes to be backported.

Why do we drop other reasons (like maintenance costs, ebuild age, ...)?

Let me quote some extracts from WilliamH's original mail ([...] snips):

    "It is becoming more and more obvious that we do not have enough
    manpower [...], to keep up with stabilization requests."

    "[...] this was affecting important packages and I felt that the
    arch teams should step up [...]. The arch team member disagreed
    unless the issue is a security bug."

    "Keeping old software in the stable tree, I think we can agree,
    isn't good because newer software, besides having new features,
    will have bug fixes."

Besides those already mentioned, there's one that didn't came up later:
arch team members disagreeing to do important packages is a big concern.

> And removing old version ONLY on security issues

We already do this by masking the version, then later removing it; given
that stabilization is in a very slow state. Or at least, I hope we do...

> or maintainer discretion.

The policy reads "The maintainer may ...".

-- 
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: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 5 Feb 2014 12:58:59 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Wed, 05 Feb 2014 15:41:58 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
> > Cause it seems that not everybody agrees with policy that we are
> > trying to make.
> 
> Because it's impossible to create a simple policy to solve complex
> problems.

Why is it impossible to do that?

> It's a waste of time

Introduction of the complex problem is also a waste of time; should we
stop stabilizing because of that? No, we'll waste our times instead.

Let's waste it efficiently while we're at it, instead of holding up
important packages with stabilization of packages that don't need it;
it can turn that waste of time in much more useful time.

> and it's going to break more than you set out to fix.

It's going to fix more than what was set out to break.

> Use common sense => communicate => resolve issues individually.

Use proper reasoning => discuss respectfully => resolve in team spirit.

> If you can't figure things out amongst yourselves, put the matter to
> this mailing list

That is exactly what was done here.

> instead of bringing it to some kind of "tribunal" -

A tribunal is needed for decision making that leads to a resolution.

> more visibility gets you more attention from volunteers and gets
> actual work done more quickly. Gentoo users and developers (should)
> just want to scratch their itches - 

How many people have joined the arch teams since this thread?

How many people have left since this thread?

What about compared to the last time we had a thread like this?

And the times before that?

> not have endless arguments about them.

In respectful discussions arguments are not endless; besides that, a
policy is in place now which prototypes one side of the arguments. If
that is found to break things (with evidencing commits), or there is
sufficiently backed up reasoning or a reasonable group of people
objecting; then I'm pretty sure it can be turned around through QA, or
when QA insists on not cooperating it can be done through the Council.

> Can we go back to fixing bugs now?

Yes, here are 157 interesting open bugs filed more than 3 months ago:

https://bugs.gentoo.org/buglist.cgi?f1=creation_ts&keywords=STABLEREQ&keywords_type=allwords&o1=lessthan&query_format=advanced&resolution=---&v1=2013-10-05

Which are part of 559 open bugs filed all time (+ 31 missing STABLEREQ):

https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&field0-0-0=keywords&limit=0&type0-0-0=substring&value0-0-0=STABLEREQ

On top of that there are a lot more versions that are considerable for
stabilization; which can be identified using `iamlate`, I guess just
this mention here might get some people to check up what they maintain.

Can we do something about our growing queue when fixing is insufficient?

https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap

PS: As a bonus, here's a nice view of our stabilization queue over time:

https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List

Notice how the graph goes down near the dates the threads were made;
although, if you would draw an average it would appear to be growing.

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

[gentoo-dev] Re: dropping redundant stable keywords

[Duncan]

Tom Wijsman posted on Wed, 05 Feb 2014 13:58:22 +0100 as excerpted:

> Can we do something about our growing queue when fixing is insufficient?
> 
> https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap
> 
> PS: As a bonus, here's a nice view of our stabilization queue over time:
> 
> https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List
> 
> Notice how the graph goes down near the dates the threads were made;
> although, if you would draw an average it would appear to be growing.

Both those links give me this:

Sorry, you aren't a member of the 'editbugs' group, and
so you are not authorized to use the "New Charts" feature. 

=:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

Against my better judgment...

On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote:
> On Tue, 04 Feb 2014 21:15:47 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
> > > On Tue, 04 Feb 2014 19:35:22 -0600
> > > Steev Klimaszewski <steev@gentoo.org> wrote:
> > > 
> > > > Alright, well, I've tried my best, I give up.  Instead of having
> > > > something working we should just remove ebuilds of working
> > > > packages.
> > > 
> > > s/should/could/ s/ebuilds/stable keyword or last stable version/
> > > 
> > > It is at the maintainer's discretion; and such decision is to make
> > > it possible for a maintainer to move on when he or she can no longer
> > > guarantee a working ebuild, to stop being progress-blocked by it.
> > > 
> > 
> > You know what - this is pure and utter bullshit.
> 
> Why is this pure and utter bullshit?

Because I'm attempting to have a discussion with a brick wall.

> 
> > Keeping it around for "slower" arches does NOT block progress.
> 
> Why is keeping it around for "slower" arches not blocking progress?
> 
Let's see... having the software at least available, versus not having
access to it at all... which one is progress...  THINK TOM THINK.

> > I have intimate knowledge with what ACTUALLY happens when people pull
> > this bullshit - and that is a system that I can no longer actually
> > work on.
> 
> That is also what happens when a maintainer keeps around old versions,
> as well as old bugs and support for those old versions; as by doing so,
> the attention towards newer versions is lost which causes much huger
> breakage than the one you have just brought up. Manpower is limited.
> 

And we attempted to come up with a solution for this, however due to the
wording of a page on the interwebs that solution is 100% unacceptable
*to you*, a person who is unaffected by it.

> > And instead of working towards a fix that actually works
> > for people who are ACTUALLY affected by the shitty policy, you hide
> > behind definitions and pedantry.  
> 
> Why do you think this about the current and/or suggested solution(s)?
> 
> > I'm now going to take a break from Gentoo development because this
> > thread has seriously caused my blood to boil based on comments from
> > the peanut gallery (you) where things don't actually affect your day
> > to day work, but your actions do affect mine.
> 
> Why? How and why are your actions affected by the QA team's actions?
> 
Not the QA team's actions.  YOURS. YOUR actions and responses in this
thread.  And the fact that the QA team allows you to continue to be on
it, despite your obvious lack of interest in ACTUALLY having quality
assurance.

My actions are affected by it because I have to continue to attempt to
discuss the issue with others who actually give a shit, and you just
swoop in and say no, that absolutely is unacceptable as a solution (even
though it doesn't affect me!) because this page here says that it can't
- we can change that definition if you'd like.  Instead of the line
saying:

The -* keyword is special. It is used to indicate package versions which
are not worth trying to test on unlisted archs.

Would changing it to read

The -* keyword is special. It is used to indicate package versions which
are not for use on unlisted archs.

Would that make it acceptable? 

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

On Wed, 2014-02-05 at 05:52 -0500, Rich Freeman wrote:
> On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
> >
> > You know what - this is pure and utter bullshit.  Keeping it around for
> > "slower" arches does NOT block progress.  I have intimate knowledge with
> > what ACTUALLY happens when people pull this bullshit - and that is a
> > system that I can no longer actually work on.
> 
> It isn't like deleted ebuilds magically disappear.  You can always dig
> them out of CVS and stick them in an overlay.  It just isn't the
> maintainer's problem.  Any dev can also co-maintain a package and keep
> the old version around.
> 
> Main issue I could see with that is stuff we don't stick in cvs/git,
> like large patches and non-upstream distfiles.  That really does need
> a better solution as has come up before on-list, but I think this is
> really a different problem.
> 
This is true, and normally I would have no problems digging out an old
ebuild, although in this specific case, the old git ebuild will not
work, and any ebuild that relies on the new git eclass will not work
either...  I understood the reason for the change, and it was and is
definitely an unfortunate turn of events, though I finally opened a bug
about it so we can hopefully track down why git 1.8+ doesn't work on arm
uclibc (it works fine on x86/amd64 uclibc).


> > I'm now going to take a break from Gentoo development because this
> > thread has seriously caused my blood to boil based on comments from the
> > peanut gallery (you) where things don't actually affect your day to day
> > work, but your actions do affect mine.
> 
> Email threads really aren't the venue for decision-making.  They're a
> great place to suggest ideas, and you have to look at them that way.
> I've barely skimmed half the messages in this thread, mainly to look
> for actual solution suggestions, and sometimes the first reply to one
> contains some useful criticism.
> 
> It looks like QA has actually intervened with an intended solution.
> If you don't like it anybody can ask the council to intervene (looks
> like there is less than a week to the next meeting).
> 
> Simply debating the issues back and forth on an email list really
> isn't like to change things much, and as you and others have pointed
> out it can be an extremely frustrating activity.
> 
> Rich
> 
There is more to it than that.  Normally discussions can be good, but
when you try to talk to a brick wall, it's absolutely pointless.

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Steev Klimaszewski]

On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote:
> Can we do something about our growing queue when fixing is insufficient?
> 
> https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap
> 
> PS: As a bonus, here's a nice view of our stabilization queue over time:
> 
> https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List
> 
> Notice how the graph goes down near the dates the threads were made;
> although, if you would draw an average it would appear to be growing.
> 
There is far more to stabilizing than just closing the bugs.

I've been working for over 2 months now on the GNOME stabilization on
ARM.  There has been a lot involved, including (but not limited to)
rebuilding kernels for proper systemd integration, setting up systemd so
that software would build (empathy won't build if systemd has no locale
set (lol!) so much for systemd properly importing my settings from
openrc) - building the software itself.  Realizing that some things were
built against the GPU opengl implementation instead of mesa's
implementation, having to rebuild that software, and all it's
dependencies. Then the process of actually attempting to get it to run,
tracking down the junk in the logs - figuring out which messages can be
ignored, which ones are actual errors (why exactly is it throwing an
error message if that message can be ignored?)

This is on multiple machines, because I'd like to cover softfp and
hardfp.  This takes time.  Even if I were to build everything on my
octa-core ARM server and just use the binpkgs, it still takes quite a
bit of time to get through everything.  And this is JUST for the default
useflags.

So you know what?  I'm sick of hearing about "slow arches" - there's a
LOT of shit that we have to do to make sure things ACTUALLY WORK, and
based on your emails, you either have NO IDEA what all is involved in
alternate arch work, or you're purposely being obtuse about it.


Now, we COULD do like Ubuntu, and just say if it builds, it's stable.
But I personally am against that, maybe that's okay with you. We used
Ubuntu on ARM devices at my last job - I'm intimately familiar with
their practices.  We do not want to replicate that here in Gentoo land,
or at least, I don't, not on ARM.  Feel free to look at all the GL based
apps that they have available on armel - and test how many of them
actually run on the hardware.  I'll wait for you to finish going through
them all...  


Save the charts for upper management, they are the only ones who care
what the pretty graphs look like instead of knowing the full details.

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Peter Stuge]

I'm firmly with Steev and Matt in this thread as well as in at least
a few others where Tom has participated intensely.

Tom Wijsman wrote:
> > Thanks for putting up with it, but it's a huge waste of your time.
> 
> Why?

Because you seem to have a completely different mindset than
everybody else, and not in a good way. :\

I told you on IRC that I don't think your approach is good for Gentoo
but I was, and still am, unable to say exactly what is going on. At a
minimum there is a severe communication problem but maybe there's
also something else.


//Peter

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 05 Feb 2014 10:55:59 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote:
> > Can we do something about our growing queue when fixing is
> > insufficient?
> > 
> > https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap
> > 
> > PS: As a bonus, here's a nice view of our stabilization queue over
> > time:
> > 
> > https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List
> > 
> > Notice how the graph goes down near the dates the threads were made;
> > although, if you would draw an average it would appear to be
> > growing.
> > 
> There is far more to stabilizing than just closing the bugs.

It is a sufficient indicator of how the amount of stabilization bugs, as
well as the amount of overall bugs, is increasing over time.

> I've been working for over 2 months now on the GNOME stabilization on
> ARM.  There has been a lot involved, including (but not limited to)
> rebuilding kernels for proper systemd integration, setting up systemd
> so that software would build (empathy won't build if systemd has no
> locale set (lol!) so much for systemd properly importing my settings
> from openrc) - building the software itself.  Realizing that some
> things were built against the GPU opengl implementation instead of
> mesa's implementation, having to rebuild that software, and all it's
> dependencies. Then the process of actually attempting to get it to
> run, tracking down the junk in the logs - figuring out which messages
> can be ignored, which ones are actual errors (why exactly is it
> throwing an error message if that message can be ignored?)
> 
> This is on multiple machines, because I'd like to cover softfp and
> hardfp.  This takes time.  Even if I were to build everything on my
> octa-core ARM server and just use the binpkgs, it still takes quite a
> bit of time to get through everything.  And this is JUST for the
> default useflags.
> 
> So you know what?  I'm sick of hearing about "slow arches" - there's a
> LOT of shit that we have to do to make sure things ACTUALLY WORK, and
> based on your emails, you either have NO IDEA what all is involved in
> alternate arch work, or you're purposely being obtuse about it.

Or it appears that some arches and people already skim down on all that
work because of the huge amount of workload; as you have seen today, I
gave an example of that on #gentoo-dev. I do have an idea; but, it
appears that that idea is already no longer applied by some of us.

I'm sick of important packages being affected this way; "sorry
WilliamH, we can't stabilize unless it's a security bug", *ouch*.

> Now, we COULD do like Ubuntu, and just say if it builds, it's stable.
> But I personally am against that, maybe that's okay with you. We used
> Ubuntu on ARM devices at my last job - I'm intimately familiar with
> their practices.  We do not want to replicate that here in Gentoo
> land, or at least, I don't, not on ARM.  Feel free to look at all the
> GL based apps that they have available on armel - and test how many
> of them actually run on the hardware.  I'll wait for you to finish
> going through them all...  

You'll wait until we burn out in increasingly unimportant workloads.

> Save the charts for upper management, they are the only ones who care
> what the pretty graphs look like instead of knowing the full details.

It demonstrates the actual problem this is all about; some of us do
care about managing the future of Gentoo, as some of us do care to make
sure the water tap is less open before mopping the floor.

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

Re: [gentoo-dev] [OT] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 5 Feb 2014 21:18:46 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > > Thanks for putting up with it, but it's a huge waste of your time.
> > 
> > Why?
> 
> Because you seem to have a completely different mindset than
> everybody else, and not in a good way. :\

That "everybody else" a broad generaliation, make a count and see how
it is a rather small set of individuals; noteworthy with that, is that
it is about different subtopics over this thread. Exactly, because
different solutions were proposed by both sides; and thus, there's
naturally some agreement (not so visual) and disagreement (more visual)
going on here. That's a good thing, it works out those solutions.

> I told you on IRC that I don't think your approach is good for Gentoo
> but I was, and still am, unable to say exactly what is going on. At a
> minimum there is a severe communication problem but maybe there's
> also something else.

Why?

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 05 Feb 2014 10:07:22 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> Against my better judgment...
> 
> On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote:
> > On Tue, 04 Feb 2014 21:15:47 -0600
> > Steev Klimaszewski <steev@gentoo.org> wrote:
> > 
> > > On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
> > > > On Tue, 04 Feb 2014 19:35:22 -0600
> > > > Steev Klimaszewski <steev@gentoo.org> wrote:
> > > > 
> > > > > Alright, well, I've tried my best, I give up.  Instead of
> > > > > having something working we should just remove ebuilds of
> > > > > working packages.
> > > > 
> > > > s/should/could/ s/ebuilds/stable keyword or last stable version/
> > > > 
> > > > It is at the maintainer's discretion; and such decision is to
> > > > make it possible for a maintainer to move on when he or she can
> > > > no longer guarantee a working ebuild, to stop being
> > > > progress-blocked by it.
> > > > 
> > > 
> > > You know what - this is pure and utter bullshit.
> > 
> > Why is this pure and utter bullshit?
> 
> Because I'm attempting to have a discussion with a brick wall.

Can you please keep yourself to responses about the subject as well as
give reasoning for them?  That way, we can make the discussion feel
less solid and more fluent; I'll have to ask again, why a brick wall?

> > > Keeping it around for "slower" arches does NOT block progress.
> > 
> > Why is keeping it around for "slower" arches not blocking progress?
> > 
> Let's see... having the software at least available, versus not having
> access to it at all... which one is progress...  THINK TOM THINK.

Yes, making the newest versions never available because the old
versions sink all your time really stops progress to a dead halt.

> > > I have intimate knowledge with what ACTUALLY happens when people
> > > pull this bullshit - and that is a system that I can no longer
> > > actually work on.
> > 
> > That is also what happens when a maintainer keeps around old
> > versions, as well as old bugs and support for those old versions;
> > as by doing so, the attention towards newer versions is lost which
> > causes much huger breakage than the one you have just brought up.
> > Manpower is limited.
> > 
> 
> And we attempted to come up with a solution for this, however due to
> the wording of a page on the interwebs that solution is 100%
> unacceptable *to you*, a person who is unaffected by it.

The last discussion has shown policy breach by bending words around.

Can you tell why it is acceptable in a way that doesn't breach policy?

> > > And instead of working towards a fix that actually works
> > > for people who are ACTUALLY affected by the shitty policy, you
> > > hide behind definitions and pedantry.  
> > 
> > Why do you think this about the current and/or suggested
> > solution(s)?
> > 
> > > I'm now going to take a break from Gentoo development because this
> > > thread has seriously caused my blood to boil based on comments
> > > from the peanut gallery (you) where things don't actually affect
> > > your day to day work, but your actions do affect mine.
> > 
> > Why? How and why are your actions affected by the QA team's actions?
> > 
> Not the QA team's actions.  YOURS. YOUR actions and responses in this
> thread.  And the fact that the QA team allows you to continue to be on
> it, despite your obvious lack of interest in ACTUALLY having quality
> assurance. My actions are affected by it because I have to continue
> to attempt to discuss the issue with others who actually give a shit,
> and you just swoop in and say no, that absolutely is unacceptable as
> a solution

The policy is made by the QA team; you are attempting to object to the
policy, therefore this is the QA team's action. This is their action.

It is rather that I ask question to clarify what you are trying to say
as to get more useful and meaningful responses; but what I receive in
return is "pure and utter bullshit" on a "brick wall", maybe someone
else would say "no" here but if you take a closer look this as well as
the previous mail contains multiple questions for you.

These questions show interest in assuring quality here; it's actually
what makes up for a defensive style of discussion, making sure that we
keep our quality as opposed to applying the first interesting solution
that we come across. If you deem the QA team's policy doesn't do that,
and that it has a detriment in quality; can you please let us know why?

> (even though it doesn't affect me!) because this page here says that
> it can't
> - we can change that definition if you'd like.  Instead of the line
> saying:
> 
> The -* keyword is special. It is used to indicate package versions
> which are not worth trying to test on unlisted archs.
> 
> Would changing it to read
> 
> The -* keyword is special. It is used to indicate package versions
> which are not for use on unlisted archs.
> 
> Would that make it acceptable? 

Feel free to propose that to the QA team and / or the Gentoo Council.

For this change, some questions come to mind:

- How do we then identify it is not worth trying to test?

- What does "not for use" really mean compared to a package.mask or
  leaving the keywords out?

- How is it different from KEYWORDS="x" instead of KEYWORDS="-* x"?

- Which work do we need to do in the Portage tree to reflect this?

We need to ensure here that we keep our existing workflow working.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 05 Feb 2014 10:26:01 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> There is more to it than that.  Normally discussions can be good, but
> when you try to talk to a brick wall, it's absolutely pointless.

QA team's decisions require more than a flip of a dime; it takes a
little more involvement, as well as solid evidence and reasoning.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Ciaran McCreesh]

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

On Wed, 5 Feb 2014 22:50:57 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> On Wed, 05 Feb 2014 10:26:01 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> > There is more to it than that.  Normally discussions can be good,
> > but when you try to talk to a brick wall, it's absolutely pointless.
> 
> QA team's decisions require more than a flip of a dime; it takes a
> little more involvement, as well as solid evidence and reasoning.

Why?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Rick "Zero_Chaos" Farina]

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

On 02/05/2014 04:48 PM, Tom Wijsman wrote:
> On Wed, 05 Feb 2014 10:07:22 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
>> Against my better judgment...
>>
>> On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote:
>>> On Tue, 04 Feb 2014 21:15:47 -0600
>>> Steev Klimaszewski <steev@gentoo.org> wrote:
>>>
>>>> On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote:
>>>>> On Tue, 04 Feb 2014 19:35:22 -0600
>>>>> Steev Klimaszewski <steev@gentoo.org> wrote:
>>>>>
>>>>>> Alright, well, I've tried my best, I give up.  Instead of
>>>>>> having something working we should just remove ebuilds of
>>>>>> working packages.
>>>>>
>>>>> s/should/could/ s/ebuilds/stable keyword or last stable version/
>>>>>
>>>>> It is at the maintainer's discretion; and such decision is to
>>>>> make it possible for a maintainer to move on when he or she can
>>>>> no longer guarantee a working ebuild, to stop being
>>>>> progress-blocked by it.
>>>>>
>>>>
>>>> You know what - this is pure and utter bullshit.
>>>
>>> Why is this pure and utter bullshit?
>>
>> Because I'm attempting to have a discussion with a brick wall.
> 
> Can you please keep yourself to responses about the subject as well as
> give reasoning for them?  That way, we can make the discussion feel
> less solid and more fluent; I'll have to ask again, why a brick wall?
> 
>>>> Keeping it around for "slower" arches does NOT block progress.
>>>
>>> Why is keeping it around for "slower" arches not blocking progress?
>>>
>> Let's see... having the software at least available, versus not having
>> access to it at all... which one is progress...  THINK TOM THINK.
> 
> Yes, making the newest versions never available because the old
> versions sink all your time really stops progress to a dead halt.
> 

Your logic isn't flawed here, it's entirely missing.  If version Y is
stable on all arches but one, and that version is still using version X
that doesn't affect any of the other arches at all.

If the maintainer doesn't wish to support version X any longer then they
can close bugs wontfix.  Removing the last stable version on an arch
from the tree is against policy.

>>>> I have intimate knowledge with what ACTUALLY happens when people
>>>> pull this bullshit - and that is a system that I can no longer
>>>> actually work on.
>>>
>>> That is also what happens when a maintainer keeps around old
>>> versions, as well as old bugs and support for those old versions;
>>> as by doing so, the attention towards newer versions is lost which
>>> causes much huger breakage than the one you have just brought up.
>>> Manpower is limited.
>>>
>>
>> And we attempted to come up with a solution for this, however due to
>> the wording of a page on the interwebs that solution is 100%
>> unacceptable *to you*, a person who is unaffected by it.
> 
> The last discussion has shown policy breach by bending words around.
> 
> Can you tell why it is acceptable in a way that doesn't breach policy?
> 
>>>> And instead of working towards a fix that actually works
>>>> for people who are ACTUALLY affected by the shitty policy, you
>>>> hide behind definitions and pedantry.  
>>>
>>> Why do you think this about the current and/or suggested
>>> solution(s)?
>>>
>>>> I'm now going to take a break from Gentoo development because this
>>>> thread has seriously caused my blood to boil based on comments
>>>> from the peanut gallery (you) where things don't actually affect
>>>> your day to day work, but your actions do affect mine.
>>>
>>> Why? How and why are your actions affected by the QA team's actions?
>>>
>> Not the QA team's actions.  YOURS. YOUR actions and responses in this
>> thread.  And the fact that the QA team allows you to continue to be on
>> it, despite your obvious lack of interest in ACTUALLY having quality
>> assurance. My actions are affected by it because I have to continue
>> to attempt to discuss the issue with others who actually give a shit,
>> and you just swoop in and say no, that absolutely is unacceptable as
>> a solution
> 
> The policy is made by the QA team; you are attempting to object to the
> policy, therefore this is the QA team's action. This is their action.

Please don't claim you speak for the QA team when in fact, you have not
discussed it with any of us, and the QA lead told you to cool it on irc
hours ago.  You are speaking for yourself here and no one else.  There
is NO policy that allows for dropping a stable ebuild without masks,
discussion, and significant passage of time.
> 
> It is rather that I ask question to clarify what you are trying to say
> as to get more useful and meaningful responses; but what I receive in
> return is "pure and utter bullshit" on a "brick wall", maybe someone
> else would say "no" here but if you take a closer look this as well as
> the previous mail contains multiple questions for you.
> 
> These questions show interest in assuring quality here; it's actually
> what makes up for a defensive style of discussion, making sure that we
> keep our quality as opposed to applying the first interesting solution
> that we come across. If you deem the QA team's policy doesn't do that,
> and that it has a detriment in quality; can you please let us know why?
> 

Again, there is no policy that allows you to drop a stable package on an
arch without a whole lot of things that I definitely never say happen.
Honestly, if I even knew what you two were discussing in specific I'd
likely be reverting the stupid drop instead of pointing out things in
this thread which is wasting my time, and everyone else's.

>> (even though it doesn't affect me!) because this page here says that
>> it can't
>> - we can change that definition if you'd like.  Instead of the line
>> saying:
>>
>> The -* keyword is special. It is used to indicate package versions
>> which are not worth trying to test on unlisted archs.
>>
>> Would changing it to read
>>
>> The -* keyword is special. It is used to indicate package versions
>> which are not for use on unlisted archs.
>>
>> Would that make it acceptable? 
> 
> Feel free to propose that to the QA team and / or the Gentoo Council.

No changes are required. Everyone with 2 brain cells knows that -* means
"cannot work on other arches". Things like binary packages, etc.


Now, before you continue "discussing" this issue here on the list,
perhaps you should turn around and talk to the QA team about what needs
changed and discussed.

thanks,
Zero_Chaos

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

iQIcBAEBAgAGBQJS8rWUAAoJEKXdFCfdEflKH1AQAJl53etm0jJvfDjt0bIVWW9J
v+2TxXTCEFbJ2IXnws1VU0XNdUq6CUOWTIWSFSzTi6y5assNTkFQxdkUJqYZbN7/
35oOe2j4Ug1Kc7Gv/qT7U70H69vhFu65KnA76oag5LiXnp/Cw2zMWJvk0KbEWRr9
uTf8NeJGZmLClAz+xYQRvnjScKRinh3tRxQN0SywUYuThkJsQdkBMZ2jI1YdtPkb
ixWLnnpIA6LWNNJhB/aISowCvPIrFNgb9VkKGGnCnC3wcU+UsgGwXe7gFl+/YhiP
Sn8exNJATBNujjzaZFlUZoZXFadGw12Zu9i8MFpPX+NKZgd5c5ACN2nMmv4rJ8HH
9BErDPpLN/aTvbAND4UFoUDKG4reMYzdYAxp0/HymVU2Um7M+/Ix2xLZ9+xWj2HY
KIjYDsyPiqr3GVJdw+deQf0E+PjPRs1/lgcp8vRtnP0dmBBsBD86jYCmBNthuztY
8Bm2YZw3bNLvmQ8+tRIf7Bvk/2txkPF+KCt6/6aZBz5DkNqHxMAvQsZwtrW2bDzB
em3ZiVmL+rIx8xKNXWqSZA+beHKZIUdtZt4AFuxwerRhEpY5nGvr/g9TJ9Mu3HOw
CK+lXdK4pSbye6SzvvCktjFTl9szXXefqXkZRrd17lFUGwRQQ6kWdy5hBY6cyZRU
QqBl7ipbjb1ZaMIXj7Xe
=ezms
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 05 Feb 2014 17:05:08 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> > 
> > Yes, making the newest versions never available because the old
> > versions sink all your time really stops progress to a dead halt.
> > 
> 
> Your logic isn't flawed here, it's entirely missing.  If version Y is
> stable on all arches but one, and that version is still using version
> X that doesn't affect any of the other arches at all.

Can this be proven? Why are maintainers like WilliamH upset about this?

Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063

> If the maintainer doesn't wish to support version X any longer then
> they can close bugs wontfix.

+1, but what about stabilization bugs that block other bugs?

> Removing the last stable version on an arch from the tree is against
> policy.

The QA policy meant to override this; to avoid confusion, I mean
including the proper workflow involved in this. But this has raised
concerns on IRC today, as it was made clear what the reasons are that I
was asking for; it's good that we do a new vote on this to properly
reflect what we really intend, rather than some poor voting that went
through a quick vote and didn't take everything in consideration.

> >> Not the QA team's actions.  YOURS. YOUR actions and responses in
> >> this thread.  And the fact that the QA team allows you to continue
> >> to be on it, despite your obvious lack of interest in ACTUALLY
> >> having quality assurance. My actions are affected by it because I
> >> have to continue to attempt to discuss the issue with others who
> >> actually give a shit, and you just swoop in and say no, that
> >> absolutely is unacceptable as a solution
> > 
> > The policy is made by the QA team; you are attempting to object to
> > the policy, therefore this is the QA team's action. This is their
> > action.
> 
> Please don't claim you speak for the QA team when in fact, you have
> not discussed it with any of us,

We did discuss this QA policy during the QA meeting.

> and the QA lead told you to cool it on irc hours ago.

That was minutes ago, you are replying to is written before that;
furthermore, I believe things are cool. Why do you think otherwise?

> You are speaking for yourself here and no one else.

I'm quoting QA team policy, agreed on by at least 8 individuals; that
policy can be read at the following URL:

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies

If you still think so, can you show me where I did speak for myself?

> There is NO policy that allows for dropping a stable ebuild without
> masks, discussion, and significant passage of time.
>
> > It is rather that I ask question to clarify what you are trying to
> > say as to get more useful and meaningful responses; but what I
> > receive in return is "pure and utter bullshit" on a "brick wall",
> > maybe someone else would say "no" here but if you take a closer
> > look this as well as the previous mail contains multiple questions
> > for you.
> > 
> > These questions show interest in assuring quality here; it's
> > actually what makes up for a defensive style of discussion, making
> > sure that we keep our quality as opposed to applying the first
> > interesting solution that we come across. If you deem the QA team's
> > policy doesn't do that, and that it has a detriment in quality; can
> > you please let us know why?
> > 
> 
> Again, there is no policy that allows you to drop a stable package on
> an arch without a whole lot of things that I definitely never say
> happen. Honestly, if I even knew what you two were discussing in
> specific I'd likely be reverting the stupid drop instead of pointing
> out things in this thread which is wasting my time, and everyone
> else's.

Indeed, there isn't; where did I say there is?

Now that it has been said so on IRC, I see it can be misinterpreted.

> >> (even though it doesn't affect me!) because this page here says
> >> that it can't
> >> - we can change that definition if you'd like.  Instead of the line
> >> saying:
> >>
> >> The -* keyword is special. It is used to indicate package versions
> >> which are not worth trying to test on unlisted archs.
> >>
> >> Would changing it to read
> >>
> >> The -* keyword is special. It is used to indicate package versions
> >> which are not for use on unlisted archs.
> >>
> >> Would that make it acceptable? 
> > 
> > Feel free to propose that to the QA team and / or the Gentoo
> > Council.
> 
> No changes are required. Everyone with 2 brain cells knows that -*
> means "cannot work on other arches". Things like binary packages, etc.

And thus -* is not a solution to this thread.

> Now, before you continue "discussing" this issue here on the list,
> perhaps you should turn around and talk to the QA team about what
> needs changed and discussed.

+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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

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

On Wed, 5 Feb 2014 22:03:09 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 5 Feb 2014 22:50:57 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Wed, 05 Feb 2014 10:26:01 -0600
> > Steev Klimaszewski <steev@gentoo.org> wrote:
> > > There is more to it than that.  Normally discussions can be good,
> > > but when you try to talk to a brick wall, it's absolutely
> > > pointless.
> > 
> > QA team's decisions require more than a flip of a dime; it takes a
> > little more involvement, as well as solid evidence and reasoning.
> 
> Why?

Because QA team's decisions are decided on during a QA team meeting
that happens once a month, just like the Gentoo Council does; it
requires us to talk about it and work towards a decision, otherwise a
statement can't be formed and we can't vote on that statement.

If we were brick walls, this policy would never get formed; exactly the
opposite is happening here, after the reason that I was asking for here
became clear in #gentoo-dev we are going to further discuss it to adapt.

The solid evidence (that it can be misinterpreted) and reasoning (that
its misinterpretations lead to situations that we don't want) both are
sufficient to revise the policy. Without those, we get what you see in
this thread; the lack of evidence and reasoning not showing why the
policy in its current form would cause breakage, or why particular
other solutions would work out well.

-- 
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: Re: dropping redundant stable keywords

[Rick "Zero_Chaos" Farina]

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

On 02/05/2014 07:48 PM, Tom Wijsman wrote:
> On Wed, 05 Feb 2014 17:05:08 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>>>
>>> Yes, making the newest versions never available because the old
>>> versions sink all your time really stops progress to a dead halt.
>>>
>>
>> Your logic isn't flawed here, it's entirely missing.  If version Y is
>> stable on all arches but one, and that version is still using version
>> X that doesn't affect any of the other arches at all.
> 
> Can this be proven? Why are maintainers like WilliamH upset about this?
> 
> Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063

I've already voiced my concern on his bug:
https://bugs.gentoo.org/show_bug.cgi?id=500014
> 
>> If the maintainer doesn't wish to support version X any longer then
>> they can close bugs wontfix.
> 
> +1, but what about stabilization bugs that block other bugs?

They stay open as a tracker, bugs track all arches.  This doesn't
prevent the work being done on the faster arches, all it does is leave
bugs hanging around when certain devs think more closed bugs is more better.
> 
>> Removing the last stable version on an arch from the tree is against
>> policy.
> 
> The QA policy meant to override this; to avoid confusion, I mean
> including the proper workflow involved in this. But this has raised
> concerns on IRC today, as it was made clear what the reasons are that I
> was asking for; it's good that we do a new vote on this to properly
> reflect what we really intend, rather than some poor voting that went
> through a quick vote and didn't take everything in consideration.
> 
Nothing in the QA policy says "ignore standard removal policy".  Here is
the standard removal policy, and I expect it to be followed:

https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

When a doctor tells you "go to the hospital as fast as you can" he
doesn't mean "steal a faster car, speed as much as possible, and don't
stop at red lights".  Doing so would obviously be dangerous, and cause
additional problems, just like ignoring the standard keyword/ebuild
removal policy.

>>>> Not the QA team's actions.  YOURS. YOUR actions and responses in
>>>> this thread.  And the fact that the QA team allows you to continue
>>>> to be on it, despite your obvious lack of interest in ACTUALLY
>>>> having quality assurance. My actions are affected by it because I
>>>> have to continue to attempt to discuss the issue with others who
>>>> actually give a shit, and you just swoop in and say no, that
>>>> absolutely is unacceptable as a solution
>>>
>>> The policy is made by the QA team; you are attempting to object to
>>> the policy, therefore this is the QA team's action. This is their
>>> action.
>>
>> Please don't claim you speak for the QA team when in fact, you have
>> not discussed it with any of us,
> 
> We did discuss this QA policy during the QA meeting.
> 
>> and the QA lead told you to cool it on irc hours ago.
> 
> That was minutes ago, you are replying to is written before that;
> furthermore, I believe things are cool. Why do you think otherwise?
> 
>> You are speaking for yourself here and no one else.
> 
> I'm quoting QA team policy, agreed on by at least 8 individuals; that
> policy can be read at the following URL:
> 
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
> 
That policy doesn't permit removal of keywords/ebuilds without following
gentoo standard policy, standard policy is available here:
https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

> If you still think so, can you show me where I did speak for myself?

As I am also a member of the QA team, clearly there isn't a consensus on
this topic.
> 
>> There is NO policy that allows for dropping a stable ebuild without
>> masks, discussion, and significant passage of time.
>>
>>> It is rather that I ask question to clarify what you are trying to
>>> say as to get more useful and meaningful responses; but what I
>>> receive in return is "pure and utter bullshit" on a "brick wall",
>>> maybe someone else would say "no" here but if you take a closer
>>> look this as well as the previous mail contains multiple questions
>>> for you.
>>>
>>> These questions show interest in assuring quality here; it's
>>> actually what makes up for a defensive style of discussion, making
>>> sure that we keep our quality as opposed to applying the first
>>> interesting solution that we come across. If you deem the QA team's
>>> policy doesn't do that, and that it has a detriment in quality; can
>>> you please let us know why?
>>>
>>
>> Again, there is no policy that allows you to drop a stable package on
>> an arch without a whole lot of things that I definitely never say
>> happen. Honestly, if I even knew what you two were discussing in
>> specific I'd likely be reverting the stupid drop instead of pointing
>> out things in this thread which is wasting my time, and everyone
>> else's.
> 
> Indeed, there isn't; where did I say there is?
> 
> Now that it has been said so on IRC, I see it can be misinterpreted.
> 
>>>> (even though it doesn't affect me!) because this page here says
>>>> that it can't
>>>> - we can change that definition if you'd like.  Instead of the line
>>>> saying:
>>>>
>>>> The -* keyword is special. It is used to indicate package versions
>>>> which are not worth trying to test on unlisted archs.
>>>>
>>>> Would changing it to read
>>>>
>>>> The -* keyword is special. It is used to indicate package versions
>>>> which are not for use on unlisted archs.
>>>>
>>>> Would that make it acceptable? 
>>>
>>> Feel free to propose that to the QA team and / or the Gentoo
>>> Council.
>>
>> No changes are required. Everyone with 2 brain cells knows that -*
>> means "cannot work on other arches". Things like binary packages, etc.
> 
> And thus -* is not a solution to this thread.

Agreed. If "slow arch" is causing issues, it would seem simple enough to
drop all the keywords except "slow arch" on the older ebuild. It reduces
maintenance burden while not breaking anyway.  Amazing how the simple
ones elude us sometimes.
> 
>> Now, before you continue "discussing" this issue here on the list,
>> perhaps you should turn around and talk to the QA team about what
>> needs changed and discussed.
> 
> +1
> 
The goal of QA is to maintain the quality of the tree. Randomly removing
packages that are blocking closing bugs doesn't contribute to tree
quality, it degrades it.  I think we can all agree we are here to make
gentoo better, so let's work together instead of against each other.

No one is going to remove a stable ebuild for an arch without discussion
with the maintainer and following proper policy outlined here:
https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

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

iQIcBAEBAgAGBQJS8t65AAoJEKXdFCfdEflKuIoQAJ9pzRygpdW18BAZfPX+a73j
YrThNkStYSr8Ld9cQIG9tWrnuwbXUlHZt1HbJTprOrbIAIGSvy5gJm3AyoAz4lk+
0Zka9cjy6rgLGsmsLZ0AM1eJkoHl3Z3Qh+a7vYF8yhB0E5yKtqAOSjYrz9vGPRGD
+UO5rnsBfZ5TBasnENZAJtniapsshidgHGQ/zvXwuPHqoMnshhsgP5u2c3LDpSiU
17rrA+m3fkqic6aNvTELOY/a47YmA+gWfq7J0Ahs2/RRdVo6kNeFMKKmoa3o8BG6
AB6v752LfNCFHbZTfmrNPxJvHqm9a2QybFPziAlHin0Truml5ayj90ZCz/0N1pR4
dQTRvwkpX4JWvV5BZj1hXJYEViOY32F62CHeNLfCKxviio5sMxZ168Yvvop66A0+
aY/n4bPa3euSjaMEfiSVOGx0DBaiMaBkiYlcVrcIzaevlrAO+VnvPBYR5HzMehH+
GNgf6r2rOqGwtMe2yU+ilOPVvkPh71KpOS/KXCke/6aEmMTjLZ9/COWmZ5ltnK7H
k/52k3Jh6KoKtrT8HS+FHs7+kT6SJj9MwGz9gEG1H2eTE7/VLVnC2JrVvB2SPIJF
5Uk7giW87lgd7cCdZwRMEVR/nKrVAuGysK+EMJxgvhZkYXz9kDCusfFxw3NIvvMO
34VTKxpRaPzeNItzClv0
=ED04
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Rich Freeman]

On Wed, Feb 5, 2014 at 8:00 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> On 02/05/2014 07:48 PM, Tom Wijsman wrote:
>>
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
>>
> That policy doesn't permit removal of keywords/ebuilds without following
> gentoo standard policy, standard policy is available here:
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

So, I realize I'm repeating myself, but the purpose of the mailing
list isn't to keep reposting the same arguments back and forth until
everybody agrees.  Post your argument once, and once it gets dull by
all means appeal to QA/council/whatever but the bickering really
doesn't add any value.  For my part I promise not to let it be a
whoever-makes-the-most-noise-sets-the-policy thing.  I appreciate the
concerns, arguments, and alternatives that were raised - they're
helpful the first time they come up.

To add something new, can the QA team please figure out what policy
they actually intended to make and just communicate it?  Having QA
team members and everybody else openly speculating about what the
policy is supposed to be on the list also adds no value.  If the new
policy does not in fact override the standard policy then I'm not
really sure what it is trying to say since it only speaks to things
that were already spoken to before, just in a different way.  Thanks
for updating the policy webpage with the note that the policy
shouldn't be followed until clarified.

One thing I haven't really seen in this thread is a better
understanding of the demand for old version removal.  I can understand
the hypothetical issues having old versions creates, but is just
WONTFIXing a bunch of old bugs a large burden in practice?  Before we
create new problems by fixing old problems, I'd like to get a sense
for whether the old problems are actually problems.  I imagine this
becomes a matter of degree - keeping a package around for an extra
6-12 months probably isn't a big deal, but when half the tree contains
6-year-old versions it is a problem.

Rich

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 05 Feb 2014 20:00:41 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> > Can this be proven? Why are maintainers like WilliamH upset about
> > this?
> > 
> > Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063
> 
> I've already voiced my concern on his bug:
> https://bugs.gentoo.org/show_bug.cgi?id=500014

Yes; there is some unclear wording causing misconceptions as well as
that you oppose in a way that makes it worth to clarify and vote again,
and I'll ACK hard enough to not discuss this without your presence. 

> > 
> >> If the maintainer doesn't wish to support version X any longer then
> >> they can close bugs wontfix.
> > 
> > +1, but what about stabilization bugs that block other bugs?
> 
> They stay open as a tracker, bugs track all arches.  This doesn't
> prevent the work being done on the faster arches, all it does is leave
> bugs hanging around when certain devs think more closed bugs is more
> better.

My concern with this is that that list is growing; and when that
happens, I'm not so much for "closed bugs", but rather about shifting
our priority to more important bugs, getting new people, better arch
testing quality, and the list goes on...

We could for example use Tinderbox and have it send success / failure
results, build logs and binpkg(s) (for download) to the arch team,
which makes the arch team just have to solely do a quick inspeciton
of the build log and test the binpkg; this automation can cut down on a
lot of manual testing. On top of that, you have Tinderbox's build log
checking on top of that; which can catch some things the eye might not
see at a first take. This was an example from #gentoo-dev yesterday.

> >> Removing the last stable version on an arch from the tree is
> >> against policy.
> > 
> > The QA policy meant to override this; to avoid confusion, I mean
> > including the proper workflow involved in this. But this has raised
> > concerns on IRC today, as it was made clear what the reasons are
> > that I was asking for; it's good that we do a new vote on this to
> > properly reflect what we really intend, rather than some poor
> > voting that went through a quick vote and didn't take everything in
> > consideration.
> > 
> Nothing in the QA policy says "ignore standard removal policy".  Here
> is the standard removal policy, and I expect it to be followed:
> 
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

We do however "revisit" it (subject of original thread); the workflow
(masking, news, ...) of course should not be ignored, however we do
ignore that it says "not to remove the last stable ebuild".

> When a doctor tells you "go to the hospital as fast as you can" he
> doesn't mean "steal a faster car, speed as much as possible, and don't
> stop at red lights".  Doing so would obviously be dangerous, and cause
> additional problems, just like ignoring the standard keyword/ebuild
> removal policy.

Consider that the person will however at least try to test the limits;
and even with those limits in place and following them, the person can
still slowly crash into something. Attention and thoughts are involved.

> >>>> Not the QA team's actions.  YOURS. YOUR actions and responses in
> >>>> this thread.  And the fact that the QA team allows you to
> >>>> continue to be on it, despite your obvious lack of interest in
> >>>> ACTUALLY having quality assurance. My actions are affected by it
> >>>> because I have to continue to attempt to discuss the issue with
> >>>> others who actually give a shit, and you just swoop in and say
> >>>> no, that absolutely is unacceptable as a solution
> >>>
> >>> The policy is made by the QA team; you are attempting to object to
> >>> the policy, therefore this is the QA team's action. This is their
> >>> action.
> >>
> >> Please don't claim you speak for the QA team when in fact, you have
> >> not discussed it with any of us,
> > 
> > We did discuss this QA policy during the QA meeting.
> > 
> >> and the QA lead told you to cool it on irc hours ago.
> > 
> > That was minutes ago, you are replying to is written before that;
> > furthermore, I believe things are cool. Why do you think otherwise?
> > 
> >> You are speaking for yourself here and no one else.
> > 
> > I'm quoting QA team policy, agreed on by at least 8 individuals;
> > that policy can be read at the following URL:
> > 
> > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
> > 
> That policy doesn't permit removal of keywords/ebuilds without
> following gentoo standard policy, standard policy is available here:
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

Maybe, maybe not; that can be misinterpreted. But what does it permit?

> > If you still think so, can you show me where I did speak for myself?
> 
> As I am also a member of the QA team, clearly there isn't a consensus
> on this topic.

So, there isn't an occasion where I spoke for myself?

> >> There is NO policy that allows for dropping a stable ebuild without
> >> masks, discussion, and significant passage of time.
> >>
> >>> It is rather that I ask question to clarify what you are trying to
> >>> say as to get more useful and meaningful responses; but what I
> >>> receive in return is "pure and utter bullshit" on a "brick wall",
> >>> maybe someone else would say "no" here but if you take a closer
> >>> look this as well as the previous mail contains multiple questions
> >>> for you.
> >>>
> >>> These questions show interest in assuring quality here; it's
> >>> actually what makes up for a defensive style of discussion, making
> >>> sure that we keep our quality as opposed to applying the first
> >>> interesting solution that we come across. If you deem the QA
> >>> team's policy doesn't do that, and that it has a detriment in
> >>> quality; can you please let us know why?
> >>>
> >>
> >> Again, there is no policy that allows you to drop a stable package
> >> on an arch without a whole lot of things that I definitely never
> >> say happen. Honestly, if I even knew what you two were discussing
> >> in specific I'd likely be reverting the stupid drop instead of
> >> pointing out things in this thread which is wasting my time, and
> >> everyone else's.
> > 
> > Indeed, there isn't; where did I say there is?
> > 
> > Now that it has been said so on IRC, I see it can be misinterpreted.
> > 
> >>>> (even though it doesn't affect me!) because this page here says
> >>>> that it can't
> >>>> - we can change that definition if you'd like.  Instead of the
> >>>> line saying:
> >>>>
> >>>> The -* keyword is special. It is used to indicate package
> >>>> versions which are not worth trying to test on unlisted archs.
> >>>>
> >>>> Would changing it to read
> >>>>
> >>>> The -* keyword is special. It is used to indicate package
> >>>> versions which are not for use on unlisted archs.
> >>>>
> >>>> Would that make it acceptable? 
> >>>
> >>> Feel free to propose that to the QA team and / or the Gentoo
> >>> Council.
> >>
> >> No changes are required. Everyone with 2 brain cells knows that -*
> >> means "cannot work on other arches". Things like binary packages,
> >> etc.
> > 
> > And thus -* is not a solution to this thread.
> 
> Agreed. If "slow arch" is causing issues, it would seem simple enough
> to drop all the keywords except "slow arch" on the older ebuild. It
> reduces maintenance burden while not breaking anyway.  Amazing how
> the simple ones elude us sometimes.

+1

> >> Now, before you continue "discussing" this issue here on the list,
> >> perhaps you should turn around and talk to the QA team about what
> >> needs changed and discussed.
> > 
> > +1
> > 
> The goal of QA is to maintain the quality of the tree. Randomly
> removing packages that are blocking closing bugs doesn't contribute
> to tree quality, it degrades it.

This discussion isn't about removing packages; it is about removing
keywords or ebuilds, which doesn't break things if done properly.

It can just as well improve tree quality, as it can remove creeping
breakage; you can't black on white say whether it improves / degrades
the tree quality, as there is too much involved in that. To put it in
Jeroen's words "there's no simple policy for a complex problem" to some
extent applies here; and hence you have to deal with "simple problems"
as they appear, and then adapt policy (or the problem) to make a fit.

So, I'm not convinced that it degrades it; can you show commits that do?

Neither will you be convinced that it improves it yet; as the commits to
show you still have to be made, we can at least agree that we can't
determine together what really happens to the quality.

I'm however convinced it will make our stabilization efforts of higher
quality; as we move work from non-important to important business, in
upper management terms, to reach more effective and efficient results.

> I think we can all agree we are here to make gentoo better, so let's
> work together instead of against each other.

+1

> No one is going to remove a stable ebuild for an arch without
> discussion with the maintainer and following proper policy outlined
> here:
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

The policy is that it is at the maintainer's discretion; furthermore, I
agree that workflow should be followed and not just a plain `rm ...` as
that would put people as a surprise (and doesn't invite arch mentees).

Consider this instead:

# This last stable version has been masked on your architecture because:
#
#     Solid reason, bugs #1, #2, #3, ...
#
# To continue to stabilize this package on your architecture, we
# currently run short in manpower to keep up with stabilizing it; if you
# want to help us out, you can contact us at [reference: staffing page]
# and read more about how arch testing works at [reference: arch
testing].

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Jeroen Roovers]

On Wed, 05 Feb 2014 10:07:22 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> > Why is this pure and utter bullshit?
> 
> Because I'm attempting to have a discussion with a brick wall.

I hit that problem immediately in another sub-thread. Are we on to
something here?


Regards,
     jer

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 5 Feb 2014 20:50:07 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> So, I realize I'm repeating myself, but the purpose of the mailing
> list isn't to keep reposting the same arguments back and forth until
> everybody agrees.  Post your argument once, and once it gets dull by
> all means appeal to QA/council/whatever but the bickering really
> doesn't add any value. For my part I promise not to let it be a
> whoever-makes-the-most-noise-sets-the-policy thing.  I appreciate the
> concerns, arguments, and alternatives that were raised - they're
> helpful the first time they come up.

+1

> To add something new, can the QA team please figure out what policy
> they actually intended to make and just communicate it?  Having QA
> team members and everybody else openly speculating about what the
> policy is supposed to be on the list also adds no value.

This is a misconception; Rick was absent during the meeting, we've
voted for it with 7 of 10, 1 person abstained, 2 were absent. A
majority thus wants the statement as it was written; which has
appeared fine up until the point that Rick addressed me in public with
a misinterpretation of that policy (or might have been unaware of it),
it's only after that point that it became clear of what I was asking
Steev, that the current policy by the QA team is being misinterpreted.

> If the new policy does not in fact override the standard policy then
> I'm not really sure what it is trying to say since it only speaks to
> things that were already spoken to before, just in a different way.

Exactly the point; note though to avoid confusion that there is a
difference between policy and workflow here. We should still use mask
messages, if needed even news and more; and not just plain out `rm ...`.

However, just like you, I see no other way to read that policy than to
override our existing policy that reads 'You should also not cause an
unnecessary downgrade for any "~arch" when removing ebuilds - ...'

http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance

And to this extent I think Rick disagrees with the essence of it; but
then again, there has also been mentions of improving the wording. Thus
I don't really know if Rick wants to see it changed _or_ removed...;
however, that'll become clear with more discussion and the meeting,
which have happened, are happening and will happen on #gentoo-qa.

> Thanks for updating the policy webpage with the note that the policy
> shouldn't be followed until clarified.

+1 for creffett doing that.

> One thing I haven't really seen in this thread is a better
> understanding of the demand for old version removal. I can
> understand the hypothetical issues having old versions creates.

> But is just WONTFIXing a bunch of old bugs a large burden in practice?

It upsets stable users; and thinking of it, it doesn't get the actual
stabilization problem across. Furthermore it is odd to show the user it
is not maintained anymore while keeping that stable keyword and version
around. Why mark it stable if the maintainer doesn't maintain it?
Should it still be kept marked stable if the maintainer considers it to
not really be stable? *"Hey you, maintainer, it acts a bit buggy!"*

> Before we create new problems by fixing old problems, I'd like to get
> a sense for whether the old problems are actually problems.  I
> imagine this becomes a matter of degree - keeping a package around
> for an extra 6-12 months probably isn't a big deal, but when half the
> tree contains 6-year-old versions it is a problem.

We should reconsider 90 days in this respect, it might be a bit on
the low end; counting in years would indeed be more appropriate.

Note that maybe (just guessing) those 6-year-old versions don't really
exist; but, if the stable queue continues to grow (it grows on average)
like this over time they eventually will get to exist in the future.

And that'll come to be an actual problem; and to avoid scratching our
heads by that time, it is nice to have our response in place in advance.

Quoting my meeting agenda questions of last time that reflect this:

    "How do we evaluate whether future stabilization improves or
    becomes worse? How bad is stabilization really at the moment? How
    can we make more users and/or developers interested in arch testing
    (and/or Gentoo)? Do we want to make a policy change now, or delay
    considering it till a later meeting in the future? ...?"

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Thu, 6 Feb 2014 03:12:54 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Wed, 05 Feb 2014 10:07:22 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > > Why is this pure and utter bullshit?
> > 
> > Because I'm attempting to have a discussion with a brick wall.
> 
> I hit that problem immediately in another sub-thread. Are we on to
> something here?

Yes, we are; for more details: http://www.paulgraham.com/disagree.html

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tyler Pohl]

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

why cant there be a second repository for all old source, ebuilds, and
patches and the stable and testing repository can be rolling like it
already is.  slower archs can then sync the old repository and the new one.
On Feb 5, 2014 5:54 PM, "Tom Wijsman" <TomWij@gentoo.org> wrote:

> On Wed, 05 Feb 2014 20:00:41 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
>
> > > Can this be proven? Why are maintainers like WilliamH upset about
> > > this?
> > >
> > > Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063
> >
> > I've already voiced my concern on his bug:
> > https://bugs.gentoo.org/show_bug.cgi?id=500014
>
> Yes; there is some unclear wording causing misconceptions as well as
> that you oppose in a way that makes it worth to clarify and vote again,
> and I'll ACK hard enough to not discuss this without your presence.
>
> > >
> > >> If the maintainer doesn't wish to support version X any longer then
> > >> they can close bugs wontfix.
> > >
> > > +1, but what about stabilization bugs that block other bugs?
> >
> > They stay open as a tracker, bugs track all arches.  This doesn't
> > prevent the work being done on the faster arches, all it does is leave
> > bugs hanging around when certain devs think more closed bugs is more
> > better.
>
> My concern with this is that that list is growing; and when that
> happens, I'm not so much for "closed bugs", but rather about shifting
> our priority to more important bugs, getting new people, better arch
> testing quality, and the list goes on...
>
> We could for example use Tinderbox and have it send success / failure
> results, build logs and binpkg(s) (for download) to the arch team,
> which makes the arch team just have to solely do a quick inspeciton
> of the build log and test the binpkg; this automation can cut down on a
> lot of manual testing. On top of that, you have Tinderbox's build log
> checking on top of that; which can catch some things the eye might not
> see at a first take. This was an example from #gentoo-dev yesterday.
>
> > >> Removing the last stable version on an arch from the tree is
> > >> against policy.
> > >
> > > The QA policy meant to override this; to avoid confusion, I mean
> > > including the proper workflow involved in this. But this has raised
> > > concerns on IRC today, as it was made clear what the reasons are
> > > that I was asking for; it's good that we do a new vote on this to
> > > properly reflect what we really intend, rather than some poor
> > > voting that went through a quick vote and didn't take everything in
> > > consideration.
> > >
> > Nothing in the QA policy says "ignore standard removal policy".  Here
> > is the standard removal policy, and I expect it to be followed:
> >
> >
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html
>
> We do however "revisit" it (subject of original thread); the workflow
> (masking, news, ...) of course should not be ignored, however we do
> ignore that it says "not to remove the last stable ebuild".
>
> > When a doctor tells you "go to the hospital as fast as you can" he
> > doesn't mean "steal a faster car, speed as much as possible, and don't
> > stop at red lights".  Doing so would obviously be dangerous, and cause
> > additional problems, just like ignoring the standard keyword/ebuild
> > removal policy.
>
> Consider that the person will however at least try to test the limits;
> and even with those limits in place and following them, the person can
> still slowly crash into something. Attention and thoughts are involved.
>
> > >>>> Not the QA team's actions.  YOURS. YOUR actions and responses in
> > >>>> this thread.  And the fact that the QA team allows you to
> > >>>> continue to be on it, despite your obvious lack of interest in
> > >>>> ACTUALLY having quality assurance. My actions are affected by it
> > >>>> because I have to continue to attempt to discuss the issue with
> > >>>> others who actually give a shit, and you just swoop in and say
> > >>>> no, that absolutely is unacceptable as a solution
> > >>>
> > >>> The policy is made by the QA team; you are attempting to object to
> > >>> the policy, therefore this is the QA team's action. This is their
> > >>> action.
> > >>
> > >> Please don't claim you speak for the QA team when in fact, you have
> > >> not discussed it with any of us,
> > >
> > > We did discuss this QA policy during the QA meeting.
> > >
> > >> and the QA lead told you to cool it on irc hours ago.
> > >
> > > That was minutes ago, you are replying to is written before that;
> > > furthermore, I believe things are cool. Why do you think otherwise?
> > >
> > >> You are speaking for yourself here and no one else.
> > >
> > > I'm quoting QA team policy, agreed on by at least 8 individuals;
> > > that policy can be read at the following URL:
> > >
> > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
> > >
> > That policy doesn't permit removal of keywords/ebuilds without
> > following gentoo standard policy, standard policy is available here:
> >
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html
>
> Maybe, maybe not; that can be misinterpreted. But what does it permit?
>
> > > If you still think so, can you show me where I did speak for myself?
> >
> > As I am also a member of the QA team, clearly there isn't a consensus
> > on this topic.
>
> So, there isn't an occasion where I spoke for myself?
>
> > >> There is NO policy that allows for dropping a stable ebuild without
> > >> masks, discussion, and significant passage of time.
> > >>
> > >>> It is rather that I ask question to clarify what you are trying to
> > >>> say as to get more useful and meaningful responses; but what I
> > >>> receive in return is "pure and utter bullshit" on a "brick wall",
> > >>> maybe someone else would say "no" here but if you take a closer
> > >>> look this as well as the previous mail contains multiple questions
> > >>> for you.
> > >>>
> > >>> These questions show interest in assuring quality here; it's
> > >>> actually what makes up for a defensive style of discussion, making
> > >>> sure that we keep our quality as opposed to applying the first
> > >>> interesting solution that we come across. If you deem the QA
> > >>> team's policy doesn't do that, and that it has a detriment in
> > >>> quality; can you please let us know why?
> > >>>
> > >>
> > >> Again, there is no policy that allows you to drop a stable package
> > >> on an arch without a whole lot of things that I definitely never
> > >> say happen. Honestly, if I even knew what you two were discussing
> > >> in specific I'd likely be reverting the stupid drop instead of
> > >> pointing out things in this thread which is wasting my time, and
> > >> everyone else's.
> > >
> > > Indeed, there isn't; where did I say there is?
> > >
> > > Now that it has been said so on IRC, I see it can be misinterpreted.
> > >
> > >>>> (even though it doesn't affect me!) because this page here says
> > >>>> that it can't
> > >>>> - we can change that definition if you'd like.  Instead of the
> > >>>> line saying:
> > >>>>
> > >>>> The -* keyword is special. It is used to indicate package
> > >>>> versions which are not worth trying to test on unlisted archs.
> > >>>>
> > >>>> Would changing it to read
> > >>>>
> > >>>> The -* keyword is special. It is used to indicate package
> > >>>> versions which are not for use on unlisted archs.
> > >>>>
> > >>>> Would that make it acceptable?
> > >>>
> > >>> Feel free to propose that to the QA team and / or the Gentoo
> > >>> Council.
> > >>
> > >> No changes are required. Everyone with 2 brain cells knows that -*
> > >> means "cannot work on other arches". Things like binary packages,
> > >> etc.
> > >
> > > And thus -* is not a solution to this thread.
> >
> > Agreed. If "slow arch" is causing issues, it would seem simple enough
> > to drop all the keywords except "slow arch" on the older ebuild. It
> > reduces maintenance burden while not breaking anyway.  Amazing how
> > the simple ones elude us sometimes.
>
> +1
>
> > >> Now, before you continue "discussing" this issue here on the list,
> > >> perhaps you should turn around and talk to the QA team about what
> > >> needs changed and discussed.
> > >
> > > +1
> > >
> > The goal of QA is to maintain the quality of the tree. Randomly
> > removing packages that are blocking closing bugs doesn't contribute
> > to tree quality, it degrades it.
>
> This discussion isn't about removing packages; it is about removing
> keywords or ebuilds, which doesn't break things if done properly.
>
> It can just as well improve tree quality, as it can remove creeping
> breakage; you can't black on white say whether it improves / degrades
> the tree quality, as there is too much involved in that. To put it in
> Jeroen's words "there's no simple policy for a complex problem" to some
> extent applies here; and hence you have to deal with "simple problems"
> as they appear, and then adapt policy (or the problem) to make a fit.
>
> So, I'm not convinced that it degrades it; can you show commits that do?
>
> Neither will you be convinced that it improves it yet; as the commits to
> show you still have to be made, we can at least agree that we can't
> determine together what really happens to the quality.
>
> I'm however convinced it will make our stabilization efforts of higher
> quality; as we move work from non-important to important business, in
> upper management terms, to reach more effective and efficient results.
>
> > I think we can all agree we are here to make gentoo better, so let's
> > work together instead of against each other.
>
> +1
>
> > No one is going to remove a stable ebuild for an arch without
> > discussion with the maintainer and following proper policy outlined
> > here:
> >
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html
>
> The policy is that it is at the maintainer's discretion; furthermore, I
> agree that workflow should be followed and not just a plain `rm ...` as
> that would put people as a surprise (and doesn't invite arch mentees).
>
> Consider this instead:
>
> # This last stable version has been masked on your architecture because:
> #
> #     Solid reason, bugs #1, #2, #3, ...
> #
> # To continue to stabilize this package on your architecture, we
> # currently run short in manpower to keep up with stabilizing it; if you
> # want to help us out, you can contact us at [reference: staffing page]
> # and read more about how arch testing works at [reference: arch
> testing].
>
> --
> 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: Type: text/html, Size: 13893 bytes --]

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 5 Feb 2014 19:04:56 -0800
Tyler Pohl <tylerapohl@gmail.com> wrote:

> why cant there be a second repository for all old source, ebuilds, and
> patches and the stable and testing repository can be rolling like it
> already is.  slower archs can then sync the old repository and the
> new one.

There is one in place, the Graveyard overlay; it hasn't had much succes:

http://gentoo.2317880.n4.nabble.com/Graveyard-overlay-was-Re-gentoo-dev-last-rites-games-strategy-x2-games-strategy-x2-demo-td258113.html

https://wiki.gentoo.org/wiki/Project:Graveyard

https://github.com/gentoo/graveyard

It needs someone to revive it and make it happen, anyone up?

PS; As a reminder, on mailing lists, consider to place your message
below of that what you quote; in personal e-mail it is to follow what
is being said as it is mostly a one-to-one conversation, however on
mailing lists people want to see what is being replied to and we
commonly read from top to bottom that way. My response is an example.

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

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Chris Reffett]

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

On 02/05/2014 09:50 PM, Tom Wijsman wrote:
> On Wed, 5 Feb 2014 20:50:07 -0500 Rich Freeman <rich0@gentoo.org>
> wrote:
> 
>> So, I realize I'm repeating myself, but the purpose of the
>> mailing list isn't to keep reposting the same arguments back and
>> forth until everybody agrees.  Post your argument once, and once
>> it gets dull by all means appeal to QA/council/whatever but the
>> bickering really doesn't add any value. For my part I promise not
>> to let it be a whoever-makes-the-most-noise-sets-the-policy
>> thing.  I appreciate the concerns, arguments, and alternatives
>> that were raised - they're helpful the first time they come up.
> 
> +1
> 
>> To add something new, can the QA team please figure out what
>> policy they actually intended to make and just communicate it?
>> Having QA team members and everybody else openly speculating
>> about what the policy is supposed to be on the list also adds no
>> value.
> 
> This is a misconception; Rick was absent during the meeting, we've 
> voted for it with 7 of 10, 1 person abstained, 2 were absent. A 
> majority thus wants the statement as it was written; which has 
> appeared fine up until the point that Rick addressed me in public
> with a misinterpretation of that policy (or might have been unaware
> of it), it's only after that point that it became clear of what I
> was asking Steev, that the current policy by the QA team is being
> misinterpreted.
> 
>> If the new policy does not in fact override the standard policy
>> then I'm not really sure what it is trying to say since it only
>> speaks to things that were already spoken to before, just in a
>> different way.
> 
> Exactly the point; note though to avoid confusion that there is a 
> difference between policy and workflow here. We should still use
> mask messages, if needed even news and more; and not just plain out
> `rm ...`.
> 
> However, just like you, I see no other way to read that policy than
> to override our existing policy that reads 'You should also not
> cause an unnecessary downgrade for any "~arch" when removing
> ebuilds - ...'
> 
> http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance
> 
> And to this extent I think Rick disagrees with the essence of it;
> but then again, there has also been mentions of improving the
> wording. Thus I don't really know if Rick wants to see it changed
> _or_ removed...; however, that'll become clear with more discussion
> and the meeting, which have happened, are happening and will happen
> on #gentoo-qa.
> 
>> Thanks for updating the policy webpage with the note that the
>> policy shouldn't be followed until clarified.
> 
> +1 for creffett doing that.
> 
>> One thing I haven't really seen in this thread is a better 
>> understanding of the demand for old version removal. I can 
>> understand the hypothetical issues having old versions creates.
> 
>> But is just WONTFIXing a bunch of old bugs a large burden in
>> practice?
> 
> It upsets stable users; and thinking of it, it doesn't get the
> actual stabilization problem across. Furthermore it is odd to show
> the user it is not maintained anymore while keeping that stable
> keyword and version around. Why mark it stable if the maintainer
> doesn't maintain it? Should it still be kept marked stable if the
> maintainer considers it to not really be stable? *"Hey you,
> maintainer, it acts a bit buggy!"*
> 
>> Before we create new problems by fixing old problems, I'd like to
>> get a sense for whether the old problems are actually problems.
>> I imagine this becomes a matter of degree - keeping a package
>> around for an extra 6-12 months probably isn't a big deal, but
>> when half the tree contains 6-year-old versions it is a problem.
> 
> We should reconsider 90 days in this respect, it might be a bit on 
> the low end; counting in years would indeed be more appropriate.
> 
> Note that maybe (just guessing) those 6-year-old versions don't
> really exist; but, if the stable queue continues to grow (it grows
> on average) like this over time they eventually will get to exist
> in the future.
> 
> And that'll come to be an actual problem; and to avoid scratching
> our heads by that time, it is nice to have our response in place in
> advance.
> 
> Quoting my meeting agenda questions of last time that reflect
> this:
> 
> "How do we evaluate whether future stabilization improves or 
> becomes worse? How bad is stabilization really at the moment? How 
> can we make more users and/or developers interested in arch
> testing (and/or Gentoo)? Do we want to make a policy change now, or
> delay considering it till a later meeting in the future? ...?"
> 
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda
>
> 
I really didn't want to get involved in this mess, but here goes:
- -Due to concerns about the wording of the policy, it is currently on
hold pending review at an upcoming QA team meeting.
- -Any further input/attempts at interpretation by QA team members at
this point would needlessly confuse the issue, therefore, I would
appreciate it if the QA team would stop trying to do so. We will have
a meeting, argue it there, and vote. Right now, all this arguing just
makes everyone more confused about what our opinion is.
- -I realize that our policy was unclear and may conflict with existing
policy on ebuild removal. I apologize for that, and will keep this
episode in mind in the future.

Chris Reffett
Gentoo QA Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLzAFBfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T76QCeOCFk8ClakUmKMqD0ldJEFQE2
kxkAn1Zw/6sSOghbc43KC4QEVzolYIvn
=+Pmi
-----END PGP SIGNATURE-----

[gentoo-dev] Re: dropping redundant stable keywords

[Duncan]

Steev Klimaszewski posted on Wed, 05 Feb 2014 10:55:59 -0600 as excerpted:

> There is far more to stabilizing than just closing the bugs.
> 
> I've been working for over 2 months now on the GNOME stabilization on
> ARM.  There has been a lot involved, including (but not limited to)
> rebuilding kernels for proper systemd integration, setting up systemd so
> that software would build (empathy won't build if systemd has no locale
> set (lol!) so much for systemd properly importing my settings from
> openrc) - building the software itself.  Realizing that some things were
> built against the GPU opengl implementation instead of mesa's
> implementation, having to rebuild that software, and all it's
> dependencies. Then the process of actually attempting to get it to run,
> tracking down the junk in the logs - figuring out which messages can be
> ignored, which ones are actual errors (why exactly is it throwing an
> error message if that message can be ignored?)
> 
> This is on multiple machines, because I'd like to cover softfp and
> hardfp.  This takes time.  Even if I were to build everything on my
> octa-core ARM server and just use the binpkgs, it still takes quite a
> bit of time to get through everything.  And this is JUST for the default
> useflags.
> 
> So you know what?  I'm sick of hearing about "slow arches" - there's a
> LOT of shit that we have to do to make sure things ACTUALLY WORK, and
> based on your emails, you either have NO IDEA what all is involved in
> alternate arch work, or you're purposely being obtuse about it.
> 
> 
> Now, we COULD do like Ubuntu, and just say if it builds, it's stable.
> But I personally am against that, maybe that's okay with you. We used
> Ubuntu on ARM devices at my last job - I'm intimately familiar with
> their practices.  We do not want to replicate that here in Gentoo land,
> or at least, I don't, not on ARM.  Feel free to look at all the GL based
> apps that they have available on armel - and test how many of them
> actually run on the hardware.

That *IS* a lot of work and you definitely have my respect for even 
/trying/ to carry it out.  But Tom's "burn out in increasingly 
unimportant workloads" seems apropos.

Which, given the continuing onslaught of stabilizations and the 
acknowledged bottleneck, eventually means something /must/, /WILL/ break.

Which is exactly what this thread is about.  Maintainers are actually 
seeing that breakage now as the backlogs get untenable.  So they're 
complaining.  Given the bottleneck and the continuing onslaught, it's 
/already/ broken.  The "will break" has for them become "now has broken".

The question then becomes what to do about that breakage, how to move it 
to the point of least disruption for gentoo as a whole.

Thus the proposal, on bottleneck archs drop stable keywords for 
"unimportant" packages, reducing the working set to something tenable and 
thus reducing the bottleneck, allowing those archs to focus more strongly 
on core packages with the idea of keeping them stable and relatively 
current, even if it comes at the cost of a much smaller stable set.  If 
the arch gets more resources in the future, it can expand that set, but 
right now it's an untenable bottleneck and /something/ must happen to 
break that bottleneck.  If it isn't this, the problem will get worse and 
worse until that /something/ gets much worse, perhaps triggering a drop 
of the entire arch to experimental.


The other alternatives include letting maintainers either reassign bugs 
for otherwise stale versions to the bottleneck arch in question, which 
just makes the problem worse as now the bottleneck has even MORE work 
piling up on it, or simply closing bugs filed against such stale versions 
as WONTFIX, perhaps with a note suggest the filer upgrade to something 
even half current, even if it's NOT stable on the arch and in fact is 
broken on the arch.

Unfortunately, that last option is the current de-facto default, except 
that without a formal policy, bugs often remain ignored or closed WONTFIX 
without a useful explanation.

IOW, for users and maintainers both the state is already broken, while 
arch-devs face an ever-increasing backlog and a bottleneck that's not 
going to get better.


Now I'm admittedly a bit biased as I'm a kde guy who wonders what sort of 
self-respecting "customization is king!" gentooer would want to run "our 
way is the ONLY CORRECT way and if you think otherwise you're just 
stupid!" gnome in the first place, case in point being this apparent 
systemd requirement, but I'd certainly personally consider an after all 
non-core optional package set requiring *THAT* much additional 
stabilization work a prime candidate for first exercise of that keyword 
dropping policy.  By your own statements that's two months of work for an 
optional non-core package set that you would have been able to skip, thus 
allowing you to focus more strongly on stabilizing other things, 
including gentoo's own default initsystem, openrc, which I think most 
would agree is otherwise a pretty core package, and this thread wouldn't 
have happened.

Of course an alternative to that, particularly if the arch-devs involved 
are gnome folks (or if there's specific gnome sponsorship, etc), would be 
to consider gnome part of core for that arch, thus effectively 
considering systemd core on that arch and dropping many/most other 
desktops and initsystems to non-core and likely ~arch-only.

With systemd now considered core as gnome is core for that arch and 
requires it, openrc would by definition then be non-core optional, and 
keywords could be dropped to ~arch, at which point again this thread 
wouldn't be happening.

The fact is arm does seem to be a bottleneck, and one way or another, 
facts "on the ground" will adjust to that.  At present, those facts on 
the ground are an enormous backlog and thus enormous pressure on the arm-
arch-devs and ATs, while both arm users and general package maintainers 
have an unsatisfactory experience as bugs on otherwise stale but 
unfortunately still latest stable packages on that arch remain unfixed 
and essentially unfixable.

The proposal simply adjusts to those current facts on the ground by 
allowing non-core packages to drop to ~arm, thus reducing the backlog and 
making /everyone/ happier, arm-arch devs and ATs because their backlog 
now reduces to something they can reasonably handle, general package 
maintainers and thus other arch users because those unfixed and unfixable 
bugs now get acknowledged as such and dropped off the radar, allowing for 
quicker progress elsewhere, and arm users because their actually marked 
stable package set better matches reality and they aren't dealing with 
all those bugs on supposedly stable packages.

There remains one loose end, however, the fact that ~arch packages can be 
dropped without notice, thereby likely dropping the only actually working 
package on an arch. =:^(

I'm not sure what to do about that.  Introducing another keyword level 
for it and giving archs veto power over dropping the last known working 
but otherwise labeled ~arch version, would very likely bring us back 
pretty fast to exactly this same spot with that other keyword, since we 
would have effectively simply relabeled the problem.

But I fail to see how that loose end is any worse than the current 
situation, since at least the ~arch keyword properly reflects the 
situation, that the arch in question simply doesn't have the resources 
necessary to properly support that package at anything like current 
versions, and old versions can always be pulled out of the attic if 
someone wants something that actually works even at the cost of no 
support.  Which is unfortunately pretty much what they're getting now, if 
the last stable version is so stale the maintainer isn't supporting it 
any longer and would drop it if he possibly could, except if a user has 
to pull it out of the attic to get it, he at least has truth in labeling 
about the support status, which is lacking with the supposedly stable 
keyworded version he'd be using now.

The only other alternative I can see would be effectively forking the 
gentoo tree into an arm-overlay, where all those stale arm keyworded 
packages can live on, supported by the people, including or even 
explicitly users, who care (this is actually what kde-sunset did, 
explicitly user-supported overlay, except that was obviously for a 
desktop package set, not an arch package set).  That's certainly possible 
as can be seen by the kde-sunset example, but has its own negatives.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: dropping redundant stable keywords

[Duncan]

Tom Wijsman posted on Thu, 06 Feb 2014 03:53:24 +0100 as excerpted:

> On Thu, 6 Feb 2014 03:12:54 +0100 Jeroen Roovers <jer@gentoo.org> wrote:
> 
>> On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski
>> <steev@gentoo.org> wrote:
>> 
>>> I'm attempting to have a discussion with a brick wall.
>> 
>> I hit that problem immediately in another sub-thread. Are we on to
>> something here?
> 
> Yes, we are; for more details: http://www.paulgraham.com/disagree.html

Thanks for the link.  Certainly thought provoking and I agree.  With it 
nicely laid out like that, I can now more concretely try to up the DH 
level of my own replies in the future. =:^)

(OTOH, acknowledging that this is in itself DH2/tone or DH0/name-calling, 
tho with a counterargument to a slightly different point so I guess it's 
DH4, I'm compelled to observe that repeatedly asking "Why?" as a one-word 
reply calls to mind the young child's constant "Why?" stage... a bit 
after they get past the earlier constant "NO!" stage...  As about any 
parent or children's care giver can certainly attest, it /does/ get 
frustrating at some point.  Perhaps you were simply trying to up the DH 
level, but in that case, something beyond "Why?" could have been useful.  
Arguably simply and repeatedly asking "Why?", without any indication even 
of what particular bit you're "whying", must be a parallel form of DH1 or 
at best DH2, ad hominem or tone.  Once was arguably useful, but after 
seeing it used multiple times in multiple replies, the usefulness was 
entirely gone and the single word question was no longer a useful 
contribution to the discussion.  Please reconsider that technique in the 
light of your above link before repetitive use in the future, and at 
least make it a useful sentence, not simply the one word, because 
especially when repeated, that single one word really does look childish 
and tends to increase frustration and reduce the quality of the 
discussion.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

[Tom Wijsman]

On Thu, 6 Feb 2014 05:21:51 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> (OTOH, acknowledging that this is in itself DH2/tone or
> DH0/name-calling, tho with a counterargument to a slightly different
> point so I guess it's DH4, I'm compelled to observe that repeatedly
> asking "Why?" as a one-word reply calls to mind the young child's
> constant "Why?" stage... a bit after they get past the earlier
> constant "NO!" stage...  As about any parent or children's care giver
> can certainly attest, it /does/ get frustrating at some point.
> Perhaps you were simply trying to up the DH level, but in that case,
> something beyond "Why?" could have been useful. Arguably simply and
> repeatedly asking "Why?", without any indication even of what
> particular bit you're "whying", must be a parallel form of DH1 or at
> best DH2, ad hominem or tone.  Once was arguably useful, but after
> seeing it used multiple times in multiple replies, the usefulness was
> entirely gone and the single word question was no longer a useful
> contribution to the discussion.  Please reconsider that technique in
> the light of your above link before repetitive use in the future, and
> at least make it a useful sentence, not simply the one word, because
> especially when repeated, that single one word really does look
> childish and tends to increase frustration and reduce the quality of
> the discussion.)

There's only a single occurrence of a single-word "Why?" without
any other question on the line, there is another single occurence of a
single-word "Why?" with a long "How ...?" on the same line; it was not
used repetitively, and the "Why?" on its own is made when we're down a
DH in this thread that's already extremely low in which point my DH
isn't any more disrespectful than its context. However, pointing this
single occurrence out in its own as well as nitpicking on it together
is something I'd like to avoid here; let me instead just point out that
most occurrences of those questions were in full text. And if we can't
ask questions in full text anymore; then, I'm unable to see how a
discussion can be held at all. Fwiw, the very same person I made that
single one-word "Why?" to has previously appreciated that I asked him.

You are welcome to point out where you think that I went to a lower DH;
but when you do, please do it in private as to avoid extra noise. At
least when we're talking here about doing this after the fact; when a
natural discussion is ongoing, a proper respectful disagreement is of
course welcome in which case you can do it in public with us. As long
as it addresses the central point of the discussion...

I've been considering a while not responding to messages of lower DH;
just like the message you have jut made, but in doing so that would
even be more disconstructive than to constructively try to make the
best out of the thread. Some people will see this discussion as popcorn
material, and rather useless; but out of this and the IRC communication
that happened afterwards we've got at least (thanks to Rick):

 1) clear there's a misunderstanding;

 2) it being discussed and voted on again at the next Gentoo QA meeting;

 3) Steev got to a discussion with the arm team, which lead to the idea
 to evaluate the usefulness of the stages and more;

and there'll be more to come, to realize and to move Gentoo forward on.

Consider what would have happened if we didn't go this far? It's scary.

PS: Wrt. your other long response, I agree with a very large part of it.

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

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

[Peter Stuge]

Please stop writing so many and so long emails.

Tom Wijsman wrote:
> Fwiw, the very same person I made that single one-word "Why?" to
> has previously appreciated that I asked him.

You can not extrapolate from that, and can certainly not assume that
I will appreciate that you ask "Why?" in response to something I
express later.

English isn't my first language, but for me it's utterly impossible
to know what exactly your "Why?" refers to.

That's a very basic failure in communication. I hope that makes sense.

The value per email byte is plummeting toward zero. :\ Look for a
different approach?


//Peter

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

[Tom Wijsman]

On Thu, 6 Feb 2014 09:47:37 +0100
Peter Stuge <peter@stuge.se> wrote:

> Please stop writing so many and so long emails.
> 
> Tom Wijsman wrote:
> > Fwiw, the very same person I made that single one-word "Why?" to
> > has previously appreciated that I asked him.
> 
> You can not extrapolate from that, and can certainly not assume that
> I will appreciate that you ask "Why?" in response to something I
> express later.

There is no extrapolation intended; this has actually happened, hence it
is appropriate to use it as it referred to that previous question.

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

Re: [gentoo-dev] Re: dropping redundant stable keywords

[Tom Wijsman]

On Wed, 5 Feb 2014 13:07:48 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Tom Wijsman posted on Wed, 05 Feb 2014 13:58:22 +0100 as excerpted:
> 
> > Can we do something about our growing queue when fixing is
> > insufficient?
> > 
> > https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap
> > 
> > PS: As a bonus, here's a nice view of our stabilization queue over
> > time:
> > 
> > https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List
> > 
> > Notice how the graph goes down near the dates the threads were made;
> > although, if you would draw an average it would appear to be
> > growing.
> 
> Both those links give me this:
> 
> Sorry, you aren't a member of the 'editbugs' group, and
> so you are not authorized to use the "New Charts" feature. 
> 
> =:^(
> 

http://dev.gentoo.org/~tomwij/files/bgo-all-open-bugs.png
http://dev.gentoo.org/~tomwij/files/bgo-all-open-key-and-stable.png

Hmm, I think that certain usage of it can cause quite a server load;
and that because of that this is in place, perhaps even by default.

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

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

[Peter Stuge]

Tom Wijsman wrote:
> > > Fwiw, the very same person I made that single one-word "Why?" to
> > > has previously appreciated that I asked him.
> > 
> > You can not extrapolate from that, and can certainly not assume that
> > I will appreciate that you ask "Why?" in response to something I
> > express later.
> 
> There is no extrapolation intended;

Thanks for clarifying that!


> this has actually happened,

Yep.


> hence it is appropriate to use it as it referred to that previous question.

Mh no not neccessarily.

Recounting it the way you did in the context where you did makes it
sound like you expect it to mean something also for more recent
events. (Otherwise recounting it would add nothing but noise, which I
think noone really wants to think that you (or anyone else) would do.)

I understand that you did not intend this now that you've clarified,
but you should also understand that this is how it sounded - possibly
not just to me.

Again, communication problem. :\


//Peter

[gentoo-dev] Re: dropping redundant stable keywords

[Duncan]

Tom Wijsman posted on Thu, 06 Feb 2014 11:10:53 +0100 as excerpted:

> On Wed, 5 Feb 2014 13:07:48 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Tom Wijsman posted on Wed, 05 Feb 2014 13:58:22 +0100 as excerpted:
>> 
>> > Can we do something about our growing queue when fixing is
>> > insufficient?
>> > 
>> > [snip privileged link, see pngs links below] 
>> > 
>> > PS: As a bonus, here's a nice view of our stabilization queue over
>> > time:
>> > 
>> > [another]
>> > 
>> > Notice how the graph goes down near the dates the threads were made;
>> > although, if you would draw an average it would appear to be growing.
>> 
>> Both those links give me this:
>> 
>> Sorry, you aren't a member of the 'editbugs' group, and so you are not
>> authorized to use the "New Charts" feature.
>> 
>> =:^(
>> 
>> 
> http://dev.gentoo.org/~tomwij/files/bgo-all-open-bugs.png
> http://dev.gentoo.org/~tomwij/files/bgo-all-open-key-and-stable.png
> 
> Hmm, I think that certain usage of it can cause quite a server load;
> and that because of that this is in place, perhaps even by default.

Very likely.  Thanks for the pngs. =:^)

It's worth noting specifically for those not too detail observant that 
the dates graphed are much different.

The bgo-all-open-bugs graph is from late 2003 to the present, just over a 
decade, and shows a general increase in open bugs from 4000 (the graph's 
y-axis zero-point) in late 2003, to 20K today, with a dip in 2006 and 
2007.

The bgo-all-open-key-and-stable graph is over a much shorter period, 
April 2011 to today so not quite three years, with the beginning date 
presumably an upgrade from an earlier bugzilla version without the 
necessary tracking data, or possibly introduction of the keywords 
tracked.  It starts at zero in April 2011 and rises quickly to ~400 bugs 
in late November of that year (2011), which a quick eyeballing suggests 
as the earliest point at which it /might/ be accurate, since previous to 
that most bugs were presumably without the necessary tracking data.  The 
peak is a couple months later, 1200 bugs, in January 2012.  Presumably 
it's reasonably accurate by then at the latest.  The current number would 
appear to be ~675.

Which leaves us basically two years of accurate tracking data on the key-
and-stable graph.  And barring the intro period before Nov 2011 when it 
clearly couldn't have been accurate yet, what jumps out at me is that 
unlike the all-open-bugs graph (which grew from just over 18K to peak at 
just over 20K and then drop down very slightly to perhaps 19,950 today, 
thus growing by nearly 2000 bugs in two years, about a thousand a year, a 
bit slower than the ~1600/year average over the decade), the keyword-and-
stable graph is a lot more volatile with a lot of vertical lines of ~300 
bugs (a quarter of the graph height of 1200 bugs!) at a time, but...

... actually seems rather stable at a near 600 bug center-graph average!

So while we clearly have a long-term trend of +1600 open bugs per year 
overall over the last decade and somewhat under that, +1000 each the last 
couple years, keyword/stablizations bugs are far more volatile over the 
shorter two-year period we can assume we have reasonably accurate data 
for, but to the extent a trend can be seen at all in the very noisy data 
over the short two-year period, it appears pretty flat-lined. If 
anything, the trend over the first year was down while the trend over the 
second has been up, but given the size of the verticals and the fact that 
our current ~675 is just over half the 1200 peak, there's really just not 
enough data yet to see a clear trend, and any trend that might be seen 
could just as easily be interpreter's bias.

That's a bit surprising given the topic of this thread.  I'd have 
expected at least /some/ upward trend.  Tho honestly, two years simply 
isn't enough history to tell, given the quarter-graph verticals.

Now what /might/ be interesting is a similar graph of keyword/stable bugs 
open say 90+ days.  I'd say 180+ too, but at two years of reliable data, 
that'd only give us a year and a half of 180+ to work with, 3X the 180 
day, which is very likely simply EINSUFFICIENTDATA.

Meanwhile, any idea what the explanation is for the drop in the all-open-
bugs graph in 2006 and 2007?  The only thing that comes to mind here is 
that it might be the effect of tree-cleaners getting to work?  Does that 
match their timing and work?  If so, WOW! =:^)  But then what happened in 
2008 that lead to a 4K increase in open bugs in one year? =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[William Hubbs]

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

On Thu, Feb 06, 2014 at 01:48:38AM +0100, Tom Wijsman wrote:
> On Wed, 05 Feb 2014 17:05:08 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
> > > 
> > > Yes, making the newest versions never available because the old
> > > versions sink all your time really stops progress to a dead halt.
> > > 
> > 
> > Your logic isn't flawed here, it's entirely missing.  If version Y is
> > stable on all arches but one, and that version is still using version
> > X that doesn't affect any of the other arches at all.
> 
> Can this be proven? Why are maintainers like WilliamH upset about this?
> 
> Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063

I was mostly upset because of the appearance of inaction by the arch
teams. In my specific case, it wasn't the arm guys I was talking about [1].
arm was stable within the first month of adding to the bug.

I was very concerned because of how long this bug sat in the stable
queue with no action being taken, especially since other important
packages depended on it.

William

[1] https://bugs.gentoo.org/show_bug.dgi?id=487332

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

[gentoo-dev] Re: dropping redundant stable keywords

[Duncan]

William Hubbs posted on Thu, 06 Feb 2014 12:26:08 -0600 as excerpted:

> [1] https://bugs.gentoo.org/show_bug.dgi?id=487332

s/dgi/cgi/  Try this one:

https://bugs.gentoo.org/show_bug.cgi?id=487332

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Re: Re: dropping redundant stable keywords

[Steven J. Long]

On Wed, Feb 05, 2014 at 01:08:33AM +0100, Tom Wijsman wrote:
> On Tue, 4 Feb 2014 21:03:20 +0000
> "Steven J. Long" wrote:
> 
> > Tom Wijsman wrote:
> > 
> > > They are less work; since it lets the slower arches move their work
> > > to bugs of important packages that need their attention, instead of
> > > bugs of non-important packages were the stabilization isn't really
> > > necessary.
> > 
> > Huh? The slower arch is not keeping up with stabilisation. How can the
> > stabilisation suddenly be unnecessary? If it is not needed, there is
> > no problem, and we wouldn't be having this discussion.
> 
> It is still necessary, as clear from the difference in importance.
> 
> > Much better for the arch in question to field the bug, than tell the
> > user there is no problem, and we don't care. That way you can get the
> > user involved in stabilisation and AT via that bug, instead of turning
> > them away with priggishness.
> 
> Problems should be visible instead of hidden, as well as resolved. A
> move in work means a move in work, further implications are yours...

Very gnomic: nothing's being hidden in the above approach. I can't make
sense of the rest so I'll move on, noting only that it's up to the arch
team, as to what _they_ decide to kick back to unstable. And that can
work without a problem if we have a mechanism in place to relieve
maintainers of those bugs. Personally I'd do it after 45 days to speed
things up, and let the ATs concerned, take the bug as and when (eg
turn the stabilisation into a tracker for the slow archs concerned, if
there are multiple.)

> > > > The arguments and headaches at the user, bug
> > > > and AT sides are causing more work (or detracting from real work)
> > > > too.
> > > 
> > > Yes, the less work that we can do, the more work the user has to do
> > > as a natural consequence; discussions like these are there to
> > > prevent those headaches way in advance, as we can proper adapt
> > > and/or respond to the situation. And if needed, bring out news such
> > > that the user is well informed. Not sure which argumentation this
> > > is about though.
> > 
> > Perfectly simple: instead of having this row repeatedly, or borking
> > archs, let's use the solution proposed by the ARM AT: provide a
> > technical reason why it won't work, rather than a conceptual problem
> > with the "hack".
> 
> Searching for such technical reasoning is a leeway for hacking & hoping.

Er what?
 
> Solutions were provided, a policy has been made; we are exactly
> avoiding to row repeatedly, and this is yet another solution I propose:
> 
> Provide a technical reason why it will work?

You have colons after a "solution I propose:" with nothing after it.
Kinda sums up your discussion for me. And your answer to "tell us what it
breaks" is "tell us why it works?" Pfft.

> You further demonstrate this solution that I propose we should use:
> 
> > The history of computing is littered with hacks that turned out to
> > shed new light on a problem: it's called exploring the problem
> > domain. It's only when you have idiomatic knowledge of the
> > language/tools *and* the specific domain, that you can envision
> > oddball solutions and more importantly _know_ that they will work
> > (perhaps with a bit of tweaking.)
> 
> It is called prototyping.

That's just another word: "exploring the problem domain" is much more
useful to keep in mind. Similar to how "Keep it Simple (and) Stupid"
is much more useful while coding, than:
"It is more important to make the purpose of the code unmistakable
than to display virtuosity. The problem with obscure code is that
debugging and modification become much more difficult, and these are
already the hardest aspects of computer programming."
  (Kernighan and Plauger, 1976)

..although the latter is still worth reading/knowing about.

> > Further, the solution steev brought up is much much better than
> > simply dropping the ebuild.
<snip>
> "The -* keyword is special. It is used to indicate package versions
> which are not worth trying to test on unlisted archs." [1]

Finally: some actual content.

> You can keep rehashing about "winning", but all it does is break policy.

*sigh*
The wonderful thing about policy is that it reflects (or is supposed to)
consensus opinion with light to contemporaneous circumstance. Since
circumstances change, so too must policy be open to change or
adaptation, in line with basic principles. So let's look at extending
it, since there is *no* technical problem:

'The redundant -* keyword is a metadata marker. It is used to indicate,
in line with the semantic of "strip all", that the ebuild in question
can only be used for the specific archs noted for one of two reasons:

1) The package-maintainer has stabilised a newer version on at least one
arch personally, the ATs for the archs listed have taken longer than
XX days to test and stabilise, and the maintainer would otherwise drop
the ebuild altogether.

2) The package version is not worth trying to test on unlisted archs.'

The policy which flows from that is:

'In the first case, it is QA policy that a comment of the form:
# STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN
is required on the line immediately above the KEYWORDS declaration.

This is to aid both automated identification, and human collaboration.'

(The latter explains why a URL, not a bug id, is required. We're trying
to get end-users to help us, so let's make it easy for them.)

I'd personally add:
'It is envisaged that the line will be added by an automated tool at
some point.'

..as well as a requirement for a bug id in the second case, but I
don't know it well enough; I'd certainly want some sort of tracking.

It's hardly an onerous requirement, and a small price to pay: if
we have a policy for how a maintainer drops an ebuild from his
queue due to it being stabilised, which we can trigger scripts
from, we avoid the arguments every year or so, and stop archs from
being borked. We can also speed it up, since we have a mechanism
in-place to support it, as opposed to ad-hoc, flawed decision-making.

The thing I think that's missing from this debate, is an
acknowledgement, or an understanding, that arch-teams are all
effectively working on their own variant of the shared Gentoo tree.
(This includes the concept of upgrades working as smoothly as they
do on other archs, at the PM level.) Similar to other portability
efforts, the tree must support them in that, not make it harder.

Especially not because another developer doesn't care about the arch
in question. That's *natural*, but _cannot_ be cause for dropping
stable ebuilds. The only issue is to take the bugs off their hands,
and we can do that with a simple tweak in metadata, so ffs let's
get on and do it.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: dropping redundant stable keywords

[Tom Wijsman]

On Thu, 13 Feb 2014 21:28:18 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> > > Much better for the arch in question to field the bug, than tell
> > > the user there is no problem, and we don't care. That way you can
> > > get the user involved in stabilisation and AT via that bug,
> > > instead of turning them away with priggishness.
> > 
> > Problems should be visible instead of hidden, as well as resolved. A
> > move in work means a move in work, further implications are yours...
> 
> Very gnomic: nothing's being hidden in the above approach.

Filing a bug but not telling the user about it is hiding the problem.

> I can't make sense of the rest so I'll move on, noting only that it's
> up to the arch team, as to what _they_ decide to kick back to
> unstable.

They need manpower to decide it, which they don't have.

> And that can work without a problem if we have a mechanism
> in place to relieve maintainers of those bugs.

Such mechanism could be to assign those bug to the arch team, this idea
came up at FOSDEM; it won't solve the lack of manpower, but it will at
least relieve the maintainers and make the problem more visible.

> Personally I'd do it after 45 days to speed things up, and let the
> ATs concerned, take the bug as and when (eg turn the stabilisation
> into a tracker for the slow archs concerned, if there are multiple.)

Since this is a soft measure I've seen a lot of people want the time to
be longer; if it still continues to be a problem, then shortening it
might be a solution but I think we'll want to avoid a too hard approach
for now. 45 days are over before you know it...

The part about ATs taking the bug sounds like what came up at FOSDEM. +1

> > > > > The arguments and headaches at the user, bug
> > > > > and AT sides are causing more work (or detracting from real
> > > > > work) too.
> > > > 
> > > > Yes, the less work that we can do, the more work the user has
> > > > to do as a natural consequence; discussions like these are
> > > > there to prevent those headaches way in advance, as we can
> > > > proper adapt and/or respond to the situation. And if needed,
> > > > bring out news such that the user is well informed. Not sure
> > > > which argumentation this is about though.
> > > 
> > > Perfectly simple: instead of having this row repeatedly, or
> > > borking archs, let's use the solution proposed by the ARM AT:
> > > provide a technical reason why it won't work, rather than a
> > > conceptual problem with the "hack".
> > 
> > Searching for such technical reasoning is a leeway for hacking &
> > hoping.
> 
> Er what?
>  
> > Solutions were provided, a policy has been made; we are exactly
> > avoiding to row repeatedly, and this is yet another solution I
> > propose: Provide a technical reason why it will work?
>
> Kinda sums up your discussion for me. And your answer to "tell us
> what it breaks" is "tell us why it works?" Pfft.

We are searching for solutions that work.

> > You further demonstrate this solution that I propose we should use:
> > 
> > > The history of computing is littered with hacks that turned out to
> > > shed new light on a problem: it's called exploring the problem
> > > domain. It's only when you have idiomatic knowledge of the
> > > language/tools *and* the specific domain, that you can envision
> > > oddball solutions and more importantly _know_ that they will work
> > > (perhaps with a bit of tweaking.)
> > 
> > It is called prototyping.
> 
> That's just another word: "exploring the problem domain" is much more
> useful to keep in mind.

We already know the problem, thus it is rather just called prototyping.

> > > Further, the solution steev brought up is much much better than
> > > simply dropping the ebuild.
> <snip>
> > "The -* keyword is special. It is used to indicate package versions
> > which are not worth trying to test on unlisted archs." [1]
> 
> Finally: some actual content.

It works.

> > You can keep rehashing about "winning", but all it does is break
> > policy.
> 
> *sigh*
> The wonderful thing about policy is that it reflects (or is supposed
> to) consensus opinion with light to contemporaneous circumstance.
> Since circumstances change, so too must policy be open to change or
> adaptation, in line with basic principles.

In this case -* works fine for what it intends to work; changing the
policy to redefine it to fit another purpose, while no longer
reflecting its original purpose is what we should avoid at all cost.

> So let's look at extending it, since there is *no* technical problem:

You have colons after the above quoted sentence with nothing after it.

(An eye for an eye... :D)

> 'The redundant -* keyword is a metadata marker.

The keyword has a meaning, therefore it is not redundant.

> It is used to indicate, in line with the semantic of "strip all",
> that the ebuild in question can only be used for the specific archs
> noted for one of two reasons:
> 
> 1) The package-maintainer has stabilised a newer version on at least
> one arch personally, the ATs for the archs listed have taken longer
> than XX days to test and stabilise, and the maintainer would
> otherwise drop the ebuild altogether.
> 
> 2) The package version is not worth trying to test on unlisted archs.'

(1) changes its meaning in a way that you can no longer interpret the
keyword solely as (2). The whole purpose of (2) is that you can
interpret it that you should not test it as it was found not to work;
(1) is different from that, as it means that there was no manpower to
test it. (1) would move ebuilds to -* and be misinterpreted as (2).

> The policy which flows from that is:
> 
> 'In the first case, it is QA policy that a comment of the form:
> # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN
> is required on the line immediately above the KEYWORDS declaration.
> 
> This is to aid both automated identification, and human
> collaboration.'
> 
> (The latter explains why a URL, not a bug id, is required. We're
> trying to get end-users to help us, so let's make it easy for them.)
>
> I'd personally add:
> 'It is envisaged that the line will be added by an automated tool at
> some point.'
> 
> ..as well as a requirement for a bug id in the second case, but I
> don't know it well enough; I'd certainly want some sort of tracking.

This yields extra commits; comments in ebuilds are directed towards
maintainers, for users we should use another approach to contact them.

> It's hardly an onerous requirement, and a small price to pay: if
> we have a policy for how a maintainer drops an ebuild from his
> queue due to it being stabilised, which we can trigger scripts
> from, we avoid the arguments every year or so, and stop archs from
> being borked. We can also speed it up, since we have a mechanism
> in-place to support it, as opposed to ad-hoc, flawed decision-making.
> 
> The thing I think that's missing from this debate, is an
> acknowledgement, or an understanding, that arch-teams are all
> effectively working on their own variant of the shared Gentoo tree.
> (This includes the concept of upgrades working as smoothly as they
> do on other archs, at the PM level.) Similar to other portability
> efforts, the tree must support them in that, not make it harder.
> 
> Especially not because another developer doesn't care about the arch
> in question. That's *natural*, but _cannot_ be cause for dropping
> stable ebuilds. The only issue is to take the bugs off their hands,
> and we can do that with a simple tweak in metadata, so ffs let's
> get on and do it.

+1 on this thought.

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

Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Fri, 14 Feb 2014 19:59:58 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> > And that can work without a problem if we have a mechanism
> > in place to relieve maintainers of those bugs.
> 
> Such mechanism could be to assign those bug to the arch team, this
> idea came up at FOSDEM; it won't solve the lack of manpower, but it
> will at least relieve the maintainers and make the problem more
> visible.

Assigning bugs so arch teams is cosmetic at best. Also note that it
used to be that way long ago, and it didn't do any good for anyone
involved. It really doesn't matter who is assigned a bug report, as
long as it's not a (theoretically) transiently involved party like an
arch team on a stabilisation bug.

Recently I've seen a few keywording/stabilisation bug reports assigned
to arch teams again. It's really annoying. If you've started doing
this, then please stop before people start to think it's a good idea.
It's not.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sat, 15 Feb 2014 01:28:55 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Fri, 14 Feb 2014 19:59:58 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > > And that can work without a problem if we have a mechanism
> > > in place to relieve maintainers of those bugs.
> > 
> > Such mechanism could be to assign those bug to the arch team, this
> > idea came up at FOSDEM; it won't solve the lack of manpower, but it
> > will at least relieve the maintainers and make the problem more
> > visible.
> 
> Assigning bugs so arch teams is cosmetic at best.

While it was not explained here, the idea can also move the actual
maintenance of the ebuild to the arch team; such that it becomes the
arch team's responsibility to deal with it, or rather don't deal with
it and have it act as a nagging reminder that stabilization really is
due. This also reflects the importance of the package, as it will
receive more attention and thus be more verbose towards the arch team.

> Also note that it used to be that way long ago, and it didn't do any
> good for anyone involved.

Did it involve a shift in maintenance back then?

> It really doesn't matter who is assigned a bug report, as long as
> it's not a (theoretically) transiently involved party like an arch
> team on a stabilisation bug.
> 
> Recently I've seen a few keywording/stabilisation bug reports assigned
> to arch teams again. It's really annoying. If you've started doing
> this, then please stop before people start to think it's a good idea.
> It's not.

Depends on what the arch teams think of this; but considering that
these are old ebuilds are the responsibility of the arch team (as they
keep them in place), you should note that they will eventually cause
the arch team to get contacted about those bus anyway in one way or
another sooner or later. Not doing this myself; but I think that people
might have started doing this, after seeing it pass by after FOSDEM on
the #gentoo-dev IRC channel (or because they consider it common sense).

Thank you for your opinion on this (as you are an arch team member).

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> > Assigning bugs so arch teams is cosmetic at best.

s|so|to|

> While it was not explained here, the idea can also move the actual
> maintenance of the ebuild to the arch team; such that it becomes the
> arch team's responsibility to deal with it, or rather don't deal with
> it

How would that ever work? You have some old cat/pkg/pkg-version.ebuild
that you no longer want to maintain, but which happens to be the latest
stable for $ARCH, which is apparently understaffed because they $ARCH
hasn't tended to a related bug report in months, and now you want to
leave the ebuild in place and also expect $ARCH to start maintaining
it? How does $ARCH have the man power to do that, again?

> and have it act as a nagging reminder that stabilization really is
> due. This also reflects the importance of the package, as it will
> receive more attention and thus be more verbose towards the arch team.

No, you're wrong there. Nobody is reading those bugzilla e-mails -
nobody is working on keywording/stabilisation for $ARCH. "Nagging" is
pointless when nobody hears you, and an e-mail from bugzilla isn't
magically better prioritised when Assignee: changes.

The only reasonable course of action is to start dropping stable
keywords for $ARCH, after a reasonable timeout. It gets tricky if this
involves removing many keywords on dependencies, but if that's what you
have to do to keep cat/pkg (and eclasses and profiles) in shape, then
by all means _help_ _out_ $ARCH by doing it for them. If that means
removing stable/unstable support for an entire DM or scripting
framework, then so be it.

As long as @system is keyworded properly (by which I really really
really mean something better than a "compile only" test - you know who
you are), $ARCH users will normally be able to figure out how to emerge
unstable packages themselves.

> > Recently I've seen a few keywording/stabilisation bug reports
> > assigned to arch teams again. It's really annoying. If you've
> > started doing this, then please stop before people start to think
> > it's a good idea. It's not.
> 
> Depends on what the arch teams think of this

No, it doesn't. Package maintainers are responsible for their bug
reports, and Assignee: should reflect that.

Maintaining a stable tree for an arch team means that someone on that
team needs to do more than scratch their own itches - slacking should
be fixed by relieving their burden, not pile on more, because that's
precisely how volunteer work ultimately doesn't get done.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Pacho Ramos]

El sáb, 15-02-2014 a las 14:30 +0100, Jeroen Roovers escribió:
[...]
> The only reasonable course of action is to start dropping stable
> keywords for $ARCH, after a reasonable timeout. It gets tricky if this
> involves removing many keywords on dependencies, but if that's what you
> have to do to keep cat/pkg (and eclasses and profiles) in shape, then
> by all means _help_ _out_ $ARCH by doing it for them. If that means
> removing stable/unstable support for an entire DM or scripting
> framework, then so be it.

I agree with this... but, if I don't misremember, there are others that
don't want to do this :/ From the big Gnome 3.8 bug, I have noticed that
we can only handle easily amd64 and x86. Probably arm in the future (at
least Steev if putting lots of effort to trying to test it at runtime on
his ARM devices... but it looks to be pretty hard). With ia64 I was able
to find an arch tester that is helping really a lot, but for the rest of
arches... (ppc, ppc64, alpha, sparc), I have been unable to even find
arch testers that could help.

Personally, I think that, before starting to discuss what to do with
"uncommon" arches we would need to decide how to test things on this
arches:
- Compile test only -> if we agree on this, probably the current
situation can be kept a bit more
- Runtime test required -> this will for sure need to start to dropping
lots of packages to "testing only".

I am not strongly in favor of any of them but I think we need to agree
on what to do. Current situation is like a ugly mix: bugs are piled for
a long long time until some people goes ahead and does the compile test
only. And I think they do what probably is the current only way to do
until we decide what kind of testing we want for this more "exotic"
arches.

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Rich Freeman]

On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
>
>> While it was not explained here, the idea can also move the actual
>> maintenance of the ebuild to the arch team; such that it becomes the
>> arch team's responsibility to deal with it, or rather don't deal with
>> it
>
> How would that ever work? You have some old cat/pkg/pkg-version.ebuild
> that you no longer want to maintain, but which happens to be the latest
> stable for $ARCH, which is apparently understaffed because they $ARCH
> hasn't tended to a related bug report in months, and now you want to
> leave the ebuild in place and also expect $ARCH to start maintaining
> it? How does $ARCH have the man power to do that, again?

Many objected to removal since old with minor issues is better than
new that doesn't work at all on some archs, or so the argument goes.

This thread has gone on for a while, but at least this is a new suggestion.

If we were torn between these two options (removal or re-assignment),
then we could potentially leave the decision up to the arch team.  If
they speak up they can get bugs assigned to them, and if they don't
speak up they get their stable packages removed.

And I'm all for other options, but beyond more manpower I'm just not
seeing anything that is going to be pretty.

> Nobody is reading those bugzilla e-mails - nobody is working on
> keywording/stabilisation for $ARCH. "Nagging" is pointless when
> nobody hears you, and an e-mail from bugzilla isn't
> magically better prioritised when Assignee: changes.

I think the point is that the maintainer doesn't see the nags.  If
nobody else sees them either it is "somebody else's problem" from
their standpoint.  That isn't going to make the bug submitter very
happy, but if removal of the only version of a package that works on
their arch entirely is the alternative I suspect they will live with
it, or better still join the arch team.

Removing the package version entirely is the tidy solution from a
tracking/bugs/etc standpoint. The problem is that for the end user it
might mean taking away something that at least somewhat works and
leaving them with nothing.  Fixing the new version probably isn't an
option if somebody isn't willing to step up, so the question is just
whether we keep around the old version.  The new suggestion is to keep
it around, but not to bug the maintainer with the resulting issues.

If an old version gets to the point where it is simply unusable it
should almost certainly be dropped.  That at least avoids constantly
pestering the bug wranglers/etc with dups, and gives the arch team a
bug list where at least they have some hope of doing something.

Rich

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[William Hubbs]

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

On Sat, Feb 15, 2014 at 11:41:57AM +0100, Tom Wijsman wrote:
> On Sat, 15 Feb 2014 01:28:55 +0100
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
> > On Fri, 14 Feb 2014 19:59:58 +0100
> > Tom Wijsman <TomWij@gentoo.org> wrote:
> > 
> > > > And that can work without a problem if we have a mechanism
> > > > in place to relieve maintainers of those bugs.
> > > 
> > > Such mechanism could be to assign those bug to the arch team, this
> > > idea came up at FOSDEM; it won't solve the lack of manpower, but it
> > > will at least relieve the maintainers and make the problem more
> > > visible.
> > 
> > Assigning bugs so arch teams is cosmetic at best.
> 
> While it was not explained here, the idea can also move the actual
> maintenance of the ebuild to the arch team; such that it becomes the
> arch team's responsibility to deal with it, or rather don't deal with
> it and have it act as a nagging reminder that stabilization really is
> due. This also reflects the importance of the package, as it will
> receive more attention and thus be more verbose towards the arch team.

The problem with this is, what if it is more than one arch team? Which
one do you assign it to?

If we want a separate assignee for old stabilizations, what about a
separate project that handles this, or maybe we could assign the bugs to
m-n or something until the arch teams catch up?

William


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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[William Hubbs]

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

On Sat, Feb 15, 2014 at 02:30:21PM +0100, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > > Assigning bugs so arch teams is cosmetic at best.
> 
> s|so|to|
> 
> > While it was not explained here, the idea can also move the actual
> > maintenance of the ebuild to the arch team; such that it becomes the
> > arch team's responsibility to deal with it, or rather don't deal with
> > it
> 
> How would that ever work? You have some old cat/pkg/pkg-version.ebuild
> that you no longer want to maintain, but which happens to be the latest
> stable for $ARCH, which is apparently understaffed because they $ARCH
> hasn't tended to a related bug report in months, and now you want to
> leave the ebuild in place and also expect $ARCH to start maintaining
> it? How does $ARCH have the man power to do that, again?
 
 This is a good question; they probably don't.

> > and have it act as a nagging reminder that stabilization really is
> > due. This also reflects the importance of the package, as it will
> > receive more attention and thus be more verbose towards the arch team.
> 
> No, you're wrong there. Nobody is reading those bugzilla e-mails -
> nobody is working on keywording/stabilisation for $ARCH. "Nagging" is
> pointless when nobody hears you, and an e-mail from bugzilla isn't
> magically better prioritised when Assignee: changes.
> 
> The only reasonable course of action is to start dropping stable
> keywords for $ARCH, after a reasonable timeout. It gets tricky if this
> involves removing many keywords on dependencies, but if that's what you
> have to do to keep cat/pkg (and eclasses and profiles) in shape, then
> by all means _help_ _out_ $ARCH by doing it for them. If that means
> removing stable/unstable support for an entire DM or scripting
> framework, then so be it.

This was my thinking when I started this thread, but the other side is
that once something is stable it shouldn't be touched until A newer
version of the package is stable.

As a maintainer, my thought is like this. If an arch team stabilizes a
version of a package I maintain, they are now committed to stabilizing
newer versions of that package in a reasonable time of when I request
them, or they need to respond to the stabilization bug within a
reasonable amount of time and tell me why they can't stabilize the newer
version so we can fix it. If they can't do either of these things, the
package doesn't need to be stable on their arch.

William


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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs <williamh@gentoo.org> wrote:

> The problem with this is, what if it is more than one arch team? Which
> one do you assign it to?

Oh the fun we had in the past when bugs got assigned to one arch team
with a few others CC'd and no maintainer in sight (because maybe the
maintainer was the reporter, or was blanky assumed to be known). Or when
another arch alias got CC'd later on. Or when a maintainer got fed up
waiting and reassigned to an arch team in a "rage quit". And so on. It
makes very messy bug reports. Musical chairs, anyone?

> If we want a separate assignee for old stabilizations, what about a
> separate project that handles this, or maybe we could assign the bugs
> to m-n or something until the arch teams catch up?

Again, where is the man power for that? :-)

It's the maintainers that this problem hurts most, so they could and
should be fixing it themselves - after a few months of waiting,
reminding arch teams and gritting your teeth over it, just remove the
old stable ebuilds[1].


     jer


[1] Where possible. If this happens with non-dev, non-experimental
    architectures and keeping the old ebuilds is a real problem, the
    architecture's status should be reconsidered. As has been done on
    this mailing list time and again. If an arch team cannot even be
    bothered to keep @system up to date, then why bother pretending
    it's anywhere near "stable"?

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[William Hubbs]

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

On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 16:53:22 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > The problem with this is, what if it is more than one arch team? Which
> > one do you assign it to?
> 
> Oh the fun we had in the past when bugs got assigned to one arch team
> with a few others CC'd and no maintainer in sight (because maybe the
> maintainer was the reporter, or was blanky assumed to be known). Or when
> another arch alias got CC'd later on. Or when a maintainer got fed up
> waiting and reassigned to an arch team in a "rage quit". And so on. It
> makes very messy bug reports. Musical chairs, anyone?
> 
> > If we want a separate assignee for old stabilizations, what about a
> > separate project that handles this, or maybe we could assign the bugs
> > to m-n or something until the arch teams catch up?
> 
> Again, where is the man power for that? :-)

Agreed, I was just trying to find a middle ground to satisfy the other
side of this.

> It's the maintainers that this problem hurts most, so they could and
> should be fixing it themselves - after a few months of waiting,
> reminding arch teams and gritting your teeth over it, just remove the
> old stable ebuilds[1].

Agreed, all the way. this is a real problem for package maintainers when
arch teams are so understaffed they can't keep up.

Also, it does a disservice to our users for us to claim we have stable
trees on these arches when the stable packages are multiple versions
behind the maintainer's stable requests.

William

>      jer
> 
> 
> [1] Where possible. If this happens with non-dev, non-experimental
>     architectures and keeping the old ebuilds is a real problem, the
>     architecture's status should be reconsidered. As has been done on
>     this mailing list time and again. If an arch team cannot even be
>     bothered to keep @system up to date, then why bother pretending
>     it's anywhere near "stable"?
> 

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sat, 15 Feb 2014 14:30:21 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > > Assigning bugs so arch teams is cosmetic at best.
> 
> s|so|to|
> 
> > While it was not explained here, the idea can also move the actual
> > maintenance of the ebuild to the arch team; such that it becomes the
> > arch team's responsibility to deal with it, or rather don't deal
> > with it
> 
> How would that ever work?

The responsibility is moved away from the maintainer; and thus also its
bugs, as well as the need to rely on a newer version to become stable.

> You have some old cat/pkg/pkg-version.ebuild that you no longer want
> to maintain, but which happens to be the latest stable for $ARCH,
> which is apparently understaffed because they $ARCH hasn't tended to
> a related bug report in months, and now you want to leave the ebuild
> in place and also expect $ARCH to start maintaining it?

The entire paragraph that you quote answers this.

> How does $ARCH have the man power to do that, again?

This thread is about the problems resulting out of that.

> > and have it act as a nagging reminder that stabilization really is
> > due. This also reflects the importance of the package, as it will
> > receive more attention and thus be more verbose towards the arch
> > team.
> 
> No, you're wrong there. Nobody is reading those bugzilla e-mails -
> nobody is working on keywording/stabilisation for $ARCH. "Nagging" is
> pointless when nobody hears you, and an e-mail from bugzilla isn't
> magically better prioritised when Assignee: changes.

The maintainer was reading these mails; this solution in main instance
addresses the maintainer's problem, what the arch team does further
with the bugs is their responsibility.

They can /dev/null it if they feel like; but if they want to address it
more useful, they can just as well use it as a measure of which
packages really need a newer version stabilized.

> The only reasonable course of action is to start dropping stable
> keywords for $ARCH, after a reasonable timeout. It gets tricky if this
> involves removing many keywords on dependencies, but if that's what
> you have to do to keep cat/pkg (and eclasses and profiles) in shape,
> then by all means _help_ _out_ $ARCH by doing it for them. If that
> means removing stable/unstable support for an entire DM or scripting
> framework, then so be it.

There was a new QA policy in place to support this; but it has been
brought back under discussion, as to address a wider acceptance further
discussion is needed. That policy was allowing the maintainer to do so.

> As long as @system is keyworded properly (by which I really really
> really mean something better than a "compile only" test - you know who
> you are), $ARCH users will normally be able to figure out how to
> emerge unstable packages themselves.

+1, more than @system would be nice, would love to see some kind of
importance applied; it can still make sense to stabilize all the
more common outside of @system that a lot of people use, but some
plug-in of some less famous package could be left unstable.

> > > Recently I've seen a few keywording/stabilisation bug reports
> > > assigned to arch teams again. It's really annoying. If you've
> > > started doing this, then please stop before people start to think
> > > it's a good idea. It's not.
> > 
> > Depends on what the arch teams think of this
> 
> No, it doesn't. Package maintainers are responsible for their bug
> reports, and Assignee: should reflect that.

The package mainatiners have long fixed this (or found fixes) in newer
versions of the package; their responsibility effectively ends at that
point, and stabilization of newer versions is the arch team's
responsibility. An arch team in Assignee: can do something about it.

> Maintaining a stable tree for an arch team means that someone on that
> team needs to do more than scratch their own itches - slacking should
> be fixed by relieving their burden, not pile on more, because that's
> precisely how volunteer work ultimately doesn't get done.

By prioritizing their efforts by bug counts, and dropping off what is
doesn't fit their slate; they can effectively relieve that burden.

For the same reason, these shouldn't be kept assigned to maintainers,
as piling old bugs on the maintainer's bugs lists is what blocks
progress; as the bottleneck is in their bug list, instead of in that of
the arch team where it is supposed to be and could be fixed or ditched.

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sat, 15 Feb 2014 10:18:32 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Many objected to removal since old with minor issues is better than
> new that doesn't work at all on some archs, or so the argument goes.

TL;DR: The opposite exists, I think we should draw a bar in the middle.

So goes the counter-argument; that an old version has some growing
issues (hidden security bugs get found, instability bugs are left
around, regressions are discovered, library dependencies get stabilized
but the package itself wasn't properly checked, ...) which are fixed in
a newer version, makes the new version better.

This could then allow one to rewrite the mail you wrote from the
complete opposite viewpoint; my point here is that, without rehashing
the discussion we had on this somewhere else in this long thread, that
the situation isn't as black on white as one would love to.

Making a claim "older [or newer] is most of the times better" requires a
quite a complex proof, but that shouldn't really be needed here. I agree
that your mention in another paragraph about "need to remove it"
definitely makes it more clear cut; although, that need can come
forward out of the presence of bugs and blocking stabilization requests.

The question here might rather be "how old is old?"; because if we're
talking about an old version of a year ago, that has quite a different
notion than an old version of several years ago. We can draw the bar
somewhere in between and we'll be fine...

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

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

On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs <williamh@gentoo.org> wrote:

> The problem with this is, what if it is more than one arch team? Which
> one do you assign it to?

The fastest gun in the west.

> If we want a separate assignee for old stabilizations, what about a
> separate project that handles this, or maybe we could assign the bugs
> to m-n or something until the arch teams catch up?

Maybe, maybe not; or just assign as above. No maintainer is needed. 

-- 
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: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sun, 16 Feb 2014 00:37:03 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sat, 15 Feb 2014 16:53:22 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > The problem with this is, what if it is more than one arch team?
> > Which one do you assign it to?
> 
> Oh the fun we had in the past when bugs got assigned to one arch team
> with a few others CC'd and no maintainer in sight (because maybe the
> maintainer was the reporter, or was blanky assumed to be known).

In this case the maintainer isn't needed on the bug anymore.

> Or when another arch alias got CC'd later on. Or when a maintainer got
> fed up waiting and reassigned to an arch team in a "rage quit". And
> so on. It makes very messy bug reports. Musical chairs, anyone?

The music seems unfit for the situation, how does this apply here?

> > If we want a separate assignee for old stabilizations, what about a
> > separate project that handles this, or maybe we could assign the
> > bugs to m-n or something until the arch teams catch up?
> 
> Again, where is the man power for that? :-)

The lack of manpower is a given by this thread, it's more about relief.

> It's the maintainers that this problem hurts most, so they could and
> should be fixing it themselves - after a few months of waiting,
> reminding arch teams and gritting your teeth over it, just remove the
> old stable ebuilds[1].

Exactly, it's that simple; but, it will be reverted per policy. 

> [1] Where possible. If this happens with non-dev, non-experimental
>     architectures and keeping the old ebuilds is a real problem, the
>     architecture's status should be reconsidered. As has been done on
>     this mailing list time and again. If an arch team cannot even be
>     bothered to keep @system up to date, then why bother pretending
>     it's anywhere near "stable"?

What "stable" means is really suffering from manpower; to be optimal it
would mean the most thorough review you can possibly think of, on top
of that the state of the ebuild is monitored a long time afterwards.

However, some do simple compile tests up to the point that the word no
longer adds stabilization on top of that of upstream and maintainer;
but rather acts to confirm that it has been made to compile, after
which the question is whether the effort will become a waste of time.

Stabilization requires tons of manpower to really work; the only way to
get that to happen with high efficiency and effectivity is to bring a
lot more people to the table, and let it also be done by the users that
already have interest in running ~ on their systems.

As they say, the more eyes the better.

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

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

On Sat, 15 Feb 2014 19:05:56 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
> > On Sat, 15 Feb 2014 16:53:22 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > The problem with this is, what if it is more than one arch team?
> > > Which one do you assign it to?
> > 
> > Oh the fun we had in the past when bugs got assigned to one arch
> > team with a few others CC'd and no maintainer in sight (because
> > maybe the maintainer was the reporter, or was blanky assumed to be
> > known). Or when another arch alias got CC'd later on. Or when a
> > maintainer got fed up waiting and reassigned to an arch team in a
> > "rage quit". And so on. It makes very messy bug reports. Musical
> > chairs, anyone?
> > 
> > > If we want a separate assignee for old stabilizations, what about
> > > a separate project that handles this, or maybe we could assign
> > > the bugs to m-n or something until the arch teams catch up?
> > 
> > Again, where is the man power for that? :-)
> 
> Agreed, I was just trying to find a middle ground to satisfy the other
> side of this.

You've already did that with the very first post of your thread; this
question however can be interpreted as either the given or the problem,
I'd prefer the former as the latter would make this thread something
that wouldn't have taken place.

> > It's the maintainers that this problem hurts most, so they could and
> > should be fixing it themselves - after a few months of waiting,
> > reminding arch teams and gritting your teeth over it, just remove
> > the old stable ebuilds[1].
> 
> Agreed, all the way. this is a real problem for package maintainers
> when arch teams are so understaffed they can't keep up.
> 
> Also, it does a disservice to our users for us to claim we have stable
> trees on these arches when the stable packages are multiple versions
> behind the maintainer's stable requests.

+1, on top of that it is further behind what upstream considers stable;
alongside that comes the drop in upstream support and bug filing, as
the old version could be considered unsupported by upstream.

-- 
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: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Pacho Ramos]

El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
> > If we want a separate assignee for old stabilizations, what about a
> > separate project that handles this, or maybe we could assign the bugs
> > to m-n or something until the arch teams catch up?
> 
> Again, where is the man power for that? :-)
> 
> It's the maintainers that this problem hurts most, so they could and
> should be fixing it themselves - after a few months of waiting,
> reminding arch teams and gritting your teeth over it, just remove the
> old stable ebuilds[1].
> 
> 
>      jer
> 
> 
> [1] Where possible. If this happens with non-dev, non-experimental
>     architectures and keeping the old ebuilds is a real problem, the
>     architecture's status should be reconsidered. As has been done on
>     this mailing list time and again. If an arch team cannot even be
>     bothered to keep @system up to date, then why bother pretending
>     it's anywhere near "stable"?
> 

I agree with Jeroen here. If the arch teams that are usually a bit
behind are not able to fix the bugs, I doubt we will gain anything
assigning bugs to them. Because of the way testing/stabilization bugs
work, arch teams should always check the bugs with them CCed and, then,
I don't think getting that bugs assigned to them would change much.

Also, keeping the bugs assigned to package maintainers will still allow
them to try to get that pending bugs fixed (or resolved in some way) as
they will take care more about that specific package status. If we get
that bugs assigned to arch teams, they will likely be ignored by both
parts, getting worse.

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> > > While it was not explained here, the idea can also move the actual
> > > maintenance of the ebuild to the arch team; such that it becomes
> > > the arch team's responsibility to deal with it, or rather don't
> > > deal with it
> > 
> > How would that ever work?
> 
> The responsibility is moved away from the maintainer; and thus also
> its bugs, as well as the need to rely on a newer version to become
> stable.

The (slightly rhetorical) question was how an understaffed team could
be realistically expected to start maintaining ebuilds. Your entire
reply missed that point.

The answer to the question is that you can't. A package maintainer
cannot burden an understaffed team with more work. They are
understaffed, so they will not do the work, and the maintainer has an
itch to scratch (stop maintaining an older version of a package).
Now guess who will be actually doing the work.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Rich Freeman]

On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> Also, keeping the bugs assigned to package maintainers will still allow
> them to try to get that pending bugs fixed (or resolved in some way) as
> they will take care more about that specific package status. If we get
> that bugs assigned to arch teams, they will likely be ignored by both
> parts, getting worse.

Well, that depends on your perspective.  If they fix them by deleting
the old version, then whether they've made things better or worse is a
matter of philosophy.

That's basically the counter-argument to removing old versions.  If
the newer version doesn't work at all, then the old buggy version is
superior.  It is better to have the bugs ignored, than to pester the
maintainer until the package is disabled entirely.

Honestly, this whole conversation seems rather theoretical.  What I
haven't heard from is the minor arch leads.  Actually, looking at the
base project page, it seems like half of them don't even have leads.

The other issue is that at least some devs have been stabilizing new
packages on minor archs for which the council decided to drop stable
keywords.  How to handle that is on the next agenda as well.

Basically all of this boils down to whether it is a good compromise to
redefine "stable" to something different on minor archs so that they
can make some use of the keyword, and do it without driving
maintainers nuts.  I don't have a big problem with that, as long as it
is done in a way that doesn't place any burden on anybody who doesn't
use the minor arch (including bug wranglers, maintainers, etc).

Rich

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> In this case the maintainer isn't needed on the bug anymore.

You can't simply drop your old toys when you get bored with them.
You're leaving a mess in the tree and blaming others. You have achieved
nothing else.

> > Or when another arch alias got CC'd later on. Or when a maintainer
> > got fed up waiting and reassigned to an arch team in a "rage quit".
> > And so on. It makes very messy bug reports. Musical chairs, anyone?
> 
> The music seems unfit for the situation, how does this apply here?

Google "musical chairs".

> > > If we want a separate assignee for old stabilizations, what about
> > > a separate project that handles this, or maybe we could assign the
> > > bugs to m-n or something until the arch teams catch up?
> > 
> > Again, where is the man power for that? :-)
> 
> The lack of manpower is a given by this thread, it's more about
> relief.

So maintainers should clean up their old ebuilds and not expect
understaffed arch teams to do it for them. Since elsewhere you actually
agreed with WilliamH agreeing with me on this point, it isn't clear what
you're meaningfully trying to add here.

> Exactly, it's that simple; but, it will be reverted per policy. 

Is the punctuation supposed to mean anything here? I can't make sense
of this otherwise.

> Stabilization requires tons of manpower to really work; the only way
> to get that to happen with high efficiency and effectivity is to
> bring a lot more people to the table, and let it also be done by the
> users that already have interest in running ~ on their systems.

You're again negating the premise that the team that is expected to do
the work is understaffed. This isn't a company where you simply hire
some more people to do the work or bring in an interim manager to fix
a team. The way volunteer work gets done is that you let stuff bitrot
for a while, make users suffer, and that if no one turns up to do the
work for you, someone will come in and clean up.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Pacho Ramos]

El dom, 16-02-2014 a las 09:03 -0500, Rich Freeman escribió:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Also, keeping the bugs assigned to package maintainers will still allow
> > them to try to get that pending bugs fixed (or resolved in some way) as
> > they will take care more about that specific package status. If we get
> > that bugs assigned to arch teams, they will likely be ignored by both
> > parts, getting worse.
> 
> Well, that depends on your perspective.  If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.

I think that, if they delete del old version without breaking the tree
(and, then, moving the package to testing for that arch), the situation
is improved. But, if the bug is assigned to the same team that cannot
handle its stabilization, I doubt they will move it to testing either.

> 
> That's basically the counter-argument to removing old versions.  If
> the newer version doesn't work at all, then the old buggy version is
> superior.  It is better to have the bugs ignored, than to pester the
> maintainer until the package is disabled entirely.

But, I guess there are two major cases:
- Versions that cannot be stabilized due they not working on that arch
any longer
- Versions that are not stabilized because arch team doesn't have the
man power to do that.

I am referring to the second case that is also really common. This also
raises again the question about being enough to do build tests for that
arches or not. If that is the case, would be nice if maintainers could
have access to that machines to let us help them :) (if I would build
them on that arches, I would try to help for sure)

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Rich Freeman]

On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> The (slightly rhetorical) question was how an understaffed team could
> be realistically expected to start maintaining ebuilds. Your entire
> reply missed that point.
>
> The answer to the question is that you can't. A package maintainer
> cannot burden an understaffed team with more work. They are
> understaffed, so they will not do the work, and the maintainer has an
> itch to scratch (stop maintaining an older version of a package).
> Now guess who will be actually doing the work.

Well, they can assign the burden to an understaffed team if the team
wants them to.

Perhaps an intermediate solution is that when a STABLEREQ gets stale
the maintainer posts in it their intention to drop the old version in
30 days.  The maintainer has to wait at least that long, and if during
that time a minor arch team asks them to keep the old version around
then all relevant bugs get reassigned to them, otherwise the
maintainer is free to delete it.

That leaves the choice with the minor arch team, with deletion being
the default.

Honestly, I'd probably be fine with the maintainer breaking the arch
stable tree when removing the package.  The arch stable tree isn't
really stable in the first place if nobody is caring for it, and there
really aren't any pretty solutions to that problem.

Rich

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Well, that depends on your perspective.  If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.

When you've cut the understaffed arch team out of the loop and removed
the troublesome old ebuild, things are actually better.

The problem with any arch team is that they may have ideas about what
should be available in the stable branch that might not match what they
can nowadays realistically maintain. This might be because fewer people
use that architecture than did in the past, or it might be because the
best systems using that architecture have become too slow for modern
versions of some software, or because a one time arch developer
happened to like certain packages and at the time thought it was a nice
idea to mark X packages stable there.

We've seen problems like this in the past with the bigger desktop
environments being stable (but lagging) on typical workstation
architectures, for instance, and also with expansive server application
frameworks on typical server architectures.

> That's basically the counter-argument to removing old versions.  If
> the newer version doesn't work at all, then the old buggy version is
> superior.  It is better to have the bugs ignored, than to pester the
> maintainer until the package is disabled entirely.
> 
> Honestly, this whole conversation seems rather theoretical.

Would you like some examples to be able to move beyond the theoretical?
I have plenty.

> What I haven't heard from is the minor arch leads.  Actually,
> looking at the base project page, it seems like half of them don't
> even have leads.

That's what "understaffed" means. I guess for them to engage in this
discussion would take away even more precious time. :)

> The other issue is that at least some devs have been stabilizing new
> packages on minor archs for which the council decided to drop stable
> keywords.  How to handle that is on the next agenda as well.

Why is this a problem? Also, doesn't profiles.desc already handle this?

> Basically all of this boils down to whether it is a good compromise to
> redefine "stable" to something different on minor archs so that they
> can make some use of the keyword, and do it without driving
> maintainers nuts.  I don't have a big problem with that, as long as it
> is done in a way that doesn't place any burden on anybody who doesn't
> use the minor arch (including bug wranglers, maintainers, etc).

What does that mean? "Stable" should mean the same for everyone, as
should "unstable" and "not keyworded". It sends a very clear message to
whomever would like to use a certain ebuild on a certain architecture.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Well, they can assign the burden to an understaffed team if the team
> wants them to.

Achieving nothing in the process, even if the understaffed team
actually responds.

> Perhaps an intermediate solution is that when a STABLEREQ gets stale
> the maintainer posts in it their intention to drop the old version in
> 30 days.  The maintainer has to wait at least that long, and if during
> that time a minor arch team asks them to keep the old version around
> then all relevant bugs get reassigned to them, otherwise the
> maintainer is free to delete it.

It isn't policy, maybe, but that's just common sense:

1) Request stabilisation.
2) Ping and wait.
3) Ping and wait.
4) Ping and wait.
5) Solve the problem yourself.

It's been done like this since forever.

> That leaves the choice with the minor arch team, with deletion being
> the default.

Yes, but "understaffed" so nobody is making any choices here.

> Honestly, I'd probably be fine with the maintainer breaking the arch
> stable tree when removing the package.  The arch stable tree isn't
> really stable in the first place if nobody is caring for it, and there
> really aren't any pretty solutions to that problem.

Indeed.



     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Rich Freeman]

On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sun, 16 Feb 2014 09:22:49 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> Well, they can assign the burden to an understaffed team if the team
>> wants them to.
>
> Achieving nothing in the process, even if the understaffed team
> actually responds.

It achieves getting them off of the maintainer's radar.  My goal isn't
to fix the package, my goal is to eliminate it as a burden on the
maintainer.  Basically that one version of the package is now
maintained by the arch team.  Yes, I know they won't maintain it.  The
only people that impacts are those who use the arch, who are free to
join the arch team and help out.  My sense is that they'd prefer
having it around to having it deleted.

>
> It's been done like this since forever.

Nobody is disputing this at all.  The reason why this thread seems to
go on forever is that it seems like the users of the minor archs don't
like the status quo.

>
>> That leaves the choice with the minor arch team, with deletion being
>> the default.
>
> Yes, but "understaffed" so nobody is making any choices here.

Well, if they make no choice then the maintainer deletes the package.
That's what you want, right?  The package would only stay around if
the minor arch asked them to.  If they don't do that, then nobody can
complain.

However, I don't think it makes sense to enact changes like these
unless the minor arch teams actually speak up about wanting the
changes.  If they don't I'd be inclined to just clarify that
maintainers are welcome to trim old stable versions on minor archs if
the bugs are older than n days.

Rich

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> I think that, if they delete del old version without breaking the tree
> (and, then, moving the package to testing for that arch), the
> situation is improved. But, if the bug is assigned to the same team
> that cannot handle its stabilization, I doubt they will move it to
> testing either.

And when you do break the tree when you threaten to effectively remove
an arch keyword, then you may need to dig deeper and remove more
keywords elsewhere until you've found an "unstable" solution. As long
as you communicate the solution to that team, and maybe prod someone on
IRC until they make the time to look at it and (reluctantly) agree,
there should be no problem in dropping stable for them.

> But, I guess there are two major cases:
> - Versions that cannot be stabilized due they not working on that arch
> any longer

It's probably a good idea to package.mask the affected versions on the
arch profile(s) (with references to bug reports, and so on) so all users
of that profile get to see it. Treat it like a "last rites" process.
Currently that's the only way for users to find out when and why a
package becomes unsupported on a given profile, and it should work
well enough. Give them thirty days to respond or become arch team
members or ATs or just give the nod to an arch developer to say "it
works" - it may even lead to actual stabilisation of a newer ebuild.

> - Versions that are not stabilized because arch team doesn't have the
> man power to do that.

As above, package.mask would be a good intermediate solution,
communicating the problem to the arch users for, say, thirty days. Of
course it may just delay solving the problem when a new set of
stabilisations is due and again no one responds.

> I am referring to the second case that is also really common. This
> also raises again the question about being enough to do build tests
> for that arches or not.

No, "compile only" is never enough to call something "stable".

> If that is the case, would be nice if maintainers could have access
> to that machines to let us help them :) (if I would build them on
> that arches, I would try to help for sure)

http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Pacho Ramos]

El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió:
> On Sun, 16 Feb 2014 15:18:42 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I think that, if they delete del old version without breaking the tree
> > (and, then, moving the package to testing for that arch), the
> > situation is improved. But, if the bug is assigned to the same team
> > that cannot handle its stabilization, I doubt they will move it to
> > testing either.
> 
> And when you do break the tree when you threaten to effectively remove
> an arch keyword, then you may need to dig deeper and remove more
> keywords elsewhere until you've found an "unstable" solution. As long
> as you communicate the solution to that team, and maybe prod someone on
> IRC until they make the time to look at it and (reluctantly) agree,
> there should be no problem in dropping stable for them.

Yeah, I know that problem of "chain reaction" will appear (I am thinking
in Gnome stuff for example :S), but I can't think on any better
alternative. Will be a lot of work but will save time in the future :|

> 
> > But, I guess there are two major cases:
> > - Versions that cannot be stabilized due they not working on that arch
> > any longer
> 
> It's probably a good idea to package.mask the affected versions on the
> arch profile(s) (with references to bug reports, and so on) so all users
> of that profile get to see it. Treat it like a "last rites" process.
> Currently that's the only way for users to find out when and why a
> package becomes unsupported on a given profile, and it should work
> well enough. Give them thirty days to respond or become arch team
> members or ATs or just give the nod to an arch developer to say "it
> works" - it may even lead to actual stabilisation of a newer ebuild.

Looks interesting, maybe that would indeed help to get more people
involved on that arch teams :O

> 
> > - Versions that are not stabilized because arch team doesn't have the
> > man power to do that.
> 
> As above, package.mask would be a good intermediate solution,
> communicating the problem to the arch users for, say, thirty days. Of
> course it may just delay solving the problem when a new set of
> stabilisations is due and again no one responds.

I disagree in this case as the package can still be in "testing", not
like the above case that, if the package is broken, it shouldn't be
neither in testing tree.

> 
> > I am referring to the second case that is also really common. This
> > also raises again the question about being enough to do build tests
> > for that arches or not.
> 
> No, "compile only" is never enough to call something "stable".
> 
> > If that is the case, would be nice if maintainers could have access
> > to that machines to let us help them :) (if I would build them on
> > that arches, I would try to help for sure)
> 
> http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines
> 
> 
>      jer
> 

Thanks for the link :D, but I don't think I could do much more than
building+running the tests of the packages while doing that in most
cases (I am thinking in "graphical" stuff). If that would be enough,
nice, if not... :S

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Basically that one version of the package is now maintained by the
> arch team.  Yes, I know they won't maintain it.  The only people that
> impacts are those who use the arch, who are free to join the arch
> team and help out.  My sense is that they'd prefer having it around
> to having it deleted.

That's a bit simplistic. What if said package or its newer version is
required for dozens of other packages, or if the old ebuild needs an
outdated eclass, or if the old version has a security issue? You can't
just "assign" all of the old KDE ebuilds to an arch team, for instance,
or keep texlive 2010 in place because you have "delegated"
responsibility for it.

Also, every time *I* look at eshowkw's output for a package I maintain
(which I assume every ebuild developer does or they should hand in
their badge) and see a lingering old version, it really itches. The
mere knowledge that I have "delegated" its maintenance to someone else
wouldn't make me feel better at all. Amplify that with reverse
dependencies.

> The reason why this thread seems to go on forever is that it seems
> like the users of the minor archs don't like the status quo.

Examples? :)

> >> That leaves the choice with the minor arch team, with deletion
> >> being the default.
> >
> > Yes, but "understaffed" so nobody is making any choices here.
> 
> Well, if they make no choice then the maintainer deletes the package.
> That's what you want, right?  The package would only stay around if
> the minor arch asked them to.  If they don't do that, then nobody can
> complain.
> 
> However, I don't think it makes sense to enact changes like these
> unless the minor arch teams actually speak up about wanting the
> changes.  If they don't I'd be inclined to just clarify that
> maintainers are welcome to trim old stable versions on minor archs if
> the bugs are older than n days.

That still leaves maintenance problems on dependent packages and
eclasses and security issues and what not.

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Sun, 16 Feb 2014 15:53:57 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

In this case:

> > > - Versions that are not stabilized because arch team doesn't have
> > > the man power to do that.  
> >
> > As above, package.mask would be a good intermediate solution,
> > communicating the problem to the arch users for, say, thirty days.
> > Of course it may just delay solving the problem when a new set of
> > stabilisations is due and again no one responds.
> 
> I disagree in this case as the package can still be in "testing", not
> like the above case that, if the package is broken, it shouldn't be
> neither in testing tree.

In this case, a newer version hasn't been (sufficiently) tested on a
certain architecture, so it is still in the "testing" phase. In this
case, you haven't established that it's broken.

Also, the general idea is to temporarily mask the _old_ stable
version(s) on the arch profile and not _all_ versions.


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sun, 16 Feb 2014 14:48:57 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 16 Feb 2014 08:23:27 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > > > While it was not explained here, the idea can also move the
> > > > actual maintenance of the ebuild to the arch team; such that it
> > > > becomes the arch team's responsibility to deal with it, or
> > > > rather don't deal with it
> > > 
> > > How would that ever work?
> > 
> > The responsibility is moved away from the maintainer; and thus also
> > its bugs, as well as the need to rely on a newer version to become
> > stable.
> 
> The (slightly rhetorical) question was how an understaffed team could
> be realistically expected to start maintaining ebuilds. Your entire
> reply missed that point.
> 
> The answer to the question is that you can't.

The deepest quote contains "or rather don't deal with it".

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[William Hubbs]

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

On Sun, Feb 16, 2014 at 09:38:20AM -0500, Rich Freeman wrote:
> Well, if they make no choice then the maintainer deletes the package.
> That's what you want, right?  The package would only stay around if
> the minor arch asked them to.  If they don't do that, then nobody can
> complain.
> 
> However, I don't think it makes sense to enact changes like these
> unless the minor arch teams actually speak up about wanting the
> changes.  If they don't I'd be inclined to just clarify that
> maintainers are welcome to trim old stable versions on minor archs if
> the bugs are older than n days.

That's exactly what my proposed patch to the devmanual says [1]. It only
applies to packages when the arch team does not respond to a stable
request within 90 days after they were added to it.

The problem is, this isn't just a clarification. It is a change of
policy. The current policy is that a maintainer is not allowed to delete
the last stable version of a package on any architecture under any
circumstances [2].

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=500014
[2] http://devmanual.gentoo.org/keywording/index.html

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sun, 16 Feb 2014 15:04:30 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 16 Feb 2014 09:00:16 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > In this case the maintainer isn't needed on the bug anymore.
> 
> You can't simply drop your old toys when you get bored with them.
> You're leaving a mess in the tree and blaming others. You have
> achieved nothing else.

In real life; if you take someone else's toys out of the garbage can,
they become your mess and it reverts my achievement of ditching them.

> > > Or when another arch alias got CC'd later on. Or when a maintainer
> > > got fed up waiting and reassigned to an arch team in a "rage
> > > quit". And so on. It makes very messy bug reports. Musical
> > > chairs, anyone?
> > 
> > The music seems unfit for the situation, how does this apply here?
> 
> Google "musical chairs".

Keeping the unfit music off, we don't play; how does this apply here?

> > > > If we want a separate assignee for old stabilizations, what
> > > > about a separate project that handles this, or maybe we could
> > > > assign the bugs to m-n or something until the arch teams catch
> > > > up?
> > > 
> > > Again, where is the man power for that? :-)
> > 
> > The lack of manpower is a given by this thread, it's more about
> > relief.
> 
> So maintainers should clean up their old ebuilds and not expect
> understaffed arch teams to do it for them.

The understaffed arch teams want to keep them around.

> Since elsewhere you actually agreed with WilliamH agreeing with me on
> this point, it isn't clear what you're meaningfully trying to add
> here.

Sounds like another context.

> > Exactly, it's that simple; but, it will be reverted per policy. 
> 
> Is the punctuation supposed to mean anything here? I can't make sense
> of this otherwise.

Replace the boundary marks by terminal marks if that helps; however,
the pauses here are as intended in a way that makes sense.

> > Stabilization requires tons of manpower to really work; the only way
> > to get that to happen with high efficiency and effectivity is to
> > bring a lot more people to the table, and let it also be done by the
> > users that already have interest in running ~ on their systems.
> 
> You're again negating the premise that the team that is expected to do
> the work is understaffed. This isn't a company where you simply hire
> some more people to do the work or bring in an interim manager to fix
> a team. The way volunteer work gets done is that you let stuff bitrot
> for a while, make users suffer, and that if no one turns up to do the
> work for you, someone will come in and clean up.

The users will do; given that we already know that, we can work towards
it.

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> [...]
> > > If we want a separate assignee for old stabilizations, what about
> > > a separate project that handles this, or maybe we could assign
> > > the bugs to m-n or something until the arch teams catch up?
> > 
> > Again, where is the man power for that? :-)
> > 
> > It's the maintainers that this problem hurts most, so they could and
> > should be fixing it themselves - after a few months of waiting,
> > reminding arch teams and gritting your teeth over it, just remove
> > the old stable ebuilds[1].
> > 
> > 
> >      jer
> > 
> > 
> > [1] Where possible. If this happens with non-dev, non-experimental
> >     architectures and keeping the old ebuilds is a real problem, the
> >     architecture's status should be reconsidered. As has been done
> > on this mailing list time and again. If an arch team cannot even be
> >     bothered to keep @system up to date, then why bother pretending
> >     it's anywhere near "stable"?
> > 
> 
> I agree with Jeroen here. If the arch teams that are usually a bit
> behind are not able to fix the bugs, I doubt we will gain anything
> assigning bugs to them. Because of the way testing/stabilization bugs
> work, arch teams should always check the bugs with them CCed and,
> then, I don't think getting that bugs assigned to them would change
> much.

That would be true if the context of this thread were the arch team;
however, the context of this thread is the maintainer as that is the
person experiencing the problem that was put forward.

The solution here thus intends to address the maintainer, which benefits
from this; while it keeps the arch team's the same, whether the arch
team does more with this is their own responsibility.

> Also, keeping the bugs assigned to package maintainers will still
> allow them to try to get that pending bugs fixed (or resolved in some
> way) as they will take care more about that specific package status.

Package maintainers have better things to do. While it would allow
for example the GNOME team to maintain GNOME 2 which sticks around; it
actually happening is another story as they want to see GNOME 2 go,
because maintaining multiple versions of GNOME costs too much time.

> If we get that bugs assigned to arch teams, they will likely be
> ignored by both parts, getting worse.

At this point the arch team can realize that keeping the version around
is an unrealistic goal, they can then take a decision to stop keeping
it around and thus remove it; if needed, taking additional steps.

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sun, 16 Feb 2014 15:46:23 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> > But, I guess there are two major cases:
> > - Versions that cannot be stabilized due they not working on that
> > arch any longer
> 
> It's probably a good idea to package.mask the affected versions on the
> arch profile(s) (with references to bug reports, and so on) so all
> users of that profile get to see it. Treat it like a "last rites"
> process. Currently that's the only way for users to find out when and
> why a package becomes unsupported on a given profile, and it should
> work well enough. Give them thirty days to respond or become arch team
> members or ATs or just give the nod to an arch developer to say "it
> works" - it may even lead to actual stabilisation of a newer ebuild.
> 
> > - Versions that are not stabilized because arch team doesn't have
> > the man power to do that.
> 
> As above, package.mask would be a good intermediate solution,
> communicating the problem to the arch users for, say, thirty days. Of
> course it may just delay solving the problem when a new set of
> stabilisations is due and again no one responds.

+1, see an example that I wrote earlier at the bottom of this mail:

http://article.gmane.org/gmane.linux.gentoo.devel/90083/match=Consider%20this%20instead

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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[William Hubbs]

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

On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
> On Sun, 16 Feb 2014 09:41:03 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> > [...]
> > > > If we want a separate assignee for old stabilizations, what about
> > > > a separate project that handles this, or maybe we could assign
> > > > the bugs to m-n or something until the arch teams catch up?
> > > 
> > > Again, where is the man power for that? :-)
> > > 
> > > It's the maintainers that this problem hurts most, so they could and
> > > should be fixing it themselves - after a few months of waiting,
> > > reminding arch teams and gritting your teeth over it, just remove
> > > the old stable ebuilds[1].
> > > 
> > > 
> > >      jer
> > > 
> > > 
> > > [1] Where possible. If this happens with non-dev, non-experimental
> > >     architectures and keeping the old ebuilds is a real problem, the
> > >     architecture's status should be reconsidered. As has been done
> > > on this mailing list time and again. If an arch team cannot even be
> > >     bothered to keep @system up to date, then why bother pretending
> > >     it's anywhere near "stable"?
> > > 
> > 
> > I agree with Jeroen here. If the arch teams that are usually a bit
> > behind are not able to fix the bugs, I doubt we will gain anything
> > assigning bugs to them. Because of the way testing/stabilization bugs
> > work, arch teams should always check the bugs with them CCed and,
> > then, I don't think getting that bugs assigned to them would change
> > much.
> 
> That would be true if the context of this thread were the arch team;
> however, the context of this thread is the maintainer as that is the
> person experiencing the problem that was put forward.
> 
> The solution here thus intends to address the maintainer, which benefits
> from this; while it keeps the arch team's the same, whether the arch
> team does more with this is their own responsibility.
> 
> > Also, keeping the bugs assigned to package maintainers will still
> > allow them to try to get that pending bugs fixed (or resolved in some
> > way) as they will take care more about that specific package status.
> 
> Package maintainers have better things to do. While it would allow
> for example the GNOME team to maintain GNOME 2 which sticks around; it
> actually happening is another story as they want to see GNOME 2 go,
> because maintaining multiple versions of GNOME costs too much time.
> 
> > If we get that bugs assigned to arch teams, they will likely be
> > ignored by both parts, getting worse.
> 
> At this point the arch team can realize that keeping the version around
> is an unrealistic goal, they can then take a decision to stop keeping
> it around and thus remove it; if needed, taking additional steps.

You are still assuming that the arch team is fully staffed. If they are
not, the old versions of packages still remain in the tree indefinitely.
As a maintainer, at some point, I don't want them around.

Keeping them around can force me to keep old migration code for example
that automates upgrading to new versions longer than I would have to
otherwise.

William


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

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Steev Klimaszewski]

On Sun, 2014-02-16 at 09:03 -0500, Rich Freeman wrote:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Also, keeping the bugs assigned to package maintainers will still allow
> > them to try to get that pending bugs fixed (or resolved in some way) as
> > they will take care more about that specific package status. If we get
> > that bugs assigned to arch teams, they will likely be ignored by both
> > parts, getting worse.
> 
> Well, that depends on your perspective.  If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.
> 
> That's basically the counter-argument to removing old versions.  If
> the newer version doesn't work at all, then the old buggy version is
> superior.  It is better to have the bugs ignored, than to pester the
> maintainer until the package is disabled entirely.
> 
> Honestly, this whole conversation seems rather theoretical.  What I
> haven't heard from is the minor arch leads.  Actually, looking at the
> base project page, it seems like half of them don't even have leads.
> 

Minor arch co-lead checking in.  I haven't chimed in as I'm still pretty
agitated with the PREVIOUS thread about this exact same topic.  And by
agitated, I mean I'm tired of it.  If you guys wanna break the tree for
us minor arches, go for it.  It's obvious from the thread that people
care not about making Gentoo the best distro that it can be, and
entirely care about how pretty the graphs are, and how short their bug
lists are.  I'm tired of "fighting" about this.  My position was made
known, some agreed, some disagreed, but reiterating it over and over
does nothing, and no new information is brought in by it.  If you want
to re-read it, feel free to read through the previous thread.

> The other issue is that at least some devs have been stabilizing new
> packages on minor archs for which the council decided to drop stable
> keywords.  How to handle that is on the next agenda as well.
> 
> Basically all of this boils down to whether it is a good compromise to
> redefine "stable" to something different on minor archs so that they
> can make some use of the keyword, and do it without driving
> maintainers nuts.  I don't have a big problem with that, as long as it
> is done in a way that doesn't place any burden on anybody who doesn't
> use the minor arch (including bug wranglers, maintainers, etc).
> 
> Rich
> 

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

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

On Sun, 16 Feb 2014 14:50:41 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
> > On Sun, 16 Feb 2014 09:41:03 +0100
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> > > [...]
> > > > > If we want a separate assignee for old stabilizations, what
> > > > > about a separate project that handles this, or maybe we could
> > > > > assign the bugs to m-n or something until the arch teams
> > > > > catch up?
> > > > 
> > > > Again, where is the man power for that? :-)
> > > > 
> > > > It's the maintainers that this problem hurts most, so they
> > > > could and should be fixing it themselves - after a few months
> > > > of waiting, reminding arch teams and gritting your teeth over
> > > > it, just remove the old stable ebuilds[1].
> > > > 
> > > > 
> > > >      jer
> > > > 
> > > > 
> > > > [1] Where possible. If this happens with non-dev,
> > > > non-experimental architectures and keeping the old ebuilds is a
> > > > real problem, the architecture's status should be reconsidered.
> > > > As has been done on this mailing list time and again. If an
> > > > arch team cannot even be bothered to keep @system up to date,
> > > > then why bother pretending it's anywhere near "stable"?
> > > > 
> > > 
> > > I agree with Jeroen here. If the arch teams that are usually a bit
> > > behind are not able to fix the bugs, I doubt we will gain anything
> > > assigning bugs to them. Because of the way testing/stabilization
> > > bugs work, arch teams should always check the bugs with them CCed
> > > and, then, I don't think getting that bugs assigned to them would
> > > change much.
> > 
> > That would be true if the context of this thread were the arch team;
> > however, the context of this thread is the maintainer as that is the
> > person experiencing the problem that was put forward.
> > 
> > The solution here thus intends to address the maintainer, which
> > benefits from this; while it keeps the arch team's the same,
> > whether the arch team does more with this is their own
> > responsibility.
> > 
> > > Also, keeping the bugs assigned to package maintainers will still
> > > allow them to try to get that pending bugs fixed (or resolved in
> > > some way) as they will take care more about that specific package
> > > status.
> > 
> > Package maintainers have better things to do. While it would allow
> > for example the GNOME team to maintain GNOME 2 which sticks around;
> > it actually happening is another story as they want to see GNOME 2
> > go, because maintaining multiple versions of GNOME costs too much
> > time.
> > 
> > > If we get that bugs assigned to arch teams, they will likely be
> > > ignored by both parts, getting worse.
> > 
> > At this point the arch team can realize that keeping the version
> > around is an unrealistic goal, they can then take a decision to
> > stop keeping it around and thus remove it; if needed, taking
> > additional steps.
> 
> You are still assuming that the arch team is fully staffed. If they
> are not, the old versions of packages still remain in the tree
> indefinitely.

It allows undermanned arch teams to prioritize; and as a consequence of
that, the assumption is that arch team's are undermanned as the fully
staffed arch teams benefit less from this. This is under the assumption
that this is being put to good use by the arch team, but that's up to
them; as I mentioned yesterday this is focused more on the maintainer.

Ignoring this, I see what you are getting at in the second part of
that paragraph; it indeed could become annoying to have to track which
versions you are and no longer are maintaining, which adds another
parameter of complexity to our daily maintenance work.

> As a maintainer, at some point, I don't want them around.
>
> Keeping them around can force me to keep old migration code for
> example that automates upgrading to new versions longer than I would
> have to otherwise.

+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: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Jeroen Roovers]

On Mon, 17 Feb 2014 19:46:43 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> It allows undermanned arch teams to prioritize

Oh, so you're still assuming an understaffed team somehow manages
to do some work in an appropriate time frame. It's getting old.

Apparently "understaffed" isn't the right word since it keeps tripping
you up. How about "abandoned"? "Overburdened"? "Inactive" maybe?


     jer

Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Mon, 17 Feb 2014 21:47:42 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 17 Feb 2014 19:46:43 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > It allows undermanned arch teams to prioritize
> 
> Oh, so you're still assuming an understaffed team somehow manages
> to do some work in an appropriate time frame. It's getting old.
> 
> Apparently "understaffed" isn't the right word since it keeps tripping
> you up. How about "abandoned"? "Overburdened"? "Inactive" maybe?

The indication of these meanings are underivable from the context of
the problem; for what we know, some bugs out of all of them linger in
the stabilization queue. That leads to the generic perception of the
arch teams being "understaffed", anything beyond that are assumptions;
less common, these assumptions exist in a non-generic way.

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

[gentoo-dev] Re: dropping redundant stable keywords

[Steven J. Long]

On Fri, Feb 14, 2014 Tom Wijsman wrote:
> On Thu, 13 Feb 2014 "Steven J. Long" wrote:
> 
> > > > Much better for the arch in question to field the bug, than tell
> > > > the user there is no problem, and we don't care. That way you can
> > > > get the user involved in stabilisation and AT via that bug,
> > > > instead of turning them away with priggishness.
> > > 
> > > Problems should be visible instead of hidden, as well as resolved. A
> > > move in work means a move in work, further implications are yours...
> > 
> > Very gnomic: nothing's being hidden in the above approach.
> 
> Filing a bug but not telling the user about it is hiding the problem.

"The bug" in the above is a bug the user on the arch in question has
filed, which would be duped to the stabilisation bug (for the arch if
there's more than one) so the user a) knows there's a newer version,
which they can try out and help stabilise, and b) isn't kicked back
with a WONTFIX, when they could be put in touch with the AT instead.

So the user filed the bug in the first place: by definition they know
about it.

> > I can't make sense of the rest so I'll move on, noting only that it's
> > up to the arch team, as to what _they_ decide to kick back to
> > unstable.
> 
> They need manpower to decide it, which they don't have.

It's still no-one else's call, though given the approach it's easy
enough to allow a further say 180 days after the "-* arch" marking,
before the maintainer is allowed to mark the package as a whole
unstable on the arch in question, given no movement.

> > And that can work without a problem if we have a mechanism
> > in place to relieve maintainers of those bugs.
> 
> Such mechanism could be to assign those bug to the arch team, this idea
> came up at FOSDEM; it won't solve the lack of manpower, but it will at
> least relieve the maintainers and make the problem more visible.

Exactly. What the AT does with it is their problem: if they don't move
after another 180 days, they can't complain, but there's at least a more
formal process, and there's no row, nor even discussion needed. You had
a chance to stabilise, we've waited, and you've still got the stable
ebuild in your tree, but now any users on your arch are going to get
redirected to you, so you can discuss moving the package forward or
bumping it to unstable.

To me that makes the action something positive, rather than negative.
Especially coupled with an indicator in the package manager output,
similar to how unstable ebuilds are marked if you're running stable,
or forced-rebuilds. That would spur more users to help, since they're
using the package in question, and are on a slow arch.

> > Personally I'd do it after 45 days to speed things up, and let the
> > ATs concerned, take the bug as and when (eg turn the stabilisation
> > into a tracker for the slow archs concerned, if there are multiple.)
> 
> Since this is a soft measure I've seen a lot of people want the time to
> be longer; if it still continues to be a problem, then shortening it
> might be a solution but I think we'll want to avoid a too hard approach
> for now. 45 days are over before you know it...

No the whole point is that the slower archs are not losing a stable
ebuild in their tree: so it's fine for the maintainer to wait a shorter
time before marking it as no-longer-my-problem. It's not the same as
dropping the ebuild altogether; it leaves the arch-tree intact, and
still marks a new phase for interested users to collaborate around,
while relieving the maintainer of the burden.

And if desired, that can be seen as the start of a phase toward bumping
it to unstable, but with more notice, and a defined process.

> The part about ATs taking the bug sounds like what came up at FOSDEM. +1

<snip>
> > The wonderful thing about policy is that it reflects (or is supposed
> > to) consensus opinion with light to contemporaneous circumstance.
> > Since circumstances change, so too must policy be open to change or
> > adaptation, in line with basic principles.
> 
> In this case -* works fine for what it intends to work; changing the
> policy to redefine it to fit another purpose, while no longer
> reflecting its original purpose is what we should avoid at all cost.

Utter nonsense. Back that up with some consequent to justify why we
should "avoid it at all costs", bearing in mind the below.

> > So let's look at extending it, since there is *no* technical problem:
> 
> You have colons after the above quoted sentence with nothing after it.
> 
> (An eye for an eye... :D)

Don't be so facile: the proposed extended policy is what follows.

> > 'The redundant -* keyword is a metadata marker.
> 
> The keyword has a meaning, therefore it is not redundant.

It is technically redundant, since the package manager does not infer
any existing keywords, so there is nothing to strip. As a metadata
marker, no ofc it's not redundant: but that's what I'm proposing to
use.

> > It is used to indicate, in line with the semantic of "strip all",
> > that the ebuild in question can only be used for the specific archs
> > noted for one of two reasons:
> > 
> > 1) The package-maintainer has stabilised a newer version on at least
> > one arch personally, the ATs for the archs listed have taken longer
> > than XX days to test and stabilise, and the maintainer would
> > otherwise drop the ebuild altogether.
> > 
> > 2) The package version is not worth trying to test on unlisted archs.'
> 
> (1) changes its meaning in a way that you can no longer interpret the
> keyword solely as (2). The whole purpose of (2) is that you can
> interpret it that you should not test it as it was found not to work;
> (1) is different from that, as it means that there was no manpower to
> test it. (1) would move ebuilds to -* and be misinterpreted as (2).

Nope: 1) implies 2) so any existing use of the marker solely in the
context of 2) still works. It certainly is not worth testing an old
ebuild that would have been dropped on an unlisted arch: whoever is
looking at the ebuild, should instead use a newer version.

> > The policy which flows from that is:
> > 
> > 'In the first case, it is QA policy that a comment of the form:
> > # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN
> > is required on the line immediately above the KEYWORDS declaration.
> > 
> > This is to aid both automated identification, and human
> > collaboration.'
> > 
> > (The latter explains why a URL, not a bug id, is required. We're
> > trying to get end-users to help us, so let's make it easy for them.)
> >
> > I'd personally add:
> > 'It is envisaged that the line will be added by an automated tool at
> > some point.'
> > 
> > ..as well as a requirement for a bug id in the second case, but I
> > don't know it well enough; I'd certainly want some sort of tracking.
> 
> This yields extra commits; comments in ebuilds are directed towards
> maintainers, for users we should use another approach to contact them.

No it keeps all the useful info in one place: the ebuild, where it's
easy to edit and see. The commit is already implicit in dropping the
ebuild to "-* slower arch": all the policy does is require a link to
the original stabilisation bug, which may be a tracker if multiple
archs are involved. However none of that is the maintainer's concern:
all they need do, when facing this rare situation, is change the
keywords and add a link to the bug (commenting is SOP for most unusual
situations in ebuilds), instead of dropping the arch's stable version.

The link is easy to extract for an automated external to show to the
user, like the mangler in the above, or a porcelain layer, given an
indicator from the mangler.

It's also a helluva lot less work than package.mask, as well as
keeping all the info in the ebuild, where it's easier to handle.

> > It's hardly an onerous requirement, and a small price to pay: if
> > we have a policy for how a maintainer drops an ebuild from his
> > queue due to it being stabilised, which we can trigger scripts
> > from, we avoid the arguments every year or so, and stop archs from
> > being borked. We can also speed it up, since we have a mechanism
> > in-place to support it, as opposed to ad-hoc, flawed decision-making.
> > 
> > The thing I think that's missing from this debate, is an
> > acknowledgement, or an understanding, that arch-teams are all
> > effectively working on their own variant of the shared Gentoo tree.
> > (This includes the concept of upgrades working as smoothly as they
> > do on other archs, at the PM level.) Similar to other portability
> > efforts, the tree must support them in that, not make it harder.
> > 
> > Especially not because another developer doesn't care about the arch
> > in question. That's *natural*, but _cannot_ be cause for dropping
> > stable ebuilds. The only issue is to take the bugs off their hands,
> > and we can do that with a simple tweak in metadata, so ffs let's
> > get on and do it.
> 
> +1 on this thought.

Well I wish you could see that steev's solution, with a bit of standard
commenting, fulfils both your +1s and doesn't lead to broken arch-trees.
It also doesn't require any communication with a non-responsive arch,
and can form the basis of a much more useful mode of collaboration,
from where I'm sitting.

Post-facto complaints about an upstream project decision to keep
migration code, or about the anguish of seeing an older version
stable on some arch you don't even care about (or you wouldn't be
dropping their last stable version) are an order-of-magnitude less
concerning. By all means address them (up to the project in the
first case, adjust your script in the second) but let's at least
admit they are less of a problem than this continual argument, and
the consequent ill-feeling brought about by lack of a defined
action to take.

The issue about confusion with multiple archs has already been
addressed by making the original stabilisation bug a tracker for
the N slow archs, if there are more than one.

Most of this can be automated, or is at least amenable to it. And
that discussion is *far* more interesting than "you broke our arch"
vs "so what, you're too slow".

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: dropping redundant stable keywords

[Tom Wijsman]

On Tue, 18 Feb 2014 18:31:28 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> On Fri, Feb 14, 2014 Tom Wijsman wrote:
> > On Thu, 13 Feb 2014 "Steven J. Long" wrote:
> > 
> > > > > Much better for the arch in question to field the bug, than
> > > > > tell the user there is no problem, and we don't care. That
> > > > > way you can get the user involved in stabilisation and AT via
> > > > > that bug, instead of turning them away with priggishness.
> > > > 
> > > > Problems should be visible instead of hidden, as well as
> > > > resolved. A move in work means a move in work, further
> > > > implications are yours...
> > > 
> > > Very gnomic: nothing's being hidden in the above approach.
> > 
> > Filing a bug but not telling the user about it is hiding the
> > problem.
> 
> "The bug" in the above is a bug the user on the arch in question has
> filed, which would be duped to the stabilisation bug (for the arch if
> there's more than one) so the user a) knows there's a newer version,
> which they can try out and help stabilise, and b) isn't kicked back
> with a WONTFIX, when they could be put in touch with the AT instead.
> 
> So the user filed the bug in the first place: by definition they know
> about it.

There are more users than the user that filed the bug; in order to
address all of them, and not just the user of the bug, other
forms of communication need to be taken to address those users. One of
such that came up is using the package.mask reason to do this.

> > > I can't make sense of the rest so I'll move on, noting only that
> > > it's up to the arch team, as to what _they_ decide to kick back to
> > > unstable.
> > 
> > They need manpower to decide it, which they don't have.
> 
> It's still no-one else's call, though given the approach it's easy
> enough to allow a further say 180 days after the "-* arch" marking,

As detailed before, -* has a different meaning defined by policy; if we
want to see that changed it should be brought up for a vote, otherwise
its usage in discussions like these seems to suggest to break an
existing policy. So, I read this as "arch" whenever it is brought up.

> before the maintainer is allowed to mark the package as a whole
> unstable on the arch in question, given no movement.

When the developer marks the package as "minorarch", it's already
unstable on the newer versions; thus I think I'm missing a particular
detail in your paragraph to understand what is meant here, unless you
mean that we keep track of this in a separate way.

> > > And that can work without a problem if we have a mechanism
> > > in place to relieve maintainers of those bugs.
> > 
> > Such mechanism could be to assign those bug to the arch team, this
> > idea came up at FOSDEM; it won't solve the lack of manpower, but it
> > will at least relieve the maintainers and make the problem more
> > visible.
> 
> Exactly. What the AT does with it is their problem: if they don't move
> after another 180 days, they can't complain, but there's at least a
> more formal process, and there's no row, nor even discussion needed.
> You had a chance to stabilise, we've waited, and you've still got the
> stable ebuild in your tree, but now any users on your arch are going
> to get redirected to you, so you can discuss moving the package
> forward or bumping it to unstable.

We've had discussion here and on IRC after the similar QA policy; it's
what put it in a state of discussing it again, which will happen
tomorrow evening during the Gentoo QA meeting.

> To me that makes the action something positive, rather than negative.
> Especially coupled with an indicator in the package manager output,
> similar to how unstable ebuilds are marked if you're running stable,
> or forced-rebuilds. That would spur more users to help, since they're
> using the package in question, and are on a slow arch.

+1, package.mask or so could serve well here.
 
> > > Personally I'd do it after 45 days to speed things up, and let the
> > > ATs concerned, take the bug as and when (eg turn the stabilisation
> > > into a tracker for the slow archs concerned, if there are
> > > multiple.)
> > 
> > Since this is a soft measure I've seen a lot of people want the
> > time to be longer; if it still continues to be a problem, then
> > shortening it might be a solution but I think we'll want to avoid a
> > too hard approach for now. 45 days are over before you know it...
> 
> No the whole point is that the slower archs are not losing a stable
> ebuild in their tree: so it's fine for the maintainer to wait a
> shorter time before marking it as no-longer-my-problem. It's not the
> same as dropping the ebuild altogether; it leaves the arch-tree
> intact, and still marks a new phase for interested users to
> collaborate around, while relieving the maintainer of the burden.
> 
> And if desired, that can be seen as the start of a phase toward
> bumping it to unstable, but with more notice, and a defined process.

Ah, no-longer-my-problem; yeah, seems we're having a different timeout
in mind then. I'd still would like to see this rather as a last resort
solution ("it's been a long while now, ..."), rather than a short ("yes,
I can ditch it now, ...") solution for when it is really needed; as we
just want to relieve some lingering maintenance weight, while not
moving more weight than needed to the architecture teams.

> > The part about ATs taking the bug sounds like what came up at
> > FOSDEM. +1
> 
> <snip>
> > > The wonderful thing about policy is that it reflects (or is
> > > supposed to) consensus opinion with light to contemporaneous
> > > circumstance. Since circumstances change, so too must policy be
> > > open to change or adaptation, in line with basic principles.
> > 
> > In this case -* works fine for what it intends to work; changing the
> > policy to redefine it to fit another purpose, while no longer
> > reflecting its original purpose is what we should avoid at all cost.
> 
> Utter nonsense. Back that up with some consequent to justify why we
> should "avoid it at all costs", bearing in mind the below.

Already did that in the other thread, let's not bring it up again; it
was shown that multiple words' meaning were bent to make it mean the
other thing that you want to use it for here, while that changes the
borders of its original meaning such that you can no longer it that way.

By all means, it is possible to change it with a vote; but just plain
out using it in a different way than how we defined it is inconsistent.

> > > So let's look at extending it, since there is *no* technical
> > > problem:
> > 
> > You have colons after the above quoted sentence with nothing after
> > it.
> > 
> > (An eye for an eye... :D)
> 
> Don't be so facile: the proposed extended policy is what follows.

Exactly it does; so, let's avoid the use of that reply. :)

> > > 'The redundant -* keyword is a metadata marker.
> > 
> > The keyword has a meaning, therefore it is not redundant.
> 
> It is technically redundant, since the package manager does not infer
> any existing keywords, so there is nothing to strip. As a metadata
> marker, no ofc it's not redundant: but that's what I'm proposing to
> use.

It could be towards the package manager, like quite a few other things
(eg. the exact name of a license); that doesn't imply that it's
redundant in general, as they have their specific meaning.

> > > It is used to indicate, in line with the semantic of "strip all",
> > > that the ebuild in question can only be used for the specific
> > > archs noted for one of two reasons:
> > > 
> > > 1) The package-maintainer has stabilised a newer version on at
> > > least one arch personally, the ATs for the archs listed have
> > > taken longer than XX days to test and stabilise, and the
> > > maintainer would otherwise drop the ebuild altogether.
> > > 
> > > 2) The package version is not worth trying to test on unlisted
> > > archs.'
> > 
> > (1) changes its meaning in a way that you can no longer interpret
> > the keyword solely as (2). The whole purpose of (2) is that you can
> > interpret it that you should not test it as it was found not to
> > work; (1) is different from that, as it means that there was no
> > manpower to test it. (1) would move ebuilds to -* and be
> > misinterpreted as (2).
> 
> Nope: 1) implies 2) so any existing use of the marker solely in the
> context of 2) still works. It certainly is not worth testing an old
> ebuild that would have been dropped on an unlisted arch: whoever is
> looking at the ebuild, should instead use a newer version.

1) means a package is unstable (~), 2) means a package is unusable (-),
there is no hence no implication; even if there were, this discussion is
solely about dropping it from stable. -* does more than what is needed.

"arch minorarch" -> "minorarch" on the old version can suffice, with
"arch ~minorarch" on the newer version; then what is "-* minorarch"
needed for? What is its additional benefit over what I suggest here?

> > > The policy which flows from that is:
> > > 
> > > 'In the first case, it is QA policy that a comment of the form:
> > > # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN
> > > is required on the line immediately above the KEYWORDS
> > > declaration.
> > > 
> > > This is to aid both automated identification, and human
> > > collaboration.'
> > > 
> > > (The latter explains why a URL, not a bug id, is required. We're
> > > trying to get end-users to help us, so let's make it easy for
> > > them.)
> > >
> > > I'd personally add:
> > > 'It is envisaged that the line will be added by an automated tool
> > > at some point.'
> > > 
> > > ..as well as a requirement for a bug id in the second case, but I
> > > don't know it well enough; I'd certainly want some sort of
> > > tracking.
> > 
> > This yields extra commits; comments in ebuilds are directed towards
> > maintainers, for users we should use another approach to contact
> > them.
> 
> No it keeps all the useful info in one place: the ebuild, where it's
> easy to edit and see. The commit is already implicit in dropping the
> ebuild to "-* slower arch": all the policy does is require a link to
> the original stabilisation bug, which may be a tracker if multiple
> archs are involved. However none of that is the maintainer's concern:
> all they need do, when facing this rare situation, is change the
> keywords and add a link to the bug (commenting is SOP for most unusual
> situations in ebuilds), instead of dropping the arch's stable version.

It's an extra commit to add the comment prior to stabilization.

> The link is easy to extract for an automated external to show to the
> user, like the mangler in the above, or a porcelain layer, given an
> indicator from the mangler.

This can be implemented by checking Bugzilla; there's no need for a
comment, as that leaves room for missing comments misrepresenting that
there is no stabilization when there is in fact stabilization going on.

> It's also a helluva lot less work than package.mask, as well as
> keeping all the info in the ebuild, where it's easier to handle.

Adding a generic or specific text to package.mask can be scripted;
beyond that, it is usable. package.mask is easier for QA to handle;
given that it's a single file, instead of ebuilds across the tree.

> > > It's hardly an onerous requirement, and a small price to pay: if
> > > we have a policy for how a maintainer drops an ebuild from his
> > > queue due to it being stabilised, which we can trigger scripts
> > > from, we avoid the arguments every year or so, and stop archs from
> > > being borked. We can also speed it up, since we have a mechanism
> > > in-place to support it, as opposed to ad-hoc, flawed
> > > decision-making.
> > > 
> > > The thing I think that's missing from this debate, is an
> > > acknowledgement, or an understanding, that arch-teams are all
> > > effectively working on their own variant of the shared Gentoo
> > > tree. (This includes the concept of upgrades working as smoothly
> > > as they do on other archs, at the PM level.) Similar to other
> > > portability efforts, the tree must support them in that, not make
> > > it harder.
> > > 
> > > Especially not because another developer doesn't care about the
> > > arch in question. That's *natural*, but _cannot_ be cause for
> > > dropping stable ebuilds. The only issue is to take the bugs off
> > > their hands, and we can do that with a simple tweak in metadata,
> > > so ffs let's get on and do it.
> > 
> > +1 on this thought.
> 
> Well I wish you could see that steev's solution, with a bit of
> standard commenting, fulfils both your +1s

The +1 is just on the thought part, not the entire thing.

> and doesn't lead to broken arch-trees. It also doesn't require any
> communication with a non-responsive arch, and can form the basis of a
> much more useful mode of collaboration, from where I'm sitting.

It however leads to different things and requires different things; so,
there are trade-offs to be made. Some of the other solutions put
forward also make collaboration an option; even outside of all
solutions, collaboration by joining an arch team is already possible.

> Post-facto complaints about an upstream project decision to keep
> migration code, or about the anguish of seeing an older version
> stable on some arch you don't even care about (or you wouldn't be
> dropping their last stable version) are an order-of-magnitude less
> concerning. By all means address them (up to the project in the
> first case, adjust your script in the second) but let's at least
> admit they are less of a problem than this continual argument, and
> the consequent ill-feeling brought about by lack of a defined
> action to take.

Action by the QA team was taken last month, and tomorrow another could
be made; this thread is making progress, and participating therein is
part of a preparation for the meeting that will take place tomorrow.

> The issue about confusion with multiple archs has already been
> addressed by making the original stabilisation bug a tracker for
> the N slow archs, if there are more than one.
> 
> Most of this can be automated, or is at least amenable to it. And
> that discussion is *far* more interesting than "you broke our arch"
> vs "so what, you're too slow".

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

Re: [gentoo-dev] Re: dropping redundant stable keywords

[Ciaran McCreesh]

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

On Tue, 18 Feb 2014 22:10:23 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> As detailed before, -* has a different meaning defined by policy; if
> we want to see that changed it should be brought up for a vote,
> otherwise its usage in discussions like these seems to suggest to
> break an existing policy. So, I read this as "arch" whenever it is
> brought up.

You would have to do this across an EAPI, since it's a change that
matters to the package mangler. Right now, if a -* is there, the package
mangler shouldn't suggest changing accepted keywords for that package
if it's suggesting how to deal with an unsatisfiable resolution.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: dropping redundant stable keywords

[Tom Wijsman]

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

On Tue, 18 Feb 2014 21:16:43 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Feb 2014 22:10:23 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > As detailed before, -* has a different meaning defined by policy; if
> > we want to see that changed it should be brought up for a vote,
> > otherwise its usage in discussions like these seems to suggest to
> > break an existing policy. So, I read this as "arch" whenever it is
> > brought up.
> 
> You would have to do this across an EAPI, since it's a change that
> matters to the package mangler. Right now, if a -* is there, the
> package mangler shouldn't suggest changing accepted keywords for that
> package if it's suggesting how to deal with an unsatisfiable
> resolution.

+1, in that case changing to ** indeed would be harmful; because -*
denotes that the package has been tested not to work, so suggesting **
would be a waste of time. 

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