[gentoo-dev] rfc: revisiting our stabilization policy

[gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

All,

It is becoming more and more obvious that we do not have enough manpower
on the arch teams, even some of the ones we consider major arch's, to
keep up with stabilization requests. For example, there is this bug [1],
which is blocking the stabilization of several important packages.

I spoke to one of the team members on one of the affected arch teams on
this bug a couple of weeks ago, and was told just that stabilization
takes time. I pointed out that this was affecting important packages and
I felt that the arch teams should step up their efforts when it comes to
important packages. The arch team member disagreed unless the issue is a
security bug.

The council decision below [2] has made it possible to move on for some
arch's by removing old stable versions of packages 90 days after the
stable request is filed and the arch teams are added if there has been
no action by the specific arch teams listed in the decision, and those
arch teams are the only ones on the bug.

I think we need a global policy that either helps keep the stable tree
up to date or reverts an architecture to ~ over time if the arch team
can't keep up.

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.

Also, I think we can agree that allowing maintainers to stabilize new
software on architectures they do not have access to wouldn't be good.

I want comments wrt two ideas:

1. I think maintainers should be able to stabilize their packages on arch's
they have access to. I think this is allowed by some arch teams, but I
think it would be good to formalize it.

2. I would like to see the policy below applied to all arch's [2].

Thoughts?

William

[1] http://bugs.gentoo.org/487332
[2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 04:37 PM, William Hubbs wrote:
> 
> 2. I would like to see the policy below applied to all arch's [2].

[ ] Yup
[X] Nope

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 04:37 PM, William Hubbs wrote:
> > 
> > 2. I would like to see the policy below applied to all arch's [2].
> 
> [ ] Yup
> [X] Nope

The reverse of this would be to let maintainers stabilize on all arch's
after 90 days, then they are allowed to remove all but the latest stable
version. This isn't good though because maintainers would be stabilizing
packages on arch's where they can't test.

The stable tree is significantly behind because the arch teams are so
short staffed, and this prooposal is an attempt to fix that.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 05:33 PM, William Hubbs wrote:
> On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
>> On 01/14/2014 04:37 PM, William Hubbs wrote:
>>>
>>> 2. I would like to see the policy below applied to all arch's [2].
>>
>> [ ] Yup
>> [X] Nope
> 
> The reverse of this would be to let maintainers stabilize on all arch's
> after 90 days, then they are allowed to remove all but the latest stable
> version. This isn't good though because maintainers would be stabilizing
> packages on arch's where they can't test.
> 
> The stable tree is significantly behind because the arch teams are so
> short staffed, and this prooposal is an attempt to fix that.

It's attempting to fix a headache with a bullet. The arch teams are
lagging behind, you're annoyed, I get it. Give 'em hell. But don't break
stable to make a point.

For users, both options are worse than the status quo.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 05:33 PM, William Hubbs wrote:
> > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >>>
> >>> 2. I would like to see the policy below applied to all arch's [2].
> >>
> >> [ ] Yup
> >> [X] Nope
> > 
> > The reverse of this would be to let maintainers stabilize on all arch's
> > after 90 days, then they are allowed to remove all but the latest stable
> > version. This isn't good though because maintainers would be stabilizing
> > packages on arch's where they can't test.
> > 
> > The stable tree is significantly behind because the arch teams are so
> > short staffed, and this prooposal is an attempt to fix that.
> 
> It's attempting to fix a headache with a bullet. The arch teams are
> lagging behind, you're annoyed, I get it. Give 'em hell. But don't break
> stable to make a point.
> 
> For users, both options are worse than the status quo.

The first option would start reverting things back to ~ and users would
have to unmask them.

The second option would introduce new things to stable which may not be
stable due to not being tested on the arch.

The second option is worse than the first imo, that's why I didn't
propose it first.

The status quo is not good, because we are forced to keep old, and
potentially buggy, versions of software around longer than necessary.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Jeff Horelick]

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

On 14 January 2014 18:11, William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> > On 01/14/2014 05:33 PM, William Hubbs wrote:
> > > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> > >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> > >>>
> > >>> 2. I would like to see the policy below applied to all arch's [2].
> > >>
> > >> [ ] Yup
> > >> [X] Nope
> > >
> > > The reverse of this would be to let maintainers stabilize on all arch's
> > > after 90 days, then they are allowed to remove all but the latest
> stable
> > > version. This isn't good though because maintainers would be
> stabilizing
> > > packages on arch's where they can't test.
> > >
> > > The stable tree is significantly behind because the arch teams are so
> > > short staffed, and this prooposal is an attempt to fix that.
> >
> > It's attempting to fix a headache with a bullet. The arch teams are
> > lagging behind, you're annoyed, I get it. Give 'em hell. But don't break
> > stable to make a point.
> >
> > For users, both options are worse than the status quo.
>
> The first option would start reverting things back to ~ and users would
> have to unmask them.
>
> The second option would introduce new things to stable which may not be
> stable due to not being tested on the arch.
>
> The second option is worse than the first imo, that's why I didn't
> propose it first.
>
> The status quo is not good, because we are forced to keep old, and
> potentially buggy, versions of software around longer than necessary.
>
> William
>
>


I think the simplest short-term solution might be to add teams that are
looking for ArchTesters to the Staffing Needs page on the wiki and promote
that page like crazy. I'd be more likely to do a lot more stabilizations if
it wasn't just me going on my experience and running through the AT
procedures myself (they're also a bit lengthy if you follow them properly,
which I prefer to).

I do feel some arches should be a bit deprecated. Not quite as severely
other arches the council deprecated a few months back, but something.

Also, to ease the burden on Arches, it'd be nice if the maintainer would do
some of the archtesting work on all their available arches rather than
making the AT's/arch teams do it...For example, almost everyone who has a
amd64 system, can easily make a x86 chroot (or VM) to test in.

Another option (and I don't mean to step on any toes or call anyone out
here, these are just examples) may be to just deprecate stabilizing certain
software. Packages such as the stuff in app-vim/ or app-emacs/ or some
games or some scientific software. For the editor plugins, most people do
not get them from the package manager I feel and a Vim plugin requires
almost as much arch testing work as a new version of grep, for example...

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 15:37:19 -0600
William Hubbs <williamh@gentoo.org> wrote:

> Thoughts?

In this situation, I see three opposite ends of choices:

  1. "We do nothing"; which means that as a side effect either less
  often a version would be picked for stabilization or stabilizations
  will just take longer due to a longer queue. The question here is
  whether the queue is actually growing; to get a quick idea, we could
  compare the amount of bugs we have now compared to those of last time.

  Advantage:    We keep the same policy and quality of stabilization.

  Disadvantage: Stable runs further behind. Waiting time. Frustration.

  Resources:    We need to find more people for the arch teams.

  2. "We crowd source it"; which means we tackle the 'low manpower'
  problem itself, we invite at a larger scale feedback for packages in
  one or another way. This ranges from a simple reminder when merging a
  non-stable package to report back whether it is working, to a more
  large scale new website effort where this can be done much more
  organized; but that's a whole discussion on its own.

  Advantage:    Power to the community. Need for arch teams decreases.

  Disadvantage: Stabilization quality could drop. Enough feedback?

  Resources:    We need to patch up and/or write enough to pull
                attention from the user that there aid is needed.

  3. "We make stable mean less"; which means that we accept the 'low
  manpower' problem, this would as a consequence thus mean that because
  we cannot put in enough effort to deem everything stable anymore. The
  word 'stable' would thus mean less, instead of 'thoroughly tested by
  a separate person' it becomes 'tested by the same maintainer'.

  Advantage:    Gentoo becomes slightly more bleeding edge.

  Disadvantage: Problematic for important packages were stabilization 
                is really needed; 'stability' of some user application
                has a much smaller meaning than on a library shared
                between multiple applications of the user.

  Resources:    Less resources used, though it might yield more bugs.

Of course this is not meant to limit other choices, there might be
others and I hope people bring them forward; as a closing word it feels
hard to decide here, especially since it can have quite an effect on
the distribution. As put above neither option seems convincing, neither
option seems like it is without risk; does anyone have a different view?

Unless we only do a small version of those options, like changing a
minor detail instead of pushing it through at once; which could be a
more safe step forward. Which smaller options do we have here?

If at all, maybe experiment something on one arch to start with?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 16:57:30 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 04:37 PM, William Hubbs wrote:
> > 
> > 2. I would like to see the policy below applied to all arch's [2].
> 
> [ ] Yup
> [X] Nope

For which reason?

I could do

[✓] Yup
[X] Nope

'cause a stable version that's no longer stable (due to found bugs)
shouldn't remain, otherwise it is falsely shown to the users as being
stable; whereas it could very well be old, insecure and buggy instead.

Together with a news message, users could appreciate this.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 525 bytes --]

Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> On Tue, 14 Jan 2014 15:37:19 -0600
> 
> William Hubbs <williamh@gentoo.org> wrote:
> > Thoughts?
> 
> In this situation, I see three opposite ends of choices:
> 

Here's another idea: 

4. Friendly ask the arch teams / make a policy that @system packages come 
first. 

(maybe these stable requests could be marked "major" in bugzilla then?)


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 17:43:57 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> It's attempting to fix a headache with a bullet. The arch teams are
> lagging behind, you're annoyed, I get it. Give 'em hell. But don't
> break stable to make a point.
>
> For users, both options are worse than the status quo.

When you do nothing then things are bound to get worse, under the
assumption that manpower doesn't change as well as the assumption that
the queue fills faster than stabilization bugs get added to it.

As a result of this, stable will eventually become broken. It is up to
you as well as us whether to consider it to be broken right now. Will
it be in a month from now? What about in a year?

Will we wait for hell? Or try to prepare and/or fix it now?

Maybe there are other options if these can be deemed as being worse.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Anthony G. Basile]

On 01/14/2014 07:06 PM, Andreas K. Huettel wrote:
> Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
>> On Tue, 14 Jan 2014 15:37:19 -0600
>>
>> William Hubbs <williamh@gentoo.org> wrote:
>>> Thoughts?
>> In this situation, I see three opposite ends of choices:
>>
> Here's another idea:
>
> 4. Friendly ask the arch teams / make a policy that @system packages come
> first.
>
> (maybe these stable requests could be marked "major" in bugzilla then?)
>
>

Actually that's a very good idea.  In fact, since those are the critical 
packages we can have the arch teams focus on them, and allow more relax 
policies of stabilization on less critical packages.




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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 18:22:51 -0500
Jeff Horelick <jdhore@gentoo.org> wrote:

> I think the simplest short-term solution might be to add teams that
> are looking for ArchTesters to the Staffing Needs page on the wiki

Adding a lot of them could make it noisy, I think we could just make
one entry to link to a page that lists them in detail; alternatively we
can work with some kind of categorization on the same page.

You could determine the success of the current version by checking
whether BSD and x86 arch teams (currently listed there) have seen
enough new arch testers over the time the need was listed.

> and promote that page like crazy.

It's linked to from the Gentoo homepage near the bottom of the left
hand side list; I was thinking, maybe we could add something like a
200x250 sized banner advertisement somewhere advertising the ability to
contribute and forward people to a relevant Wikipedia page.

Besides it being linked there, hwoarang has very recently linked to
this from the Google+ website; on IRC we have this URL near the end of
the #gentoo-dev-help topic.

Recently I revamped https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
where there are two lines that could invite people to the arch testing
business, these two:

 - Become an arch tester; for instance, check out the arch teams x86 and
   amd64.

 - Become a Gentoo Developer and join one or more of the many herds
   to contribute to interesting project(s). 

But I feel like that page itself can use much more attention.

Is anyone here good in advertising and promotion skills? :)

> I'd be more likely to do a lot more
> stabilizations if it wasn't just me going on my experience and
> running through the AT procedures myself (they're also a bit lengthy
> if you follow them properly, which I prefer to).

We could optimize the AT pages to make them look less scary to people;
especially if it's described as 'bit length' it doesn't sound like a
neat workflow that I would be wanting to read through, maybe some
things would be too wordy here or some things could be put in a tool?

(Haven't actually looked, but reading length can matter a lot)

> I do feel some arches should be a bit deprecated. Not quite as
> severely other arches the council deprecated a few months back, but
> something.

Yes, maybe; whatever we do, I hope it to be an arch-by-arch approach.

> Also, to ease the burden on Arches, it'd be nice if the maintainer
> would do some of the archtesting work on all their available arches
> rather than making the AT's/arch teams do it...For example, almost
> everyone who has a amd64 system, can easily make a x86 chroot (or VM)
> to test in.

The problem (at least for overworked maintainers) is that this moves
efforts from one place to another; and thus, while this could result in
near the same quality stabilizations, it will remove (or delay) either
work efforts or quality in other places due to the lack of time.

> Another option (and I don't mean to step on any toes or call anyone
> out here, these are just examples) may be to just deprecate
> stabilizing certain software. Packages such as the stuff in app-vim/
> or app-emacs/ or some games or some scientific software. For the
> editor plugins, most people do not get them from the package manager
> I feel and a Vim plugin requires almost as much arch testing work as
> a new version of grep, for example...

Sounds like a good idea, but how do we translate that to the user;
always mark them stable, or always mark them unstable? Do we want users
to explicitly accept keywords on these packages?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Wed, 15 Jan 2014 01:06:07 +0100
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> > On Tue, 14 Jan 2014 15:37:19 -0600
> > 
> > William Hubbs <williamh@gentoo.org> wrote:
> > > Thoughts?
> > 
> > In this situation, I see three opposite ends of choices:
> > 
> 
> Here's another idea: 
> 
> 4. Friendly ask the arch teams / make a policy that @system packages
> come first. 

Hmm, I'm wondering if that has an actual use or whether that would just
move the problem. The bug in question that WilliamH demonstrated is
indeed part of @system; but shouldn't be, it is due to functions.sh.

So, assuming OpenRC wouldn't have been part of it, as it should be; this
suggestion wouldn't change WilliamH's problem. Then comes the question
whether we expand on all options in the virtuals, dependencies that
come in through certain USE flags of @system; as well as the
important libraries that aren't necessarily part of @system.

Though on the other hand, what would be the point of prioritizing
stabilization of important libraries if the applications are way too
long detailed? Maybe it could improve their workflow of picking bugs a
bit, dunno; I guess arch teams can shed some light on this last part.

> (maybe these stable requests could be marked "major" in bugzilla
> then?)

Given that I think that we want more than just @system in the future,
but those other things wouldn't be as important as @system and thus
need a different way of being marked; I think we should rather pick
"blocker" for @system packages. Then it still leaves us "critical" and
"major" available for packages that are in between being the
most and least important.

Though as said, I think this would make only certain people happy; the
question is to whereas how unhappy the other people would be, I can't
really comment on this because of completely using unstable 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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 19:17:35 -0500
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 01/14/2014 07:06 PM, Andreas K. Huettel wrote:
> > Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> >> On Tue, 14 Jan 2014 15:37:19 -0600
> >>
> >> William Hubbs <williamh@gentoo.org> wrote:
> >>> Thoughts?
> >> In this situation, I see three opposite ends of choices:
> >>
> > Here's another idea:
> >
> > 4. Friendly ask the arch teams / make a policy that @system
> > packages come first.
> >
> > (maybe these stable requests could be marked "major" in bugzilla
> > then?)
> >
> >
> 
> Actually that's a very good idea.  In fact, since those are the
> critical packages we can have the arch teams focus on them, and allow
> more relax policies of stabilization on less critical packages.

Besides allowing certain packages to be set a higher policy, we could
also recommend that maintainers lower it if needed; for example:

    If I want to stabilize some plugin, it doesn't really have to be
    put "Normal" you know; I wouldn't bother it to be "Enhancement".

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Wed, Jan 15, 2014 at 01:38:08AM +0100, Tom Wijsman wrote:
> On Wed, 15 Jan 2014 01:06:07 +0100
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
> > Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> > > On Tue, 14 Jan 2014 15:37:19 -0600
> > > 
> > > William Hubbs <williamh@gentoo.org> wrote:
> > > > Thoughts?
> > > 
> > > In this situation, I see three opposite ends of choices:
> > > 
> > 
> > Here's another idea: 
> > 
> > 4. Friendly ask the arch teams / make a policy that @system packages
> > come first. 
> 
> Hmm, I'm wondering if that has an actual use or whether that would just
> move the problem. The bug in question that WilliamH demonstrated is
> indeed part of @system; but shouldn't be, it is due to functions.sh.

Correct; Openrc ultimately will not be part of @system; it is provided
by a virtual that is.

If you want to say @system, you have to include all rdepends of virtuals
in @system and all packages that are dependencies of any packages in
@system, at least.

Keeping track of that will be difficult at best.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 06:11 PM, William Hubbs wrote:
>>
>> For users, both options are worse than the status quo.
> 
> The first option would start reverting things back to ~ and users would
> have to unmask them.
> 
> The second option would introduce new things to stable which may not be
> stable due to not being tested on the arch.
> 
> The second option is worse than the first imo, that's why I didn't
> propose it first.
> 
> The status quo is not good, because we are forced to keep old, and
> potentially buggy, versions of software around longer than necessary.

So you're going to force stable users onto the unstable, untested
version, which they could have done anyway if they wanted to. Strictly
worse than the status quo (where it's optional).

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 07:13 PM, Tom Wijsman wrote:
>>
>> For users, both options are worse than the status quo.
> 
> When you do nothing then things are bound to get worse, under the
> assumption that manpower doesn't change as well as the assumption that
> the queue fills faster than stabilization bugs get added to it.
> 
> As a result of this, stable will eventually become broken. It is up to
> you as well as us whether to consider it to be broken right now. Will
> it be in a month from now? What about in a year?
> 
> Will we wait for hell? Or try to prepare and/or fix it now?
> 
> Maybe there are other options if these can be deemed as being worse.
> 

As I mentioned in a reply to William, right now I can decide when stuff
is broken and keyword the newer versions. The proposal is to force me
onto the new versions, which is strictly worse from my perspective.

The whole issue of how much it sucks that stable is lagging is orthogonal.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 19:47:50 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 06:11 PM, William Hubbs wrote:
> >>
> >> For users, both options are worse than the status quo.
> > 
> > The first option would start reverting things back to ~ and users
> > would have to unmask them.
> > 
> > The second option would introduce new things to stable which may
> > not be stable due to not being tested on the arch.
> > 
> > The second option is worse than the first imo, that's why I didn't
> > propose it first.
> > 
> > The status quo is not good, because we are forced to keep old, and
> > potentially buggy, versions of software around longer than
> > necessary.
> 
> So you're going to force stable users onto the unstable, untested
> version, which they could have done anyway if they wanted to. Strictly
> worse than the status quo (where it's optional).

This is under the assumption that the user knows of the state of the
stabilization worsening; if the user is unaware of that change, the
"could have done anyway" might be less common and first something bad
would need to happen before they realize the worsened stabilization.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> 
> This is under the assumption that the user knows of the state of the
> stabilization worsening; if the user is unaware of that change, the
> "could have done anyway" might be less common and first something bad
> would need to happen before they realize the worsened stabilization.
> 

If I don't realize it, it ain't broke.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 19:50:30 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 07:13 PM, Tom Wijsman wrote:
> >>
> >> For users, both options are worse than the status quo.
> > 
> > When you do nothing then things are bound to get worse, under the
> > assumption that manpower doesn't change as well as the assumption
> > that the queue fills faster than stabilization bugs get added to it.
> > 
> > As a result of this, stable will eventually become broken. It is up
> > to you as well as us whether to consider it to be broken right now.
> > Will it be in a month from now? What about in a year?
> > 
> > Will we wait for hell? Or try to prepare and/or fix it now?
> > 
> > Maybe there are other options if these can be deemed as being worse.
> > 
> 
> As I mentioned in a reply to William, right now I can decide when
> stuff is broken and keyword the newer versions.

As in the mail I send seconds ago, I could complete this sentence with
"... because I know stabilaziton has lagged / worsened"; but how does
the user know of that?

If we keep things the same we might consider to bring out a news item
to at least make them aware of this, that news item might even be useful
to attract new arch testers at the same time.

> The proposal is to force me onto the new versions, which is strictly
> worse from my perspective.
>
> The whole issue of how much it sucks that stable is lagging is
> orthogonal.

That's one of the proposals, there are others; and staying where we are
is one of them, but we need to account for that (eg. recruit more,
perhaps a news item, ...) to keep that option a good choice.

Having stabilization eventually die due to the extra lag that collected
over time is just another way of forcing you onto the new versions,
which makes it less worse than you think it is; it might take a bit
longer and yield a slow and painful death.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 20:11:24 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> > 
> > This is under the assumption that the user knows of the state of the
> > stabilization worsening; if the user is unaware of that change, the
> > "could have done anyway" might be less common and first something
> > bad would need to happen before they realize the worsened
> > stabilization.
> > 
> 
> If I don't realize it, it ain't broke.

So, you're going to wait for corruption, a security breach or something
along those lines to happen first?

Corruption is what stabilization of consistent dependencies can
prevent, rather than relying on a >=... dependency too much. Security
is what prevents security bugs from remaining present. And so on...

If you don't realize it, it ain't fixed.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 18:46:06 -0600
William Hubbs <williamh@gentoo.org> wrote:

> If you want to say @system, you have to include all rdepends of
> virtuals in @system and all packages that are dependencies of any
> packages in @system, at least.
> 
> Keeping track of that will be difficult at best.

Trying to depclean it gives a warn, which is a simple form to check it;
we could probably optimize this if it needs to run faster. Or we have
some separate script generate an online list (like our rev deps) to
quickly check it up with; could go a step further, one can set up a
tool to ensure the bugs get set accordingly.

For example; see security's GLSA bug bot, which is much more complex.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> On Tue, 14 Jan 2014 20:11:24 -0500
> Michael Orlitzky <mjo@gentoo.org> wrote:
> 
>> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
>>>
>>> This is under the assumption that the user knows of the state of the
>>> stabilization worsening; if the user is unaware of that change, the
>>> "could have done anyway" might be less common and first something
>>> bad would need to happen before they realize the worsened
>>> stabilization.
>>>
>>
>> If I don't realize it, it ain't broke.
> 
> So, you're going to wait for corruption, a security breach or something
> along those lines to happen first?

I will wait for them to be *known*.

Security stabilizations are already treated special, so while they'd
make a nice example here you don't get to invoke them =)

It's highly unlikely that one day a stable piece of software is just
going to start corrupting data randomly when some other stable package
is updated. Why? Because arch testers have to test them before they go
stable! It's even more unlikely that upgrading to untested stuff would
be safer than staying put, which is really all I care about given a
choice between the two.

For really bad cases like data corruption we already have procedures
that allow quick stabilization ("reasonable amount of time..."). All
we're really talking about here is forcing me to upgrade to an unstable
package for some features or bugfixes I don't care about.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> > 
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the state of the
> >>> stabilization worsening; if the user is unaware of that change, the
> >>> "could have done anyway" might be less common and first something
> >>> bad would need to happen before they realize the worsened
> >>> stabilization.
> >>>
> >>
> >> If I don't realize it, it ain't broke.
> > 
> > So, you're going to wait for corruption, a security breach or something
> > along those lines to happen first?
> 
> I will wait for them to be *known*.
> 
> Security stabilizations are already treated special, so while they'd
> make a nice example here you don't get to invoke them =)
> 
> It's highly unlikely that one day a stable piece of software is just
> going to start corrupting data randomly when some other stable package
> is updated. Why? Because arch testers have to test them before they go
> stable! It's even more unlikely that upgrading to untested stuff would
> be safer than staying put, which is really all I care about given a
> choice between the two.
> 
> For really bad cases like data corruption we already have procedures
> that allow quick stabilization ("reasonable amount of time..."). All
> we're really talking about here is forcing me to upgrade to an unstable
> package for some features or bugfixes I don't care about.

After the package has been sitting in ~arch for 90 days with an open
stable request with no blockers that the arch team has not taken any
action on. We are not talking about randomly yanking package versions,
just doing something when arch teams are not responsive, and it seems
that the cleanest thing to do would be to remove the old versions.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 09:09 PM, William Hubbs wrote:
> 
> After the package has been sitting in ~arch for 90 days with an open
> stable request with no blockers that the arch team has not taken any
> action on. We are not talking about randomly yanking package versions,
> just doing something when arch teams are not responsive, and it seems
> that the cleanest thing to do would be to remove the old versions.
> 

People running stable value... stability. I would much rather wait for
the arch teams to get un-busy than to be forced to upgrade to something
untested. Why would I care if it takes another month? Strictly from a
user's perspective. I don't, unless I do, in which case I know that I
do, and I could just keyword the thing if I wanted to.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 20:36:10 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> > 
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the state of
> >>> the stabilization worsening; if the user is unaware of that
> >>> change, the "could have done anyway" might be less common and
> >>> first something bad would need to happen before they realize the
> >>> worsened stabilization.
> >>>
> >>
> >> If I don't realize it, it ain't broke.
> > 
> > So, you're going to wait for corruption, a security breach or
> > something along those lines to happen first?
> 
> I will wait for them to be *known*.

The question is whether you or the user will want to wait whether it
*happens* to you; of course you can restrict yourself to what's known,
but you cannot keep track of *everything that's known* out there easily.

And even if you were hundred security experts tracking everything; that
wouldn't reflect the user, neither our security team. Just like
stabilization, efforts are limited in security; so, you're going to
have to rely on a problem similar to that of WilliamH.

Besides that, *unknown* things could happen to you too; are you sure you
definitely want to wait for that to happen? Or rather upgrade?

> Security stabilizations are already treated special, so while they'd
> make a nice example here you don't get to invoke them =)

Assuming every security bug is known by the public. =)

> It's highly unlikely that one day a stable piece of software is just
> going to start corrupting data randomly when some other stable package
> is updated. 

That is exactly one of the popular ways to introduce incompatibilities;
and thus, it can cause corruption or something less worse than that to
happen. There are other things like data loss, like we see happen more
often with hangs and crashes; corruption is just one example of many...

> Why? Because arch testers have to test them before they go stable!

Testing all reverse dependencies of sys-libs/glibc or one of the other
important libraries is rather impossible given the lack of resources,
you're relying on the same problem WilliamH has here; well, you could
select a sample set of them perhaps, but you cannot assure there to be
no regression in a small set of the reverse dependencies.

"Arch testers have to test them before they go stable!" Why? Because
of the lack of upper bounds on deps, neither do they have proper slots,
and not to forget that stabilizations are laggy; interesting!

> It's even more unlikely that upgrading to untested stuff would
> be safer than staying put, which is really all I care about given a
> choice between the two.

untested (subjective) != unstable   (objective),
safer    (subjective) != stable     (objective),
I care   (subjective) != users care (objective).

There's doubt in this paragraph, but no constructive reasoning.

You are focusing on a single solution instead of focusing on the actual
problem and the other solutions; while you may very well care for one
solution not to happen, that doesn't ensure that we keep what we have.

If you tell us what you want, we can do something about it. If you tell
us what you don't want, but don't tell that to us based on what you
want; it becomes a vote without any value instead than a discussion.

> For really bad cases like data corruption we already have procedures
> that allow quick stabilization ("reasonable amount of time...").

Turn this sentence around and you'll see how quick stabilization leads
to less data corruption.

> All we're really talking about here is forcing me to upgrade to an
> unstable package for some features or bugfixes I don't care about.

You are focusing on a single solutions instead of ... [see above].

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 21:21:51 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/14/2014 09:09 PM, William Hubbs wrote:
> > 
> > After the package has been sitting in ~arch for 90 days with an open
> > stable request with no blockers that the arch team has not taken any
> > action on. We are not talking about randomly yanking package
> > versions, just doing something when arch teams are not responsive,
> > and it seems that the cleanest thing to do would be to remove the
> > old versions.
> > 
> 
> People running stable value... stability.

gentoo-sources-3.10.25 is stable on the most important arches; but,
other arches are left in the dark with a stable 3.10.7(-r1). Now, what
is well known is that kernel.org upstream backports mostly known fixes;
as their goals is for this long term stable branch to increase the
value of what you claim people running stable need... stability.

But, as those people running stable on those arches are stuck on
3.10.7(-r1); heh, they're not running the more stable kernel at all.

> I would much rather wait for the arch teams to get un-busy than to be
> forced to upgrade to something untested.

If they get stabilization requests faster than they can stabilize, then
they will remain busy for as long as we don't get manpower to turn
around the tide; and as mentioned in the mail of a few minutes ago,
there are other options possible too. Forcing is just one of them.

> Why would I care if it takes another month?

What about another year? Or ten years? Why would users care?

> Strictly from a user's perspective. I don't, unless I do, in which
> case I know that I do, and I could just keyword the thing if I wanted
> to.

This is the exact same argument as in your other mail, which is your
point of view; this is under the assumption that you know that
stabilization is worsening over time, which users may not perceive.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michael Orlitzky]

On 01/14/2014 09:34 PM, Tom Wijsman wrote:
> 
>> Strictly from a user's perspective. I don't, unless I do, in which
>> case I know that I do, and I could just keyword the thing if I wanted
>> to.
> 
> This is the exact same argument as in your other mail, which is your
> point of view; this is under the assumption that you know that
> stabilization is worsening over time, which users may not perceive.
> 

I've written too many emails today, I hereby give up =)

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 20:09:34 -0600
William Hubbs <williamh@gentoo.org> wrote:

> After the package has been sitting in ~arch for 90 days with an open
> stable request with no blockers that the arch team has not taken any
> action on. We are not talking about randomly yanking package versions,
> just doing something when arch teams are not responsive, and it seems
> that the cleanest thing to do would be to remove the old versions.

Exactly, the common case for stabilization bugs is that stabilization
just happens; as far as I have seen, it is rather rare that another
bug blocks the stabilization bug. At least this is the case for the
common package; as for important bugs, which should be treated with
more care, it is more common for these blocking bugs to get filed.

If the arch hasn't responded for X months; then marking a version
stable oneself on a non-important package should be acceptable, it
doesn't yield any huge problem afaik and isn't that much different.

And for that occasional mis-guess, *boohoo*, the user can just file a
bug; which ironically even happens occasionally for stable packages.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Tue, Jan 14, 2014 at 09:21:51PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 09:09 PM, William Hubbs wrote:
> > 
> > After the package has been sitting in ~arch for 90 days with an open
> > stable request with no blockers that the arch team has not taken any
> > action on. We are not talking about randomly yanking package versions,
> > just doing something when arch teams are not responsive, and it seems
> > that the cleanest thing to do would be to remove the old versions.
> > 
> 
> People running stable value... stability. I would much rather wait for
> the arch teams to get un-busy than to be forced to upgrade to something
> untested. Why would I care if it takes another month? Strictly from a
> user's perspective. I don't, unless I do, in which case I know that I
> do, and I could just keyword the thing if I wanted to.

s/month/year/

Do you feel the same way then? I have heard of stabilizations taking
this long before. I just had to try to pick something reasonable for the
discussion.

I suppose a compromise would be, instead of removing the old versions,
move them back to ~arch for a month then remove them, but that still
implies action on your part.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 14 Jan 2014 21:40:24 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> I've written too many emails today, I hereby give up =)

At least you've let your voice be heard against this option. :)

It sets the ground for discussion for people that agree with you.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[grozin]

On Tue, 14 Jan 2014, William Hubbs wrote:
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.
+1

Also, there is a substantial number of packages which contain only python 
code (or perl, ruby), or only LaTeX classes, or only documentation. It 
makes no sense to test them on each arch separately. I think maintainers 
should be allowed to stabilize such packages (with no compiled code) on 
all arches.

Andrey

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Wed, Jan 15, 2014 at 10:48:53AM +0700, grozin@gentoo.org wrote:
> On Tue, 14 Jan 2014, William Hubbs wrote:
> > 1. I think maintainers should be able to stabilize their packages on arch's
> > they have access to. I think this is allowed by some arch teams, but I
> > think it would be good to formalize it.
> +1
> 
> Also, there is a substantial number of packages which contain only python 
> code (or perl, ruby), or only LaTeX classes, or only documentation. It 
> makes no sense to test them on each arch separately. I think maintainers 
> should be allowed to stabilize such packages (with no compiled code) on 
> all arches.

There is a reason we don't do this, back in Gentoo history somewhere, but  I
don't remember what it was.

If someone can tell us why this isn't allowed I am all ears. Otherwise,
I could agree on this point as well.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Robin H. Johnson]

On Tue, Jan 14, 2014 at 10:49:48PM -0600, William Hubbs wrote:
> > Also, there is a substantial number of packages which contain only python 
> > code (or perl, ruby), or only LaTeX classes, or only documentation. It 
> > makes no sense to test them on each arch separately. I think maintainers 
> > should be allowed to stabilize such packages (with no compiled code) on 
> > all arches.
> There is a reason we don't do this, back in Gentoo history somewhere, but  I
> don't remember what it was.
> 
> If someone can tell us why this isn't allowed I am all ears. Otherwise,
> I could agree on this point as well.
I vaguely recall an example of some non-compiled Perl code that wasn't
portable over architectures. 

However I feel that should really be the exception, not the general
case.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Dirkjan Ochtman]

On Wed, Jan 15, 2014 at 5:49 AM, William Hubbs <williamh@gentoo.org> wrote:
>> Also, there is a substantial number of packages which contain only python
>> code (or perl, ruby), or only LaTeX classes, or only documentation. It
>> makes no sense to test them on each arch separately. I think maintainers
>> should be allowed to stabilize such packages (with no compiled code) on
>> all arches.
>
> There is a reason we don't do this, back in Gentoo history somewhere, but  I
> don't remember what it was.
>
> If someone can tell us why this isn't allowed I am all ears. Otherwise,
> I could agree on this point as well.

Yeah, as the python team lead, I feel we could definitely stick some
policy bits in (almost) all python packages that says stable for one
arch means stable for all arches. Sure, there'd be some fallout, but I
suspect that would be very limited, and in return only one arch tester
(or the maintainer!) can stabilize for all architectures.

Cheers,

Dirkjan

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Hans de Graaff]

On Tue, 2014-01-14 at 22:49 -0600, William Hubbs wrote:
> > Also, there is a substantial number of packages which contain only python 
> > code (or perl, ruby), or only LaTeX classes, or only documentation. It 
> > makes no sense to test them on each arch separately. I think maintainers 
> > should be allowed to stabilize such packages (with no compiled code) on 
> > all arches.
> 
> There is a reason we don't do this, back in Gentoo history somewhere, but  I
> don't remember what it was.
> 
> If someone can tell us why this isn't allowed I am all ears. Otherwise,
> I could agree on this point as well.

Speaking for ruby I have seen various arch-related bugs in pure ruby
code. It doesn't happen a lot (maybe 1% of stable requests) but it is
also not predictable.

I also like the second set of eyes verifying what we've done as part of
marking a package stable, so I probably would still file bugs rather
than marking stuff stable myself.

Hans

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michał Górny]

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

Dnia 2014-01-14, o godz. 15:37:19
William Hubbs <williamh@gentoo.org> napisał(a):

> I want comments wrt two ideas:
> 
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.

I think we'd use more feedback from the 'other' arch teams before
agreeing on this. Some arches may have a pretty tricky issues that
could affect stabilization but which average developer may be not aware
of. Maybe it'd be good if each arch team had a wiki page explaining
the testing process for their arch.

We should also make it clear that the developer is supposed to test
the package on a pure stable system to avoid misunderstandings.

> 2. I would like to see the policy below applied to all arch's [2].
>
> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt

Honestly, this sounds like a very bad idea to me. Even on the minor
architectures.

TLDR: users will end up running unsupported mixed-arch systems
and stabilizing the package again sometime wouldn't make much sense.

Dropping the stable keyword on a package means that user either:

1) has to remove the package and either find an alternative or lose
particular features completely. And unlike with regular package.mask,
he won't get any tips from us. In fact, this policy makes it possible
to kill, say, the last graphical word processor on the arch.

2) has to add package.accept_keywords entry for the package. Which
means turning a pure stable system into an unsupported mixed-keyword
system.

Considering portage behavior, I think that 2) is much more likely. Now,
the keyword may be added per-version or per-package. If it's added
per-version, user simply ends up sticking to another single version
until he thinks of upgrading the package manually.

If it's added per-package, the keyword usually persists on the user's
system. When we bring the stable keywords to the package again, user
would have to notice that and remove his override. How likely is that
going to happen?

So, in the end once we remove stable keyword from a package, most users
add ~arch keyword and future stable keyword on the package becomes
meaningless.

I'd rather go for removing stable keywords from all packages. This
would at least make turning the architecture back stable easy for users.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 01:37, William Hubbs пишет:
> I want comments wrt two ideas:
> 
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.
> 
> 2. I would like to see the policy below applied to all arch's [2].
> 
> Thoughts?
> 
> William
> 
> [1] http://bugs.gentoo.org/487332
> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
> 

amd64 and x86 arch teams have agreement, that maintainers can stabilize
their packages if they know how to properly test them.

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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 03:11, William Hubbs пишет:
> The status quo is not good, because we are forced to keep old, and
> potentially buggy, versions of software around longer than necessary.

<arch team member opinion>
But both of suggested solutions will break the whole idea of stabling.
Dropping packages to unstable on regular basis will annoy our users.

If we have old stable package, it builds and works correctly in new
environment(new gcc, glibc etc), then i do not see the point in rushing
things up, unless there are some more critical things, that needs new
version of this package. Stable should be reasonable. Each new version
of package contains bugfixes, it is true. But we should note, that new
versions(even so-called bugfix releases) can also bring new bugs.
</arch team member>


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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 01:37, William Hubbs пишет:
> All,
> 
> It is becoming more and more obvious that we do not have enough manpower
> on the arch teams, even some of the ones we consider major arch's, to
> keep up with stabilization requests. For example, there is this bug [1],
> which is blocking the stabilization of several important packages.

And by the way, the only arches left there are ppc and ppc64, which are
NOT major ones.

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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 06:42, Tom Wijsman пишет:
> And for that occasional mis-guess, *boohoo*, the user can just file a
> bug; which ironically even happens occasionally for stable packages.

If we blindly approves increasing of such mis-guesses, then our QA level
in arch teams will down below the apropriate level IMO. And this is not
good first of all for our stable users.

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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 03:49, Tom Wijsman пишет:
> On Tue, 14 Jan 2014 15:37:19 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> Thoughts?
> 
> In this situation, I see three opposite ends of choices:
> 
>   1. "We do nothing"; which means that as a side effect either less
>   often a version would be picked for stabilization or stabilizations
>   will just take longer due to a longer queue. The question here is
>   whether the queue is actually growing; to get a quick idea, we could
>   compare the amount of bugs we have now compared to those of last time.
> 
>   Advantage:    We keep the same policy and quality of stabilization.
> 
>   Disadvantage: Stable runs further behind. Waiting time. Frustration.
> 
>   Resources:    We need to find more people for the arch teams.
> 
>   2. "We crowd source it"; which means we tackle the 'low manpower'
>   problem itself, we invite at a larger scale feedback for packages in
>   one or another way. This ranges from a simple reminder when merging a
>   non-stable package to report back whether it is working, to a more
>   large scale new website effort where this can be done much more
>   organized; but that's a whole discussion on its own.
> 
>   Advantage:    Power to the community. Need for arch teams decreases.
> 
>   Disadvantage: Stabilization quality could drop. Enough feedback?
> 
>   Resources:    We need to patch up and/or write enough to pull
>                 attention from the user that there aid is needed.
> 
>   3. "We make stable mean less"; which means that we accept the 'low
>   manpower' problem, this would as a consequence thus mean that because
>   we cannot put in enough effort to deem everything stable anymore. The
>   word 'stable' would thus mean less, instead of 'thoroughly tested by
>   a separate person' it becomes 'tested by the same maintainer'.
> 
>   Advantage:    Gentoo becomes slightly more bleeding edge.
> 
>   Disadvantage: Problematic for important packages were stabilization 
>                 is really needed; 'stability' of some user application
>                 has a much smaller meaning than on a library shared
>                 between multiple applications of the user.
> 
>   Resources:    Less resources used, though it might yield more bugs.
> 
> Of course this is not meant to limit other choices, there might be
> others and I hope people bring them forward; as a closing word it feels
> hard to decide here, especially since it can have quite an effect on
> the distribution. As put above neither option seems convincing, neither
> option seems like it is without risk; does anyone have a different view?
> 
> Unless we only do a small version of those options, like changing a
> minor detail instead of pushing it through at once; which could be a
> more safe step forward. Which smaller options do we have here?
> 
> If at all, maybe experiment something on one arch to start with?
> 

As i said earlier for similar proposals - the one option that i see here
to make all things going better - to recruit more people in arch
teams/arch testers. Other options lead us to nowhere, when stable will
be eliminated or transformed into fake.

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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Rich Freeman]

On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> 2) has to add package.accept_keywords entry for the package. Which
> means turning a pure stable system into an unsupported mixed-keyword
> system.

As opposed to an unsupported pure stable system or an unsupported pure
unstable system?  I doubt anybody runs a pure stable system, and if
they do I doubt their experience is much different from those who run
mixed keywords.

Of course, having random system packages drop stable keywords from
time to time isn't going to help anything in that department.

Obviously maintainers should keep stable system packages around as
long as they can.  However, there needs to be some way to deal with
cases where their stabilization gets held up on a major arch.  If we
don't have the manpower to stabilize newer versions, what makes
anybody think that maintainers have the manpower to "support" ancient
versions?

The have our cake and eat it too solution is to obtain more manpower.
That should be done without question, but for whatever reason it never
actually happens, so we need to think about what the alternative is.
If talking about it scares more people into volunteering so that it
isn't necessary all the better...

Given constrained manpower the options basically are some variation on:
1.  Status quo - for some packages stable gets REALLY old, and likely
has problems that maintainers ignore.  You can't force somebody to
maintain something any more than you can force somebody to test
something.

2.  We become more liberal with stabilizing newer versions.  Lots of
variations on this, but the bottom line is that packages get
stabilized that would otherwise not be.

3.  We drop stable keywords on packages.  Lots of variations on this
as well, but the result is mixed-arch systems or dropping stable for
the whole arch.

I don't think #1 is really the answer - it just results in
less-visible problems and a stable that is probably works worse than
either #2 or #3 would yield.

#2 has the advantage that it gives us more control over what gets
installed on stable systems and you don't end up with mixed keywords.
The downside to #2 is that the user doesn't have as much visibility
into which packages are "really" stable.  Maybe an in-between quality
tier would help (if you're going to run a mixed keyword system, at
least use this version).

#3 has the advantage that it makes the problem directly visible to the
user.  However, the solution ends up being entirely user-discretion.
Some users end up on ~arch for life, others do it version-by-version
in which case they end up on various versions.  Personally I run
stable and when I need to run unstable on a package I tend to use
<cat/foo-major+1 syntax so that I'm tracking unstable until the next
major version and then I get a chance to revisit the decision -
usually stable catches up by then.

The only "nice" solution is more manpower.  I'd like a pony to go with
that as well...

Rich

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote:
> 15.01.2014 01:37, William Hubbs пишет:
> > All,
> > 
> > It is becoming more and more obvious that we do not have enough manpower
> > on the arch teams, even some of the ones we consider major arch's, to
> > keep up with stabilization requests. For example, there is this bug [1],
> > which is blocking the stabilization of several important packages.
> 
> And by the way, the only arches left there are ppc and ppc64, which are
> NOT major ones.

Sparc is also still on that bug, and according to the council decision I
sited, these arch's are still treated like major arch's.

Wrt your comment about x86 and amd64 having agreements that maintainers
can stabilize packages on those arch's, I thought amd64 did, but I
didn't know about x86.

Formal policy says that all stabilizations must be done by arch teams
unless you have special arrangements with them [1], so my questions
still stand.

1. Should we make it policy that maintainers can stabilize packages on
arch's they have access to?

2. See Rich's message in this thread for my other concern; he spells it
out pretty well -- what should we do about architectures the maintainer
does not have access to?

3. Also, another interesting question has come up in this thread, that of
non-binary packages. Should we give maintainers the option of
stabilizing them on all arch's themselves?

William

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

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

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Michael Palimaka]

On 01/15/2014 03:49 PM, William Hubbs wrote:
> On Wed, Jan 15, 2014 at 10:48:53AM +0700, grozin@gentoo.org wrote:
>> On Tue, 14 Jan 2014, William Hubbs wrote:
>>> 1. I think maintainers should be able to stabilize their packages on arch's
>>> they have access to. I think this is allowed by some arch teams, but I
>>> think it would be good to formalize it.
>> +1
>>
>> Also, there is a substantial number of packages which contain only python 
>> code (or perl, ruby), or only LaTeX classes, or only documentation. It 
>> makes no sense to test them on each arch separately. I think maintainers 
>> should be allowed to stabilize such packages (with no compiled code) on 
>> all arches.
> 
> There is a reason we don't do this, back in Gentoo history somewhere, but  I
> don't remember what it was.
> 
> If someone can tell us why this isn't allowed I am all ears. Otherwise,
> I could agree on this point as well.
> 
> William
> 
I don't know the exact situation, but the devmanual[1] provides a little
insight: "Do not assume that because your code is written in Perl /
Python / Java / whatever that it will run on other archs (there is at
least one case of a vim script which only worked on x86)."

[1]: http://devmanual.gentoo.org/keywording/#keywording-new-packages

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Wed, 15 Jan 2014 15:33:28 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 15.01.2014 06:42, Tom Wijsman пишет:
> > And for that occasional mis-guess, *boohoo*, the user can just file
> > a bug; which ironically even happens occasionally for stable
> > packages.
> 
> If we blindly approves increasing of such mis-guesses, then our QA
> level in arch teams will down below the apropriate level IMO. And
> this is not good first of all for our stable users.

What I'm saying is that even on arch team stabilized ebuilds bugs
getting filed happens as well; so, it happening for a maintainer
stabilized ebuild wouldn't be so problematic from that perspective.

But, indeed, it depends on which arch team procedure efforts the
maintainer actually applies; on an own arch it is quite possible for
the maintainer to be near the QA level of the arch team, whereas not
having access to a certain architecture can indeed become problematic.

So, for the arches the maintainers do have, it depends on what the
maintainers do as much as what the arch teams do; and to be realistic
arch teams might not always do everything as intended, especially under
time pressure. In my opinion, a maintainer would even spend more time.

As for arches the maintainer does not have, the available machines
might be usable; though the doubt is whether they have enough power.

Most of this discussion is hypothetical assuming stabilization stays
(or continues to grow to be more) problematic; who knows we might get
to see the opposite effect that this thread yields some new arch team
members, which could make what we've discussed here not necessary in the
short term run. It is clear everyone wants to hold on to the arch teams.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Wed, 15 Jan 2014 15:40:20 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> As i said earlier for similar proposals - the one option that i see
> here to make all things going better - to recruit more people in arch
> teams/arch testers. Other options lead us to nowhere, when stable
> will be eliminated or transformed into fake.

If eventually our existing approach yields no or worsening results, it
would leads us nowhere as well; we can pick that option a few times,
but if it doesn't improve anything we'll need to start reconsidering.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Matthew Thode]

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

On 01/15/2014 10:57 AM, Tom Wijsman wrote:
> On Wed, 15 Jan 2014 15:33:28 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> 15.01.2014 06:42, Tom Wijsman пишет:
>>> And for that occasional mis-guess, *boohoo*, the user can just file
>>> a bug; which ironically even happens occasionally for stable
>>> packages.
>>
>> If we blindly approves increasing of such mis-guesses, then our QA
>> level in arch teams will down below the apropriate level IMO. And
>> this is not good first of all for our stable users.
> 
> What I'm saying is that even on arch team stabilized ebuilds bugs
> getting filed happens as well; so, it happening for a maintainer
> stabilized ebuild wouldn't be so problematic from that perspective.
> 
> But, indeed, it depends on which arch team procedure efforts the
> maintainer actually applies; on an own arch it is quite possible for
> the maintainer to be near the QA level of the arch team, whereas not
> having access to a certain architecture can indeed become problematic.
> 
> So, for the arches the maintainers do have, it depends on what the
> maintainers do as much as what the arch teams do; and to be realistic
> arch teams might not always do everything as intended, especially under
> time pressure. In my opinion, a maintainer would even spend more time.
> 
> As for arches the maintainer does not have, the available machines
> might be usable; though the doubt is whether they have enough power.
> 
> Most of this discussion is hypothetical assuming stabilization stays
> (or continues to grow to be more) problematic; who knows we might get
> to see the opposite effect that this thread yields some new arch team
> members, which could make what we've discussed here not necessary in the
> short term run. It is clear everyone wants to hold on to the arch teams.
> 
I would like to see the ability for devs to become arch testers for the
packages they own on the architectures they have access to.  The hard
part is enforcing the arch testing guidelines, so maybe this can be
considered 'arch tester jr.'.

-- 
-- Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Thomas Sachau]

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

William Hubbs schrieb:

> Thoughts?
> 
> William
> 
> [1] http://bugs.gentoo.org/487332
> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
> 

I see 2 cases here:

1. specific or all arch teams allow maintainers to stabilize packages on
their own, when they follow the arch team stabilization rules (e.g.
having a system running with stable keywords for testing the package).
This should not reduce the quality of the stable tree (or only to the
small amount, that some arch testers do additional checks the maintainer
does not do). Reading through this thread, it seems like amd64 and x86
arch teams already use this policy. This sounds like a reasonable
agreement, so i am supporting this too.

2. for arches with no such agreement or where the maintainer does not
have the needed hardware to test, no action for a certain amount of time
usually means, that the arch team is overloaded with work so the only
short- to mid-term solution is to reduce the amount of work resulting in
smaller amount of stable packages. So i am voting for maintainers
dropping stable keywords after a certain amount of time with no actions
(maybe with some notice beforehand). This might result in a mixed arch
user setup by default, but imho it is still better to have a smaller
stable set of core packages and testing packages on top then having
either everything on testing or broken/untested/unsupported packages,
which are still claimed to be the opposite with the stable keyword.

short summary:

-in agreement with arch teams, following stabilization policy and having
the needed hardware, maintainers should be able to add stable keywords
themselves
-if either agreement of arch team or needed hardware is missing,
keywords should be dropped, so that after some time the workload matches
the abilities of the arch team again.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Wed, Jan 15, 2014 at 07:33:45PM +0100, Thomas Sachau wrote:
> William Hubbs schrieb:
> 
> > Thoughts?
> > 
> > William
> > 
> > [1] http://bugs.gentoo.org/487332
> > [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
> > 
> 
> I see 2 cases here:
> 
> 1. specific or all arch teams allow maintainers to stabilize packages on
> their own, when they follow the arch team stabilization rules (e.g.
> having a system running with stable keywords for testing the package).
> This should not reduce the quality of the stable tree (or only to the
> small amount, that some arch testers do additional checks the maintainer
> does not do). Reading through this thread, it seems like amd64 and x86
> arch teams already use this policy. This sounds like a reasonable
> agreement, so i am supporting this too.
> 
> 2. for arches with no such agreement or where the maintainer does not
> have the needed hardware to test, no action for a certain amount of time
> usually means, that the arch team is overloaded with work so the only
> short- to mid-term solution is to reduce the amount of work resulting in
> smaller amount of stable packages. So i am voting for maintainers
> dropping stable keywords after a certain amount of time with no actions
> (maybe with some notice beforehand). This might result in a mixed arch
> user setup by default, but imho it is still better to have a smaller
> stable set of core packages and testing packages on top then having
> either everything on testing or broken/untested/unsupported packages,
> which are still claimed to be the opposite with the stable keyword.
> 
> short summary:
> 
> -in agreement with arch teams, following stabilization policy and having
> the needed hardware, maintainers should be able to add stable keywords
> themselves
> -if either agreement of arch team or needed hardware is missing,
> keywords should be dropped, so that after some time the workload matches
> the abilities of the arch team again.

When you say "drop keywords" do you mean:

1) revert the old version back to ~arch or
2) remove the old version.

As a maintainer, I would rather do 2, because I do not want to backport
fixes to the old version.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Ruud Koolen]

On Tuesday 14 January 2014 22:37:19 William Hubbs wrote:
> I think we need a global policy that either helps keep the stable tree
> up to date or reverts an architecture to ~ over time if the arch team
> can't keep up.

As a compromise solution for minor archs, it would be nice if there were a 
portage feature allowing me to ACCEPT_KEYWORDS those packages that are 
keyworded both ~arch, and stable on some major arch. For example, on m68k, it 
would select packages that are keyworded ~m68k && amd64, or ~m68k && x86, 
etc. This would allow me to run m68k "kinda stable".

[Speculation as to applying a similar system more broadly witheld.]

-- Ruud

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Rich Freeman posted on Wed, 15 Jan 2014 07:51:49 -0500 as excerpted:

> Given constrained manpower the options basically are some variation on:

> 1. Status quo - for some packages stable gets REALLY old, and likely has
> problems that maintainers ignore.  You can't force somebody to maintain
> something any more than you can force somebody to test something.
> 
> 2. We become more liberal with stabilizing newer versions.  Lots of
> variations on this, but the bottom line is that packages get stabilized
> that would otherwise not be.
> 
> 3. We drop stable keywords on packages.  Lots of variations on this as
> well, but the result is mixed-arch systems or dropping stable for the
> whole arch.
> 
> I don't think #1 is really the answer - it just results in less-visible
> problems and a stable that is probably works worse than either #2 or #3
> would yield.
> 
> #2 has the advantage that it gives us more control over what gets
> installed on stable systems and you don't end up with mixed keywords.
> The downside to #2 is that the user doesn't have as much visibility into
> which packages are "really" stable.  Maybe an in-between quality tier
> would help (if you're going to run a mixed keyword system, at least use
> this version).

What about a third "target-stable" keyword?  Either arch-teams or package-
maintainers (with maintainers getting priority in case of differing 
viewpoints, just as arch-teams already have priority over full-stable) 
could set this, and it would let users who wanted to be "almost stable 
but hasn't gotten thru all the hoops just yet" arch-testers do just that, 
see and test almost-stable packages.

An open stabilization bug would be required for any target-stable 
package, and only one target-stable per-slot per-arch would be allowed -- 
if there's already a target-stable in that slot for that arch, it would 
need to be removed and either that package fully stabilized or the new 
one substituted in the target-stable slot.

* Note however that different archs could however have different target-
stable packages within a slot.  This would allow a maintainer to set a 
minimal version target-stable keyword for lagging archs, while setting a 
preferred version target-stable keyword for current archs.

A maintainer facing lagging archs could then set target-stable 
appropriately, and could re-assign any bugs on the old-stable version to 
the arch in question, with comment boilerplate to the effect that the 
arch is lagging and hasn't updated stable, so they get to deal with bugs 
for their ancient-stable version.

A variant on the theme would be to split the current stable keyword in 
half, arch-stable and maintainer stable.  Any package version keyworded 
for both would be considered fully stable, but the two halves would then 
be fully independent, no longer interlocked, and for half-stable packages 
bugs would be assigned to the stable side with the other side CCed.  In 
this variant, there'd be no limit on the number of package versions that 
could be half-stabled by either half, just as there can now be multiple 
stable-keyworded versions, and for that matter, multiple testing versions 
as well.

> #3 has the advantage that it makes the problem directly visible to the
> user.  However, the solution ends up being entirely user-discretion.

Either target-stable keyword variant above would be directly visible to 
the end user as well, and of course they could choose full-stable or half-
stable on either side as they wished.

> Some users end up on ~arch for life, others do it version-by-version in
> which case they end up on various versions.  Personally I run stable and
> when I need to run unstable on a package I tend to use <cat/foo-major+1
> syntax so that I'm tracking unstable until the next major version and
> then I get a chance to revisit the decision - usually stable catches
> up by then.

Interesting.  Nominally I do ~arch as for me stab?le== , but I do more or 
less the same thing at the overlay-~arch/unkeyworded/masked/live-9999 
level.

For my kde packages, for example, I run the overlay and normally 
package.keyword/package.unmask 4.y.9999 as soon as it's available in the 
kde overlay (I have scripts that do git log --color --stat --graph 
$branch ORIG_HEAD..  on the overlays, and routinely run them after 
syncing so I know what's going on).  But since upstream kde doesn't split 
a branch until the rcs and thus those branches and the kde overlay 
packages based on them don't appear for the betas, I have to switch to 
-9999 during the kde betas, and "downgrade" back to 4.y.9999 when 
upstream branches and the 4.y.9999 ebuilds appear.  I suppose one of 
these days I'll setup kde-frameworks and be doing about the same for it, 
too...

What's nice is that for kde 4.12.9999 for example, when gentoo/kde was 
still sorting out the masking/dependencies issues in the overlay due to 
plasma/workspace being locked to 4.11.x, I was able to grab the 4.11.9999 
unmask files from the overlay, do a global search and replace 4.12.9999 
in place of 4.11.9999 but keeping the 4.11.9999 for workspace packages, 
set a few KDE_OVERRIDE_MINIMAL=4.11 via package.env, and go to town with 
4.12.9999 before gentoo/kde had finished sorting out the masking and 
dependency issues themselves. =:^)

Of course for kde there's the -4.x.9999 versions to use.  For openrc, 
etc, there's not.  There it's -9999 or ~arch, and for openrc in 
particular I use -9999 because the ~arch ebuild changelogs simply aren't 
detailed enough and it's too difficult to track down the bugs when they 
inevitably appear.  Git log and if the commit log is interesting enough, 
git show <id>, is far *FAR* better! =:^)

Unfortunately, while it might have been useful for devs, git-r3 has sure 
been a headache for users trying to follow upstream development with git 
log ORIG_HEAD.. There's workarounds, but they're a lot more hassle with 
git-r3 than git2 was.  =:^(

-- 
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: rfc: revisiting our stabilization policy

[Martin Vaeth]

Ruud Koolen <redlizard@gentoo.org> wrote:
>
> As a compromise solution for minor archs, it would be nice if there were a
> portage feature allowing me to ACCEPT_KEYWORDS those packages that are
> keyworded both ~arch, and stable on some major arch. For example, on m68k, it
> would select packages that are keyworded ~m68k && amd64, or ~m68k && x86,
> etc. This would allow me to run m68k "kinda stable".

http://bugs.gentoo.org/show_bug.cgi?id=208316

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Michael Orlitzky posted on Tue, 14 Jan 2014 19:50:30 -0500 as excerpted:

> As I mentioned in a reply to William, right now I can decide when stuff
> is broken and keyword the newer versions. The proposal is to force me
> onto the new versions, which is strictly worse from my perspective.

Force??

As I discovered when gentoo/kde "forced" me into taking semantic-desktop 
up the <beep> with early kde 4.11, there's rather less "force" on gentoo 
than many realize, certainly as long as upstream is still supporting the 
options, anyway, one of the reasons I run gentoo.[1] =:^)

Every once in awhile I drag an ebuild out of /var/db/pkg/ to put in my 
overlay, because the ~arch I normally run has moved on and my current 
version is gone, but the new version is broken (or simply hugely changed 
and I don't have time to reconfigure ATM), while the stab?le version is 
just that, stale.

Of course the kde-sunset overlay is perhaps the ultimate example of that.

Yes, ultimately there will eventually be some "forcing" as in-tree deps 
change and keeping the old/overlaid version building and running becomes 
more of an issue over time, but it'll be a gradual process over a number 
of years, and the gentooer remains free to pick his pain point and do the 
migration in his own time, which at minimum, makes it a substantially 
softer "force" than would be the case on /most/ distributions.

---
[1] In the kde/semantic-desktop case, I diffed package versions with and 
without the flag and figured out which changes were related to it and 
which not, creating my own ebuild patches, which I dropped in a tree 
under /etc/portage/patches.ebuild/, similar to the /etc/portage/patches/ 
tree.  I then hacked up a script to apply those ebuild patches and re-
manifest, and added that step to my sync-script.  This was all possible, 
and actually surprisingly easy, because (1) upstream kde still supports 
the configure options and AFAIK intends to thru all of kde4, and (2) 
gentoo/kde had the options available at one point, so all I had to do was 
diff the before and after, and reverse the effect, hard-coding the flag 
off, where gentoo/kde was was effectively hard-coding it on.

Fortunately, before 4.11 went stable, gentoo/kde decided to keep the 
flags after all, and reintroduced them.  So I didn't have to carry my own 
patches for as long as I had feared I might.  But regardless, their 
"forcing" semantic-desktop on ~arch and overlay users didn't "force" /me/ 
to take it, because I'm an empowered gentooer and one way or another I 
wasn't taking any such "forcing"!  There efforts underway to do a user-
controlled kde-sunset overlay thing, possibly calling it kde-lite, too, 
thus spreading the work around a bit, but fortunately that ultimately 
wasn't needed.  And if it had come to it, I was beginning to look at 
other desktops too, as I had tried it previously and was done with kde 
with semantic-desktop, period, but fortunately that migration didn't have 
to happen either. =:^)

-- 
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: rfc: revisiting our stabilization policy

[Duncan]

Tom Wijsman posted on Wed, 15 Jan 2014 01:28:09 +0100 as excerpted:

>> Another option (and I don't mean to step on any toes or call anyone out
>> here, these are just examples) may be to just deprecate stabilizing
>> certain software. Packages such as the stuff in app-vim/ or app-emacs/
>> or some games or some scientific software. For the editor plugins, most
>> people do not get them from the package manager I feel and a Vim plugin
>> requires almost as much arch testing work as a new version of grep, for
>> example...
> 
> Sounds like a good idea, but how do we translate that to the user;
> always mark them stable, or always mark them unstable? Do we want users
> to explicitly accept keywords on these packages?

As a ~arch/masked/overlay/live user here (who additionally doesn't even 
use gentoo kernel ebuilds, preferring direct upstream git and my own 
scripts), I haven't even checked if it actually happened (looks like 
gentoo-sources-3.10.x is still stable on x86/amd64, so maybe not), but...

There was previous discussion of destable-keywording the kernel.  How has 
that gone?

I've always thought that having a stable policy exception that the user 
actually has to deal with for certain packages, particularly core 
packages such as the kernel, would be confusing at best.  Still, given 
the upstream development pattern, I couldn't think of a reasonable 
alternative for the kernel, and agreed with the thread that it may have 
to be, for packages like that and perhaps google-chrome and firefox, 
where upstream releases are too close to 30-day and updates are very 
likely to be security-critical on packages that are net-exposed.

So it seemed it had to be, for them, and if that has gone well, perhaps 
expanding that no-stable policy precedent to things like editor plugins 
could work better than I might have imagined.

The other question then becomes, since ~arch packages are normally masked 
to stable, how are users exposed to them?  What about a file somewhere in 
profiles that lists all these no-stable packages, such that the PM can 
(perhaps optionally, I could imagine a setting in make.conf...) list all 
~arch versions of those packages on an otherwise stable system as if they 
were stable, tho possibly marked in some way to indicate that this 
package isn't a stable-keyword candidate?

-- 
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: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Wed, 15 Jan 2014 23:59:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> There was previous discussion of destable-keywording the kernel.  How
> has that gone?

That was for vanilla-sources only, because that has restricted to only
the latest upstream version; as that makes the version change almost
weekly, the package can't undergo our stabilization procedure.
 
> I've always thought that having a stable policy exception that the
> user actually has to deal with for certain packages, particularly
> core packages such as the kernel, would be confusing at best.

Yes, if this would ever happen to gentoo-sources; I'd think the
handbook would then need to be updated to mention the necessary extra
step, but I think it is not bound to happen any time soon.

> Still,
> given the upstream development pattern, I couldn't think of a
> reasonable alternative for the kernel, and agreed with the thread
> that it may have to be, for packages like that and perhaps
> google-chrome and firefox, where upstream releases are too close to
> 30-day and updates are very likely to be security-critical on
> packages that are net-exposed.

What we do now appears to work fine, critical security bugs cause fast
track stabilization if needed; I've backported some security fixes in
the past for less critical CVEs in the past, but the main problem here
for keeping this up is the lack of manpower on the kernel team.

> So it seemed it had to be, for them, and if that has gone well,
> perhaps expanding that no-stable policy precedent to things like
> editor plugins could work better than I might have imagined.

I think it needs to put the accept keywords in a more prominent place
if we're going to do this at a wider scale; currently it's in one of
those sections that people often don't read due to focusing on
continuing with there install instead, eg. they move to some DE guide.

> The other question then becomes, since ~arch packages are normally
> masked to stable, how are users exposed to them?

They aren't unless they accept keywords for them; which can either be
done globally using package.accept_keywords, or locally
by listing the package atom in /etc/portage/package.accept_keywords

> What about a file
> somewhere in profiles that lists all these no-stable packages, such
> that the PM can (perhaps optionally, I could imagine a setting in
> make.conf...) list all ~arch versions of those packages on an
> otherwise stable system as if they were stable, tho possibly marked
> in some way to indicate that this package isn't a stable-keyword
> candidate?

If we drop stable versions on a wider scale, we could indeed make the
~arch versions more visible where they currently aren't; we don't want
to give the impression that we are removing everything.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Wed, 2014-01-15 at 13:07 -0600, William Hubbs wrote:
> When you say "drop keywords" do you mean:
> 
> 1) revert the old version back to ~arch or
> 2) remove the old version.
> 
> As a maintainer, I would rather do 2, because I do not want to backport
> fixes to the old version.
> 
> William
> 

I'm not sure what he meant by drop keywords either, however, something
that I would like to see (with my ARM hat on here) - is, if something is
taking a while to stable for a certain arch, remove the keywords except
for that existing arch.  

We actually ran into something along this issue with git.

Now, arm is an interesting keyword, because for arm, when something
needs to be stabled, we have to test armv4, armv5, armv6, armv6
hardfloat, armv7, armv7 hardfloat, armv7 uclibc.

In my testing, one known issue was that git on uclibc did (and still
doesn't) work properly starting with git 1.8 - so I noted in the bug
that this was the case, and to NOT stable it for arm.  Unfortunately,
someone else on the ARM team disregarded the note and stabled the new
git, then the git maintainers dropped the old versions.  Now on arm
uclibc, git is entirely broken and unusable.

And no, adding more people to the arch team doesn't particularly help,
as people are buying more and more armv7 so they test that, but not the
rest of the versions - and no one wants to buy the older hardware
"because it's so slow" - we know it's slow, that's why it takes time.

I'd have definitely preferred that for git, that the 1.7 version stuck
around with just KEYWORDS="-* arm" (and maybe even stabling 1.8 but
leaving 1.7 in masked?) - I realize it was a bit of a special case
because of the new git eclass.  Unfortunately, debugging what's going
on, is a bit above me, and the only other person I know who can/does
work on it, is blueness, and he's quite busy.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Robin H. Johnson]

On Wed, Jan 15, 2014 at 06:58:27PM -0600, Steev Klimaszewski wrote:
> We actually ran into something along this issue with git.
> 
> Now, arm is an interesting keyword, because for arm, when something
> needs to be stabled, we have to test armv4, armv5, armv6, armv6
> hardfloat, armv7, armv7 hardfloat, armv7 uclibc.
> 
> In my testing, one known issue was that git on uclibc did (and still
> doesn't) work properly starting with git 1.8 - so I noted in the bug
> that this was the case, and to NOT stable it for arm.  Unfortunately,
> someone else on the ARM team disregarded the note and stabled the new
> git, then the git maintainers dropped the old versions.  Now on arm
> uclibc, git is entirely broken and unusable.
Ugh, this does suck.

Wasn't there a proposal years ago to include the libc in the keyword?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Thu, 2014-01-16 at 02:32 +0000, Robin H. Johnson wrote:
> > In my testing, one known issue was that git on uclibc did (and still
> > doesn't) work properly starting with git 1.8 - so I noted in the bug
> > that this was the case, and to NOT stable it for arm.  Unfortunately,
> > someone else on the ARM team disregarded the note and stabled the new
> > git, then the git maintainers dropped the old versions.  Now on arm
> > uclibc, git is entirely broken and unusable.
> Ugh, this does suck.
> 

It does, though it's specific to arm uclibc, as it works fine on
amd64/x86 uclibc.  And unfortunately, it seems like this type of thing
is what people are proposing we move towards.  Instead of working but
old, not having access to the software at all.  I know it's not the
norm, nor is it typical, but the chance of this happening does exist,
and I can't see how anyone would say, well, that's just the chance that
people should take, unless they've never been bitten by a bug like this.


> Wasn't there a proposal years ago to include the libc in the keyword?
> 

There may have been, I'm not sure that's really the right step either
though.  

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 19:30, William Hubbs пишет:
> On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote:
>> 15.01.2014 01:37, William Hubbs пишет:
>>> All,
>>>
>>> It is becoming more and more obvious that we do not have enough manpower
>>> on the arch teams, even some of the ones we consider major arch's, to
>>> keep up with stabilization requests. For example, there is this bug [1],
>>> which is blocking the stabilization of several important packages.
>>
>> And by the way, the only arches left there are ppc and ppc64, which are
>> NOT major ones.
> 
> Sparc is also still on that bug, and according to the council decision I
> sited, these arch's are still treated like major arch's.

Well, to be honest, personally i consider only amd64 and x86(and maybe
arm) as major arches, other are minor in my eyes. Council decision is
more about arches, that crucially lacks manpower.

> Wrt your comment about x86 and amd64 having agreements that maintainers
> can stabilize packages on those arch's, I thought amd64 did, but I
> didn't know about x86.

It's not mentioned, yeah, i was not aware about it for some time.
Probably it should be mentioned in Gentoo Development Guide.

> Formal policy says that all stabilizations must be done by arch teams
> unless you have special arrangements with them [1], so my questions
> still stand.
> 
> 1. Should we make it policy that maintainers can stabilize packages on
> arch's they have access to?
> 
> 2. See Rich's message in this thread for my other concern; he spells it
> out pretty well -- what should we do about architectures the maintainer
> does not have access to?
> 
> 3. Also, another interesting question has come up in this thread, that of
> non-binary packages. Should we give maintainers the option of
> stabilizing them on all arch's themselves?

1. If you know how to test it properly, know arch-specific
problems(aligning, endianness, ABI breakage) and how to fix it - then,
probably yes. But usually maintainers are bored to do proper testing.
2. I think - no. You can not test it - you can not stabilize it, period.
3. If code is interpreted rather then compiled, it does not matter that
it is properly ported on minor arches. I knew dozens of examples with
Perl and Python packages(not sure about Ruby, but Hans said that it
happens with it too). So, i would not treat such packages differently.


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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 21:04, Tom Wijsman пишет:
> On Wed, 15 Jan 2014 15:40:20 +0400
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> As i said earlier for similar proposals - the one option that i see
>> here to make all things going better - to recruit more people in arch
>> teams/arch testers. Other options lead us to nowhere, when stable
>> will be eliminated or transformed into fake.
> 
> If eventually our existing approach yields no or worsening results, it
> would leads us nowhere as well; we can pick that option a few times,
> but if it doesn't improve anything we'll need to start reconsidering.
> 

It can not go to no result, unless we have no breakages in stable,
stable REMAINS stable. If it contains old, but working software - then
it is stable.

As i said earlier, problem begins when we NEED to stabilize something to
prevent breakages and arch teams are slow.

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


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov]

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

15.01.2014 22:33, Thomas Sachau пишет:
> William Hubbs schrieb:
> 
>> Thoughts?
>>
>> William
>>
>> [1] http://bugs.gentoo.org/487332
>> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
>>
> 
> I see 2 cases here:
> 
> 1. specific or all arch teams allow maintainers to stabilize packages on
> their own, when they follow the arch team stabilization rules (e.g.
> having a system running with stable keywords for testing the package).
> This should not reduce the quality of the stable tree (or only to the
> small amount, that some arch testers do additional checks the maintainer
> does not do). Reading through this thread, it seems like amd64 and x86
> arch teams already use this policy. This sounds like a reasonable
> agreement, so i am supporting this too.
> 
> 2. for arches with no such agreement or where the maintainer does not
> have the needed hardware to test, no action for a certain amount of time
> usually means, that the arch team is overloaded with work so the only
> short- to mid-term solution is to reduce the amount of work resulting in
> smaller amount of stable packages. So i am voting for maintainers
> dropping stable keywords after a certain amount of time with no actions
> (maybe with some notice beforehand). This might result in a mixed arch
> user setup by default, but imho it is still better to have a smaller
> stable set of core packages and testing packages on top then having
> either everything on testing or broken/untested/unsupported packages,
> which are still claimed to be the opposite with the stable keyword.
> 
> short summary:
> 
> -in agreement with arch teams, following stabilization policy and having
> the needed hardware, maintainers should be able to add stable keywords
> themselves
> -if either agreement of arch team or needed hardware is missing,
> keywords should be dropped, so that after some time the workload matches
> the abilities of the arch team again.
> 

Thanks, for the proposal. IIRC, there was similar backroom agreement in
some minor arches, look at how armin76 stabilized packages earlier -
sometimes he drops vast amount of keywords on ia64/sparc/m68k to
unstable in stabilization requests.

And i think we should continue this practice.

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


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

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Michael Palimaka]

On 01/16/2014 05:27 PM, Sergey Popov wrote:
> 
> Thanks, for the proposal. IIRC, there was similar backroom agreement in
> some minor arches, look at how armin76 stabilized packages earlier -
> sometimes he drops vast amount of keywords on ia64/sparc/m68k to
> unstable in stabilization requests.
> 
> And i think we should continue this practice.
> 
I agree completely. The keywords on many packages are historical and do
not necessarily represent the current reality. Is it really a good use
of our resources to maintain stable keywords for some small auxiliary
package?
I think every stable request is a good opportunity for each minor arch
team to review their keywords for that package.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Christopher Head]

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

On Tue, 14 Jan 2014 20:46:04 -0600
William Hubbs <williamh@gentoo.org> wrote:

> s/month/year/
> 
> Do you feel the same way then? I have heard of stabilizations taking
> this long before. I just had to try to pick something reasonable for
> the discussion.
> 
> I suppose a compromise would be, instead of removing the old versions,
> move them back to ~arch for a month then remove them, but that still
> implies action on your part.
> 
> William

If I need or want a feature or bugfix which isn’t in the newer version,
I always have the choice to use ~. If I don’t, why do I care if the
package is a year old? I lose none of my time to use the old version,
since it does all I want; I lose a nonzero amount of time if I get a
version which breaks things (even if the only time I lose is the time
it takes to downgrade), so it’s in my best interest to use the stable
versions of such packages, even if they’re a month, a year, or three
years old.
-- 
Christopher Head

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Peter Stuge]

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

Sergey Popov wrote:
> As i said earlier, problem begins when we NEED to stabilize
> something to prevent breakages and arch teams are slow.

Isn't that simply a matter of assigning and respecting priority on
bugs properly?


//Peter

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Rich Freeman]

On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge <peter@stuge.se> wrote:
> Sergey Popov wrote:
>> As i said earlier, problem begins when we NEED to stabilize
>> something to prevent breakages and arch teams are slow.
>
> Isn't that simply a matter of assigning and respecting priority on
> bugs properly?

Are you suggesting that we should forbid people from working on
lower-priority bugs anytime a higher-priority bug exists?  That would
probably just reduce the amount of contribution.  You can't force
anybody to work on the higher-priority ones.

Sure, in an ideal world people work on the high-priority stuff.
However, often somebody either prefers to work on a lower-priority
bug, or finds it easier to do so.  Simply marking a bug as
high-priority doesn't make the bug get resolved.

Bottom line is that people work on what they work on.  Unless you can
find people to work on the stuff that you want done you need to make
work go away.

Rich

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Alan McKinnon]

On 16/01/2014 19:56, Rich Freeman wrote:
> On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge <peter@stuge.se> wrote:
>> Sergey Popov wrote:
>>> As i said earlier, problem begins when we NEED to stabilize
>>> something to prevent breakages and arch teams are slow.
>>
>> Isn't that simply a matter of assigning and respecting priority on
>> bugs properly?
> 
> Are you suggesting that we should forbid people from working on
> lower-priority bugs anytime a higher-priority bug exists?  That would
> probably just reduce the amount of contribution.  You can't force
> anybody to work on the higher-priority ones.
> 
> Sure, in an ideal world people work on the high-priority stuff.
> However, often somebody either prefers to work on a lower-priority
> bug, or finds it easier to do so.  Simply marking a bug as
> high-priority doesn't make the bug get resolved.
> 
> Bottom line is that people work on what they work on.  Unless you can
> find people to work on the stuff that you want done you need to make
> work go away.

+1

"Respecting bug priority" feels like that corporate BS I have to put up
with every day. Like every sysadmin team world-wide, we're understaffed
so the only bugs that get any attention at all are ones where some fool
of a manager thinks he can shout louder than anyone else.

Gentoo is not like that. As you say, devs will work on what they feel
like working on, heavily influenced by their own sense of
responsibility. We have nothing to offer maintainers except
fuzzy-feel-good and recognition; we have to trust them to do the right
thing.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Peter Stuge]

Rich Freeman wrote:
> >> As i said earlier, problem begins when we NEED to stabilize
> >> something to prevent breakages and arch teams are slow.
> >
> > Isn't that simply a matter of assigning and respecting priority on
> > bugs properly?
> 
> Are you suggesting that we should forbid people from working on
> lower-priority bugs anytime a higher-priority bug exists?

No, of course not forbid.

I admit it's naïve but I can't believe that it would be neccessary.
I expect anyone with the slightest sense of responsibility to solve
problems in order of priority.

Individuals may have different priorities than Gentoo as a whole and
that is and must be fine, but in that case Gentoo's high priority
problems stay unsolved, and I do not at all think that it's
catastrophical to have unfixed high priority problems.


> You can't force anybody to work on the higher-priority ones.

Yes, you can't force anybody to do anything unless you motivate them,
usually with money. The state of Gentoo always did and always will
equal the sum of contributors' work.


> Bottom line is that people work on what they work on.  Unless you can
> find people to work on the stuff that you want done you need to make
> work go away.

I certainly don't think the work needs to go away if the work is
considered to be important. It's fine to have open bugs for years
in the absence of a good solution.

Things happen when they happen. If someone cares then they fix and
ideally it is so easy for them to contribute the fix that they will.

If noone cares then bugs stay unfixed and then the bugs don't matter. ;)


//Peter

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Peter Stuge]

Alan McKinnon wrote:
> "Respecting bug priority" feels like that corporate BS I have to put up
> with every day.

Gentoo is incorporated so maybe that fits. ;)

On a more serious note, please try to understand what I meant rather
than just what I wrote.

I wrote both "assigning" and "respecting"; your gripe with "corporate BS"
may be a result of how priority was assigned to your bugs, and likely
amplified if you can't do much to influence that process. If you only
get a priority shoved down your throat you of course can't really
respect it.

For priority to have any meaning on bugs.g.o there would need to be
some buy-in among developers to actually want to work together to
assign the proper priority to each bug.

Bug trackers aren't management command and control tools, they are
hive minds which just remember what workers agree on anyway.


> the only bugs that get any attention at all are ones where some
> fool of a manager thinks he can shout louder than anyone else.

> We have nothing to offer maintainers except fuzzy-feel-good and
> recognition; we have to trust them to do the right thing.

Nobody will do the right thing if they don't know what it is.

Recognition can certainly communicate that higher priority bugs are
more important, but honestly, I wouldn't want someone who needs to
be told that explicitly on my (the Gentoo) team in the first place..

Disclaimer for anyone who might find this upsetting: Of course people
always have limited scope, and it is perfectly fine if high priority
bugs can simply not be fixed by whoever has time to work on bugs at
any given moment.

IMO, closing bugs without having the right fix has negative value.

I know that it can be depressing and demotivating to have too many
bugs, just like it is to live in a too messy room, but I really do
think that the best solution is simply to pick one thing up at a
time. It may take a long time, but in the end the room is clean. :)


//Peter

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Rich Freeman]

On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge <peter@stuge.se> wrote:
> I certainly don't think the work needs to go away if the work is
> considered to be important. It's fine to have open bugs for years
> in the absence of a good solution.

I get what you're saying, though there is still a cost to leaving the
bug open to years.  In this case it means an old package stays in the
tree marked as stable.  That either costs maintainers the effort to
keep it work, or they don't bother to keep in working in which case
users get saddled with issues.

I am completely in support of making use of the priority field - if
something is causing issues by all means call attention to it. I bet
it would /help/ with the problem, but it won't make it go away.

Rich

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Thu, Jan 16, 2014 at 01:42:41PM -0500, Rich Freeman wrote:
> On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge <peter@stuge.se> wrote:
> > I certainly don't think the work needs to go away if the work is
> > considered to be important. It's fine to have open bugs for years
> > in the absence of a good solution.
> 
> I get what you're saying, though there is still a cost to leaving the
> bug open to years.  In this case it means an old package stays in the
> tree marked as stable.  That either costs maintainers the effort to
> keep it work, or they don't bother to keep in working in which case
> users get saddled with issues.

Correct.

> I am completely in support of making use of the priority field - if
> something is causing issues by all means call attention to it. I bet
> it would /help/ with the problem, but it won't make it go away.

It might help, but, no, it will not make the problem go away.
The issue is that the arch team and maintainer may have different
ideas of what is high priority. If a maintainer opens a high priority
stable request or bumps a stable request to high priority, there is no
guarantee that the arch team will feel it should be prioritized the same
way, and when that happens, users are stuck with issues from the old
versions of the software.

William


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Peter Stuge]

Rich Freeman wrote:
> I get what you're saying, though there is still a cost to leaving the
> bug open to years.  In this case it means an old package stays in the
> tree marked as stable.  That either costs maintainers the effort to
> keep it work, or they don't bother to keep in working in which case
> users get saddled with issues.

Since it's not possible to force anyone to keep old packages working
when the rest of a system has been upgraded this is hard to solve.

If reality is that a package is in the tree but there is no stable
version which works in an otherwise updated system then I think it's
accurate to have an open bug.

If nobody makes the package work then there seem to be two options;
either leave the bug open until someone makes things work again,
or to remove the package from portage and close the bug as WONTFIX.

But even if a given package is removed from portage the old stable
version is still installed on the user's system.


//Peter

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Alan McKinnon]

On 16/01/2014 20:26, Peter Stuge wrote:
> Alan McKinnon wrote:
>> "Respecting bug priority" feels like that corporate BS I have to put up
>> with every day.
> 
> Gentoo is incorporated so maybe that fits. ;)
> 
> On a more serious note, please try to understand what I meant rather
> than just what I wrote.
> 
> I wrote both "assigning" and "respecting"; your gripe with "corporate BS"
> may be a result of how priority was assigned to your bugs, and likely
> amplified if you can't do much to influence that process. If you only
> get a priority shoved down your throat you of course can't really
> respect it.
> 
> For priority to have any meaning on bugs.g.o there would need to be
> some buy-in among developers to actually want to work together to
> assign the proper priority to each bug.
> 
> Bug trackers aren't management command and control tools, they are
> hive minds which just remember what workers agree on anyway.
> 
> 
>> the only bugs that get any attention at all are ones where some
>> fool of a manager thinks he can shout louder than anyone else.
> 
>> We have nothing to offer maintainers except fuzzy-feel-good and
>> recognition; we have to trust them to do the right thing.
> 
> Nobody will do the right thing if they don't know what it is.
> 
> Recognition can certainly communicate that higher priority bugs are
> more important, but honestly, I wouldn't want someone who needs to
> be told that explicitly on my (the Gentoo) team in the first place..
> 
> Disclaimer for anyone who might find this upsetting: Of course people
> always have limited scope, and it is perfectly fine if high priority
> bugs can simply not be fixed by whoever has time to work on bugs at
> any given moment.
> 
> IMO, closing bugs without having the right fix has negative value.
> 
> I know that it can be depressing and demotivating to have too many
> bugs, just like it is to live in a too messy room, but I really do
> think that the best solution is simply to pick one thing up at a
> time. It may take a long time, but in the end the room is clean. :)


When relying on folk's goodwill (like in the open source world), I find
there are really only two priorities

1. the bug breaks stuff
2. everything else

with possibly a #3 - stuff that doesn't matter, can be done whenever.

Gentoo devs have shown time and again that they do take #1 seriously.
After all, they are themselves Gentoo users. The team that is dealing
with the bug may of course assign priority as they see fit as long as
they mostly agree on what it is.

I reckon the cardinal rule is "avoid as much as possible having priority
set by someone who is not solving the problem". I think that comes close
in my words to what you are saying.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Peter Stuge]

Alan McKinnon wrote:
> > I wrote both "assigning" and "respecting"
> 
> I reckon the cardinal rule is "avoid as much as possible having priority
> set by someone who is not solving the problem". I think that comes close
> in my words to what you are saying.

Yes that's exactly what I mean. Thanks for expressing it well. :)


//Peter

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Wed, 15 Jan 2014 23:28:04 -0800
Christopher Head <chead@chead.ca> wrote:

> If I need or want a feature or bugfix which isn’t in the newer
> version, I always have the choice to use ~.

Yes.

> If I don’t, why do I care if the package is a year old? I lose none
> of my time to use the old version, since it does all I want;

This is under the assumption that the old version has no further
implications, which is a false assumption; because the older a stable
ebuild get, the higher the chance is that it becomes incompatible with
its libraries and/or causes blockers. Even further, a security bug for
an old version of a library it depends on could cause its removal.

Regardless, it'll work fine for some time; and you can even pull it
further by attempting to keep things around and not upgrade, but at a
certain point it'll come costly to hold on to. I'm not saying it is a
lot of your time, but it's a bit more than none of your time.

This point becomes much more clear if you imagine using software from in
the early Linux years, most of them would be incompatible with today.

> I lose a
> nonzero amount of time if I get a version which breaks things (even
> if the only time I lose is the time it takes to downgrade),

Depends on whether the stable version is as perfect as one thinks it
is; an upgrade can go two ways, it improves or regresses. (Well, three
ways as it can stay the same, but that wouldn't demonstrate the point)

> so it’s in my best interest to use the stable versions of such
> packages, even if they’re a month, a year, or three years old.

Based on what you know, what you need and that you can resist change;
yes, but this doesn't take into account what you don't know, you don't
know you need and the improvements that change can bring.

While it doesn't happen often, some people will say "if I knew this
earlier, I would have already upgraded a long while ago"; either
because the new version brings something good, or the old version has a
regression they were not aware of yet or came due to incompatibility...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 16 Jan 2014 10:20:37 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> It can not go to no result, unless we have no breakages in stable,
> stable REMAINS stable. If it contains old, but working software - then
> it is stable.

An ebuild promoted to stable is because an arch team (or a privileged
maintainer to do it individually) has put a keyword in place. The
person that puts that keyword in place, defines that the ebuild is
stable at that specific point in time.

However; this does not imply that as the ebuild gets older, that this
doesn't come without problems; neither does it imply that the software
is totally working. Software is rarely completely without bugs.

> As i said earlier, problem begins when we NEED to stabilize something
> to prevent breakages and arch teams are slow.

Yes; there is a big correlation between breakages in old versions and
stabilization, in both ways.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[grozin]

On Thu, 16 Jan 2014, Sergey Popov wrote:
>> 3. Also, another interesting question has come up in this thread, that of
>> non-binary packages. Should we give maintainers the option of
>> stabilizing them on all arch's themselves?
> 3. If code is interpreted rather then compiled, it does not matter that
> it is properly ported on minor arches. I knew dozens of examples with
> Perl and Python packages(not sure about Ruby, but Hans said that it
> happens with it too). So, i would not treat such packages differently.
OK, let's be conservative. Python and Perl scripts may break on some 
arches (I'd say it's a rare exception, perhaps 1%, but still). But what 
about

dev-java/java-sdk-docs
dev-db/postgresql-docs
sys-kernel/linux-docs
dev-dotnet/gtk-sharp-docs
app-xemacs/general-docs
dev-util/kdevelop-php-docs
dev-util/gnome-devel-docs
app-vim/phpdocs
gnome-extra/gnome-user-docs
gnome-extra/gnome-getting-started-docs
dev-php/smarty-docs
dev-python/python-docs
dev-python/cheetah-docs
app-doc/php-docs
app-doc/root-docs
app-doc/geant-docs
app-doc/blas-docs
app-doc/lapack-docs
app-doc/gnucash-docs
app-office/abiword-docs
dev-lisp/hyperspec
sys-apps/man-pages[-*]

and maybe others? They contain no scripts which can possibly break. I'd 
say they should be keyworded on all arches as soon as they are keyworded 
on the first arch; the same goes for stabilization. I'd include also 
packages containing only TeX/LaTeX code - TeX behaves identically on all 
arches, this was and is its main strength. Also, probably, 
python/perl/ruby interpreted scripts *which don't load extra libraries* 
work identically on all arches not in 99% of cases but in 99.99% (0.01% is 
for cases when the interpreter is broken on a given arch).

Andrey

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[grozin]

Sorry for following up myself,

On Fri, 17 Jan 2014, grozin@gentoo.org wrote:
> OK, let's be conservative. Python and Perl scripts may break on some arches 
> (I'd say it's a rare exception, perhaps 1%, but still). But what about
>
> dev-java/java-sdk-docs
> dev-db/postgresql-docs
> sys-kernel/linux-docs
> dev-dotnet/gtk-sharp-docs
> app-xemacs/general-docs
> dev-util/kdevelop-php-docs
> dev-util/gnome-devel-docs
> app-vim/phpdocs
> gnome-extra/gnome-user-docs
> gnome-extra/gnome-getting-started-docs
> dev-php/smarty-docs
> dev-python/python-docs
> dev-python/cheetah-docs
> app-doc/php-docs
> app-doc/root-docs
> app-doc/geant-docs
> app-doc/blas-docs
> app-doc/lapack-docs
> app-doc/gnucash-docs
> app-office/abiword-docs
> dev-lisp/hyperspec
> sys-apps/man-pages[-*]
>
> and maybe others? They contain no scripts which can possibly break. I'd say 
> they should be keyworded on all arches as soon as they are keyworded on the 
> first arch; the same goes for stabilization. I'd include also packages 
> containing only TeX/LaTeX code - TeX behaves identically on all arches, this 
> was and is its main strength. Also, probably, python/perl/ruby interpreted 
> scripts *which don't load extra libraries* work identically on all arches not 
> in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is 
> broken on a given arch).
Maybe, a good solution is to introduce a special arch, "noarch", for such 
packages (similar to what's done in the rpm world). Then, if a package is 
~noarch, it is automatically considered ~arch for all arches. Similar for 
stable. The maintainer should be able to keyword ~noarch and to stabilize 
noarch. Comments?

Andrey

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Matt Turner]

On Thu, Jan 16, 2014 at 11:02 PM,  <grozin@gentoo.org> wrote:
> Sorry for following up myself,
>
>
> On Fri, 17 Jan 2014, grozin@gentoo.org wrote:
>>
>> OK, let's be conservative. Python and Perl scripts may break on some
>> arches (I'd say it's a rare exception, perhaps 1%, but still). But what
>> about
>>
>> dev-java/java-sdk-docs
>> dev-db/postgresql-docs
>> sys-kernel/linux-docs
>> dev-dotnet/gtk-sharp-docs
>> app-xemacs/general-docs
>> dev-util/kdevelop-php-docs
>> dev-util/gnome-devel-docs
>> app-vim/phpdocs
>> gnome-extra/gnome-user-docs
>> gnome-extra/gnome-getting-started-docs
>> dev-php/smarty-docs
>> dev-python/python-docs
>> dev-python/cheetah-docs
>> app-doc/php-docs
>> app-doc/root-docs
>> app-doc/geant-docs
>> app-doc/blas-docs
>> app-doc/lapack-docs
>> app-doc/gnucash-docs
>> app-office/abiword-docs
>> dev-lisp/hyperspec
>> sys-apps/man-pages[-*]
>>
>> and maybe others? They contain no scripts which can possibly break. I'd
>> say they should be keyworded on all arches as soon as they are keyworded on
>> the first arch; the same goes for stabilization. I'd include also packages
>> containing only TeX/LaTeX code - TeX behaves identically on all arches, this
>> was and is its main strength. Also, probably, python/perl/ruby interpreted
>> scripts *which don't load extra libraries* work identically on all arches
>> not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter
>> is broken on a given arch).
>
> Maybe, a good solution is to introduce a special arch, "noarch", for such
> packages (similar to what's done in the rpm world). Then, if a package is
> ~noarch, it is automatically considered ~arch for all arches. Similar for
> stable. The maintainer should be able to keyword ~noarch and to stabilize
> noarch. Comments?
>
> Andrey

There's been opposition to this in the past, but I'm in favor of
giving this a shot.

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Rich Freeman]

On Fri, Jan 17, 2014 at 2:58 AM, Matt Turner <mattst88@gentoo.org> wrote:
> On Thu, Jan 16, 2014 at 11:02 PM,  <grozin@gentoo.org> wrote:
>> Maybe, a good solution is to introduce a special arch, "noarch", for such
>> packages (similar to what's done in the rpm world). Then, if a package is
>> ~noarch, it is automatically considered ~arch for all arches. Similar for
>> stable. The maintainer should be able to keyword ~noarch and to stabilize
>> noarch. Comments?
>>
> There's been opposition to this in the past, but I'm in favor of
> giving this a shot.
>

I too think it is at least worth a try.  We can learn from this either
way.  Maybe start out leaving it up to maintainer discretion, and if
that becomes an issue we can try to formulate guidelines.

Rich

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Michał Górny]

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

Dnia 2014-01-17, o godz. 14:02:51
grozin@gentoo.org napisał(a):

> Maybe, a good solution is to introduce a special arch, "noarch", for such 
> packages (similar to what's done in the rpm world). Then, if a package is 
> ~noarch, it is automatically considered ~arch for all arches. Similar for 
> stable. The maintainer should be able to keyword ~noarch and to stabilize 
> noarch. Comments?

If you want to play with such a major change, you should start a new
thread instead of starting it in the middle of this spam-art.
Otherwise, many people will miss it and complain loudly afterwards.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Ulrich Mueller]

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

>>>>> On Fri, 17 Jan 2014, grozin  wrote:

> Maybe, a good solution is to introduce a special arch, "noarch", for
> such packages (similar to what's done in the rpm world). Then, if a
> package is ~noarch, it is automatically considered ~arch for all
> arches. Similar for stable. The maintainer should be able to keyword
> ~noarch and to stabilize noarch. Comments?

How would you handle dependencies in such a scenario? All dependencies
must be keyworded or stable on all architectures, before the package
can be keyworded or stabilised on noarch?

Ulrich

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Fri, 17 Jan 2014 16:31:54 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 17 Jan 2014, grozin  wrote:
> 
> > Maybe, a good solution is to introduce a special arch, "noarch", for
> > such packages (similar to what's done in the rpm world). Then, if a
> > package is ~noarch, it is automatically considered ~arch for all
> > arches. Similar for stable. The maintainer should be able to keyword
> > ~noarch and to stabilize noarch. Comments?
> 
> How would you handle dependencies in such a scenario? All dependencies
> must be keyworded or stable on all architectures, before the package
> can be keyworded or stabilised on noarch?

Maybe we can let the package managers only perceive it as keyworded or
stable if all of its dependencies are keyworded or stable on the
architecture that the user runs. Then we can have repoman just ignore
checking dependencies' keywords when we keyword or stabilize them.

Not sure how implementable this idea is though...

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

noarch packages, was Re: [gentoo-dev] rfc: revisiting our stabilization policy

[grozin]

On Fri, 17 Jan 2014, Ulrich Mueller wrote:
>>>>>> On Fri, 17 Jan 2014, grozin  wrote:
>> Maybe, a good solution is to introduce a special arch, "noarch", for
>> such packages (similar to what's done in the rpm world). Then, if a
>> package is ~noarch, it is automatically considered ~arch for all
>> arches. Similar for stable. The maintainer should be able to keyword
>> ~noarch and to stabilize noarch. Comments?
>
> How would you handle dependencies in such a scenario? All dependencies
> must be keyworded or stable on all architectures, before the package
> can be keyworded or stabilised on noarch?
Many "pure data" packages don't depend on anything.

Pure TeX/LaTeX packages should be keyworded ~noarch only if a suitable 
binary TeX is keyworded for each arch. Hmm, this, probably, means that 
they can never be stabilized as noarch.

Pure python scripts (without library dependencies) should become ~noarch 
if some suitable python binary is keyworded for each arch. Similarly for 
perl, ruby. Python is installed on each Gentoo box anyway, so, in this 
case it is less problematic.

Andrey

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[grozin]

On Fri, 17 Jan 2014, Tom Wijsman wrote:
> On Fri, 17 Jan 2014 16:31:54 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>> On Fri, 17 Jan 2014, grozin  wrote:
>>> Maybe, a good solution is to introduce a special arch, "noarch", for
>>> such packages (similar to what's done in the rpm world). Then, if a
>>> package is ~noarch, it is automatically considered ~arch for all
>>> arches. Similar for stable. The maintainer should be able to keyword
>>> ~noarch and to stabilize noarch. Comments?
>>
>> How would you handle dependencies in such a scenario? All dependencies
>> must be keyworded or stable on all architectures, before the package
>> can be keyworded or stabilised on noarch?
>
> Maybe we can let the package managers only perceive it as keyworded or
> stable if all of its dependencies are keyworded or stable on the
> architecture that the user runs. Then we can have repoman just ignore
> checking dependencies' keywords when we keyword or stabilize them.
Very reasonable.

Andrey

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Ciaran McCreesh]

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

On Fri, 17 Jan 2014 17:47:58 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> Maybe we can let the package managers only perceive it as keyworded or
> stable if all of its dependencies are keyworded or stable on the
> architecture that the user runs. Then we can have repoman just ignore
> checking dependencies' keywords when we keyword or stabilize them.
> 
> Not sure how implementable this idea is though...

It's going to hurt for four reasons that I can think of right now.

Firstly, things you think are "obviously portable" sometimes aren't.

Secondly, users already get confused by "stable use masks". This is
going to be even worse: users aren't going to understand why a noarch
package isn't available for them.

Thirdly, you have to decide how to deal with long chains and cycles in
noarch dependencies.

Fourthly, the interaction with || deps is an awful mess.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Maciej Mrozowski]

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

On Friday 17 of January 2014 13:06:22 grozin@gentoo.org wrote:

| dev-util/kdevelop-php-docs

While of course it doesn't invalidate your entire idea, this particular example
is a kdevelop plugin written in C++ that provides php API documentation integration.
This tells however that decision to "auto"-keyword/stabilize remaining arches
cannot be taken lightly and not by everyone.

regards
MM

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Fri, 17 Jan 2014 18:28:41 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 17 Jan 2014 17:47:58 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > Maybe we can let the package managers only perceive it as keyworded
> > or stable if all of its dependencies are keyworded or stable on the
> > architecture that the user runs. Then we can have repoman just
> > ignore checking dependencies' keywords when we keyword or stabilize
> > them.
> > 
> > Not sure how implementable this idea is though...
> 
> It's going to hurt for four reasons that I can think of right now.
> 
> Firstly, things you think are "obviously portable" sometimes aren't.

We could write a search for architecture dependent / specific code.

> Secondly, users already get confused by "stable use masks". This is
> going to be even worse: users aren't going to understand why a noarch
> package isn't available for them.

We can improve the output of the package manager to make this easier
to understand; one way is to clarify it, the other way is to just
replace it by the actual archictecture the user runs.

As a side note, I think we might want to name this anyarch... :)

> Thirdly, you have to decide how to deal with long chains and cycles in
> noarch dependencies.
>
> Fourthly, the interaction with || deps is an awful mess.

Yes, these are though problems to resolve; my mind came up with that
this idea needs recursion, hence the "not sure how implementable".

A cycle can be broken by stopping to continue to a certain dependency
if that dependency is of the parent reverse dependencies, capture the
set of packages as a cycle. Then check for each package in the cycle if
their dependencies satisfy each package; if so, all the packages in
the cycle are satisfied.

Of course, this doesn't take into account more complex cycles were two
cycles are connected to each other; but if we would have such thing,
I'd rather see that get fixed in the Portage tree as that sounds like a
needlessly complex set of ebuilds.

Long chains might or might exist and might or might not be problematic,
that's something we would need to test out when this is implemented.

|| deps can be done, just check them in the same order like before;
what I'm more scared of is the amount of anyarch/noarch there would be
added to the Portage tree, just a few can be easily done.

If it is going to be a large share of the Portage tree we'll want to
look for another design or just not change how this works at all. 

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Manuel Rüger]

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

On 01/17/2014 06:08 PM, grozin@gentoo.org wrote:
> On Fri, 17 Jan 2014, Tom Wijsman wrote:
>> On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller
>> <ulm@gentoo.org> wrote:
>>>>>>>> On Fri, 17 Jan 2014, grozin  wrote:
>>>> Maybe, a good solution is to introduce a special arch,
>>>> "noarch", for such packages (similar to what's done in the
>>>> rpm world). Then, if a package is ~noarch, it is
>>>> automatically considered ~arch for all arches. Similar for
>>>> stable. The maintainer should be able to keyword ~noarch and
>>>> to stabilize noarch. Comments?
>>> 
>>> How would you handle dependencies in such a scenario? All
>>> dependencies must be keyworded or stable on all architectures,
>>> before the package can be keyworded or stabilised on noarch?
>> 
>> Maybe we can let the package managers only perceive it as
>> keyworded or stable if all of its dependencies are keyworded or
>> stable on the architecture that the user runs. Then we can have
>> repoman just ignore checking dependencies' keywords when we
>> keyword or stabilize them.
> Very reasonable.
> 
> Andrey
> 


I think the idea itself is good, but we should not add this to
KEYWORDS directly, as it might cause some problems with older package
managers(?).

A new variable can be introduced, which will overwrite testing
keywords to stable keywords, if the var is set to "stable" and keeps
everything in KEYWORDS marked as testing otherwise.

If this var exists in an ebuild and there is a new stabilization bug,
the arch team can decide if they want to mark it stable for all
architectures (via setting the var to stable) or only for the
architecture they tested it for (if some dependencies are missing on
other architectures).
This practice ensures that at least one arch team member of any arch
tested it.

The use of the to-be-added variable could also be extended for
vulnerability fixing.
It's more important to users to deal with less vulnerabilities for a
long time than a working stable dependency tree. Because the latter
got easier with the autounmask feature in portage.

If the var is set by the maintainer to "security-fix-$bugid" and the
users add an option to their profile, it automatically sets the ebuild
to stable and prompts an info with the bugid.
Users who do not want to wait for stabilization or GLSA have a better
possibility to secure their system earlier.
The advantage in general is that quickly added fixes get a wider
testing. So stable users will also profit.


Cheers

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

iQJ8BAEBCgBmBQJS2cwvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcpuwP/27np/ekt9AWHJz/OC7BpDz8
gxrE0iuocczV6m5/CejSY8GEdd26xQRdyloZ/7f74W1I5jRB/WPbHUKa0dnglZba
AG/WRJRYOao6537t5p9n6knH3Bj0wIcZl90Jox80HOXsvk/eBwZaliE+jcA+6Mat
Dcl0FVgl/b1WJZaa0aEt5st8nnW5TJ5ZTuWBG6e6shH94qAFcr8VWLOTtY1xqvHf
U1GHlynM4h+nX7BnDlhPxPf2l9XPBZNQFOAvWfvE341uZcSUpkQYfYzpo2TKdYop
oPL6hfMsHq5uggB0OvVaf4CiuCKhV3re7GVexKJE9Moigrb0v/nWCy5ApvR0Ww/N
7wozyGcWUKc/oHW3CHGAYr4wbFjjI9LjB5IVEjmEAGmJ5bq7/RViM+5slj/s9kBe
Vioti6i2vYVs4awm/HrMvremVUJ03Deh8uwVnOaggyrggRnwbxEsRxdsMCmYNkKN
2xAVvnSi2YEMSwBWvClRJwFvvrZzzsWd+t2Y/e/VqAFNvZn0H0lqZAP1+z540nzU
I7f2ym88jedwRJq41q6TgI9XaHlTFXLMcb9Hu19Xv/faUu5jHxg+ZvQtIwC/2YRy
6La1PGO9uk0wHOgixHe/bPXmZ2ArTHB6pAzgiLMpQxuahJhbGXiTmjM8qBc8IKD2
t0VP0WhLWZahQtQ21vrW
=UumH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[William Hubbs]

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

On Fri, Jan 17, 2014 at 04:02:27PM +0100, Michał Górny wrote:
> Dnia 2014-01-17, o godz. 14:02:51
> grozin@gentoo.org napisał(a):
> 
> > Maybe, a good solution is to introduce a special arch, "noarch", for such 
> > packages (similar to what's done in the rpm world). Then, if a package is 
> > ~noarch, it is automatically considered ~arch for all arches. Similar for 
> > stable. The maintainer should be able to keyword ~noarch and to stabilize 
> > noarch. Comments?
> 
> If you want to play with such a major change, you should start a new
> thread instead of starting it in the middle of this spam-art.
> Otherwise, many people will miss it and complain loudly afterwards.

I am going to agree with mgorny on this; highjacking this thread with
this change is not appropriate; all we were doing in this thread is
trying to figure out a way to improve our stabilization policy.

Introducing a "noarch" keyword should be discussed in a completely
separate thread.

William

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

[gentoo-dev] arch="any" (Re: rfc: revisiting our stabilization policy)

[Steven J. Long]

On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote:
> On Fri, 17 Jan 2014 18:28:41 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Fri, 17 Jan 2014 17:47:58 +0100
> > Tom Wijsman <TomWij@gentoo.org> wrote:
> > > Maybe we can let the package managers only perceive it as keyworded
> > > or stable if all of its dependencies are keyworded or stable on the
> > > architecture that the user runs. Then we can have repoman just
> > > ignore checking dependencies' keywords when we keyword or stabilize
> > > them.
> > > 
> > > Not sure how implementable this idea is though...

Seems reasonable to me: it's a property of the tree per-arch, that can
be calculated post-sync client-side, if all else fails, based on the
metadata cache for standard ebuilds. So the resolver doesn't need to
worry about it (as far as the resolver's concerned the ebuild is arch or
~arch according to CHOST.)

> As a side note, I think we might want to name this anyarch... :)

I agree, arch="any" makes a lot more sense.

> > It's going to hurt for four reasons that I can think of right now.
> > 
> > Firstly, things you think are "obviously portable" sometimes aren't.
> 
> We could write a search for architecture dependent / specific code.
> 
> > Secondly, users already get confused by "stable use masks". This is
> > going to be even worse: users aren't going to understand why a noarch
> > package isn't available for them.
> 
> We can improve the output of the package manager to make this easier
> to understand; one way is to clarify it, the other way is to just
> replace it by the actual archictecture the user runs.

Well, if we follow your idea, then the user won't know it's arch="any",
since by the time resolution happens, it's marked stable or testing for
the user's arch. So I don't really see the issue, though better info
is always useful, and in case of problem, we'd likely want to be told
it's an arch="~any" and what its dependencies are.

But that's in the slowpath when there's a problem the resolver can't
handle itself.

> > Thirdly, you have to decide how to deal with long chains and cycles in
> > noarch dependencies.
> >
> > Fourthly, the interaction with || deps is an awful mess.
> 
> Yes, these are though problems to resolve; my mind came up with that
> this idea needs recursion, hence the "not sure how implementable".

These are standard dep resolution problems already, and given that the
mangler is to consider it either arch or ~arch according to the user
arch, and the state of its dependencies in the cache which can be worked
out post-sync, this is exactly the same problem as the rest of the tree.

So the rest of your mail appears to be a discussion of prior art.

> If it is going to be a large share of the Portage tree we'll want to
> look for another design or just not change how this works at all.

Still not seeing the problem: perhaps we can see the roadblock in
implementation. About the only issue I can see is trying to break
an R/PDEPEND cycle, but again the question of whether its arch="any"
is orthogonal, given your definition, so again that is covered by
prior art.

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 862 bytes --]

On Friday 17 January 2014 02:02:51 grozin@gentoo.org wrote:
> Maybe, a good solution is to introduce a special arch, "noarch", for such
> packages (similar to what's done in the rpm world). Then, if a package is
> ~noarch, it is automatically considered ~arch for all arches. Similar for
> stable. The maintainer should be able to keyword ~noarch and to stabilize
> noarch. Comments?

you mean * ?  this already works today (at least with portage):
	KEYWORDS="~*"
	KEYWORDS="*"

in fact, i was planning on converting Chromium OS over to use this instead of 
a list of arches.  but that's because we run a simpler system of there really 
only being two sets of ebuilds in the tree -- stable for all and unstable for 
all.

for the ebuilds that are truly arch-specific (or otherwise need restricting), 
then we'll do:
	KEYWORDS="-* ~arm"
-mike

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

Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy)

[Pacho Ramos]

El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> On Friday 17 January 2014 02:02:51 grozin@gentoo.org wrote:
> > Maybe, a good solution is to introduce a special arch, "noarch", for such
> > packages (similar to what's done in the rpm world). Then, if a package is
> > ~noarch, it is automatically considered ~arch for all arches. Similar for
> > stable. The maintainer should be able to keyword ~noarch and to stabilize
> > noarch. Comments?
> 
> you mean * ?  this already works today (at least with portage):
> 	KEYWORDS="~*"
> 	KEYWORDS="*"
> 
> in fact, i was planning on converting Chromium OS over to use this instead of 
> a list of arches.  but that's because we run a simpler system of there really 
> only being two sets of ebuilds in the tree -- stable for all and unstable for 
> all.
> 
> for the ebuilds that are truly arch-specific (or otherwise need restricting), 
> then we'll do:
> 	KEYWORDS="-* ~arm"
> -mike

I had no idea that existed :O, I guess something related with
"specification" is missing? :/

[gentoo-dev] Re: Add a KEYWORD representing any arch

[Ulrich Mueller]

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

>>>>> On Sun, 19 Jan 2014, Pacho Ramos wrote:

> El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
>> you mean * ? this already works today (at least with portage):
>>       KEYWORDS="~*"
>>       KEYWORDS="*"

Currently not allowed by policy:
http://devmanual.gentoo.org/keywording/index.html

> I had no idea that existed :O, I guess something related with
> "specification" is missing? :/

Now what problem are we trying to solve? As I see it, it is mainly
one of manpower, namely that some arch teams cannot keep up with
stable requests, and I doubt that any technical solution will help
to solve this. Introducing a "noarch" keyword or allowing "*" will
potentially cause problems with dependency resolution.

Instead, we should come up with a clear set of rules under what
circumstances package maintainers are allowed to stabilise ebuilds
themselves on all architectures.

Ulrich

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

Re: Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1368 bytes --]

On Sunday 19 January 2014 04:28:33 Pacho Ramos wrote:
> El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> > On Friday 17 January 2014 02:02:51 grozin@gentoo.org wrote:
> > > Maybe, a good solution is to introduce a special arch, "noarch", for
> > > such packages (similar to what's done in the rpm world). Then, if a
> > > package is ~noarch, it is automatically considered ~arch for all
> > > arches. Similar for stable. The maintainer should be able to keyword
> > > ~noarch and to stabilize noarch. Comments?
> > 
> > you mean * ?  this already works today (at least with portage):
> > 	KEYWORDS="~*"
> > 	KEYWORDS="*"
> > 
> > in fact, i was planning on converting Chromium OS over to use this
> > instead of a list of arches.  but that's because we run a simpler system
> > of there really only being two sets of ebuilds in the tree -- stable for
> > all and unstable for all.
> > 
> > for the ebuilds that are truly arch-specific (or otherwise need
> > restricting),  then we'll do:
> > 	KEYWORDS="-* ~arm"
> 
> I had no idea that existed :O, I guess something related with
> "specification" is missing? :/

specs are for chumps!  although PMS documents -* already, so * and ~* is a 
logical extension.  i suspect on the portage side the history is related to 
package.keywords support.  but i'm just guessing.
-mike

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

Re: [gentoo-dev] Re: Add a KEYWORD representing any arch

[Pacho Ramos]

El dom, 19-01-2014 a las 10:46 +0100, Ulrich Mueller escribió:
> >>>>> On Sun, 19 Jan 2014, Pacho Ramos wrote:
> 
> > El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> >> you mean * ? this already works today (at least with portage):
> >>       KEYWORDS="~*"
> >>       KEYWORDS="*"
> 
> Currently not allowed by policy:
> http://devmanual.gentoo.org/keywording/index.html
> 
> > I had no idea that existed :O, I guess something related with
> > "specification" is missing? :/
> 
> Now what problem are we trying to solve? As I see it, it is mainly
> one of manpower, namely that some arch teams cannot keep up with
> stable requests, and I doubt that any technical solution will help
> to solve this. Introducing a "noarch" keyword or allowing "*" will
> potentially cause problems with dependency resolution.
> 
> Instead, we should come up with a clear set of rules under what
> circumstances package maintainers are allowed to stabilise ebuilds
> themselves on all architectures.
> 
> Ulrich

Yeah, the problem is manpower and, then, we are thinking in cases like
wallpapers, changes in the installation of some files (that are not arch
specific)... But, how to indicate a concrete package can be handled in
this special "noarch" way? It's easy for some cases like I posted, but
there are others that are more difficult to handle (perl modules for
example?)

If we could agree on the kind of packages we could handle in this way
(stabilizing for all arches) would be nice

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Thomas Sachau]

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

William Hubbs schrieb:
> When you say "drop keywords" do you mean:
> 
> 1) revert the old version back to ~arch or
> 2) remove the old version.
> 
> As a maintainer, I would rather do 2, because I do not want to backport
> fixes to the old version.
> 
> William
> 

With 1) users would still be using newer versions with ~arch keyword
except with explicit mask on newer versions, so keeping the old versions
doesnt make much sense.

With 2), there may be additional one-time cost for the maintainer (since
he should check with reserve dependencies first to avoid broken
dependency trees), but afterwards this solution should mean an adjusted
amount of stable packages for each arch and no permanent additional work
for the maintainer.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Christopher Head]

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

On Thu, 16 Jan 2014 23:44:42 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> > If I don’t, why do I care if the package is a year old? I lose none
> > of my time to use the old version, since it does all I want;
> 
> This is under the assumption that the old version has no further
> implications, which is a false assumption; because the older a stable
> ebuild get, the higher the chance is that it becomes incompatible with
> its libraries and/or causes blockers. Even further, a security bug for
> an old version of a library it depends on could cause its removal.

Right, of course things can become incompatible—but the distro handles
that by either leaving old enough version of e.g. libraries around that
the latest stable versions of their reverse dependencies don’t break,
or, in exceptional cases (e.g. security), by breaking things
intentionally if necessary, thus telling me that there’s a problem.

> > I lose a
> > nonzero amount of time if I get a version which breaks things (even
> > if the only time I lose is the time it takes to downgrade),
> 
> Depends on whether the stable version is as perfect as one thinks it
> is; an upgrade can go two ways, it improves or regresses. (Well, three
> ways as it can stay the same, but that wouldn't demonstrate the point)

Well, yes. I was considering the case of a stable version that does
work well. If the stable version has a bug that affects me, I won’t be
using it—I’ll pull in an unstable version that fixes the bug, and then
get back to stable ASAP after that.

> > so it’s in my best interest to use the stable versions of such
> > packages, even if they’re a month, a year, or three years old.
> 
> Based on what you know, what you need and that you can resist change;
> yes, but this doesn't take into account what you don't know, you don't
> know you need and the improvements that change can bring.
> 
> While it doesn't happen often, some people will say "if I knew this
> earlier, I would have already upgraded a long while ago"; either
> because the new version brings something good, or the old version has
> a regression they were not aware of yet or came due to
> incompatibility...

Sure, it was wrong to say it takes *no* time, but I think less time
than sticking to the bleeding edge and having things break from time to
time. My experience with stable has been that bugs (at least bugs that
I encounter) are rare and, most importantly, bugs are *very* rare in the
important packages that are hard to fix (glibc, openrc, gentoo-sources,
openssh for servers, etc.). I understand they’re fairly rare in unstable
as well, but I would expect a bit more common than in stable.

If stable really is falling behind and the backlog is always growing,
obviously something has to be done. I just don’t want “something” to
mean “don’t have a stable tree”. The stable tree provides me with a
benefit. If standards have to slip a bit to maintain timeliness, then
I’d prefer a stable tree that’s as stable as practical, accepting
reality—perhaps where users are able to submit reports of working
packages, or where we let platform-agnostic packages be stabilized
after one arch has tested, or various of the other suggestions in this
thread. Just not no stable tree at all.
-- 
Christopher Head

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

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Sun, 19 Jan 2014 14:31:57 -0800
Christopher Head <chead@chead.ca> wrote:

> Right, of course things can become incompatible—but the distro handles
> that by either leaving old enough version of e.g. libraries around
> that the latest stable versions of their reverse dependencies don’t
> break, or, in exceptional cases (e.g. security), by breaking things
> intentionally if necessary, thus telling me that there’s a problem.

True, note that upper limits on the dependencies (<cat/pkg-ver) or
similar blockers are not always in place; which can make this
problematic if the maintainer doesn't catch the incompatible regression,
especially since a lot of us run testing and don't look after older
or stable packages as much as we would want.

> If stable really is falling behind and the backlog is always growing,
> obviously something has to be done. I just don’t want “something” to
> mean “don’t have a stable tree”. The stable tree provides me with a
> benefit. If standards have to slip a bit to maintain timeliness, then
> I’d prefer a stable tree that’s as stable as practical, accepting
> reality—perhaps where users are able to submit reports of working
> packages, or where we let platform-agnostic packages be stabilized
> after one arch has tested, or various of the other suggestions in this
> thread. Just not no stable tree at all.

+1 as long as we can find effort and ways to keep it around.

-- 
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: Add a KEYWORD representing any arch

[Steev Klimaszewski]

On Sun, 2014-01-19 at 10:46 +0100, Ulrich Mueller wrote:
> Now what problem are we trying to solve? As I see it, it is mainly
> one of manpower, namely that some arch teams cannot keep up with
> stable requests, and I doubt that any technical solution will help
> to solve this. Introducing a "noarch" keyword or allowing "*" will
> potentially cause problems with dependency resolution.
> 
> Instead, we should come up with a clear set of rules under what
> circumstances package maintainers are allowed to stabilise ebuilds
> themselves on all architectures.
> 

When they have machines that cover all architectures - assuming there is
some sort of machine code at all.  Otherwise, why even bother having
stable keywords?  Everyone keeps going on about how they will
potentially have issues because something old is stable - I've thrown
out that maybe we should (after a certain amount of time - when cleaning
maybe?) remove all keywords except the only stable one, and then leaving
it up to the slow arches.  

I know what the dev manual says, but I'd much rather have an old ebuild
that's KEYWORDS="-* arm" than have that ebuild removed because a new one
is KEYWORDS="arm" that doesn't work at all. Everyone else keeps talking
in the theoretical, and I'm talking an actual issue.  This affects me
and my workflow and ask ryao about how he wanted to emerge git-9999 to
look into fixing it...


-- steev

Re: [gentoo-dev] Re: Add a KEYWORD representing any arch

[Jeroen Roovers]

On Sun, 19 Jan 2014 10:46:28 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> Instead, we should come up with a clear set of rules under what
> circumstances package maintainers are allowed to stabilise ebuilds
> themselves on all architectures.

The cases where stabilisation is important (for security, progress) are
usually those where this arbitrary type of stabilisation is not an
option, unless we drop all pretence of upholding the dictionary meaning
of "stabilisation".

What we need is architecture teams that clearly do the work (as a team),
or we drop their stable status. Recent "advances" in stabilisation
practices certainly haven't helped establish a reliable picture of some
teams.

If a team cannot keep up stabilising thousands of packages, then it
should focus in the short term on dropping keywords for "extra"
packages, and then in the long term focus on getting a reliable base
system up to date (i.e. drop all the "fun" keywording and focus on what
that platform really must have to get a system running).

If all that doesn't pan out, then we should set the QA hounds on
them. :)


     jer

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steven J. Long]

On Mon, Jan 20, 2014, Tom Wijsman wrote:
> On Sun, 19 Jan 2014, Christopher Head wrote:
> > If stable really is falling behind and the backlog is always growing,
> > obviously something has to be done. I just don't want "something" to
> > mean "don't have a stable tree". The stable tree provides me with a
> > benefit. If standards have to slip a bit to maintain timeliness, then
> > I'd prefer a stable tree that's as stable as practical, accepting
> > reality-- perhaps where users are able to submit reports of working
> > packages, or where we let platform-agnostic packages be stabilized
> > after one arch has tested, or various of the other suggestions in this
> > thread. Just not no stable tree at all.
> 
> +1 as long as we can find effort and ways to keep it around.

What? Without a stable tree, Gentoo is useless afaic.

I don't think that's what was being proposed, though. The question was
really the old complaint about slow architectures; the "-* arch"
solution sounds like the most reasonable definition of "dropping"
keywords, in the absence of AT communication otherwise.

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 23 Jan 2014 18:12:42 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> On Mon, Jan 20, 2014, Tom Wijsman wrote:
> > On Sun, 19 Jan 2014, Christopher Head wrote:
> > > If stable really is falling behind and the backlog is always
> > > growing, obviously something has to be done. I just don't want
> > > "something" to mean "don't have a stable tree". The stable tree
> > > provides me with a benefit. If standards have to slip a bit to
> > > maintain timeliness, then I'd prefer a stable tree that's as
> > > stable as practical, accepting reality-- perhaps where users are
> > > able to submit reports of working packages, or where we let
> > > platform-agnostic packages be stabilized after one arch has
> > > tested, or various of the other suggestions in this thread. Just
> > > not no stable tree at all.
> > 
> > +1 as long as we can find effort and ways to keep it around.
> 
> What? Without a stable tree, Gentoo is useless afaic.

It moves us closer to upstream releases, a little more bleeding edge; a
lot of users and developers run that already, it is found to be useful.

> I don't think that's what was being proposed, though. The question was
> really the old complaint about slow architectures; the "-* arch"
> solution sounds like the most reasonable definition of "dropping"
> keywords, in the absence of AT communication otherwise.

Dropping keywords and specifying -* are a world apart of each other.

The former means that it is not ready for wide stable or testing users,
the latter means that it has been tested to not work at all;
furthermore, we need to explicitly specify which arches in that case.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Thu, 2014-01-23 at 20:13 +0100, Tom Wijsman wrote:
> > I don't think that's what was being proposed, though. The question was
> > really the old complaint about slow architectures; the "-* arch"
> > solution sounds like the most reasonable definition of "dropping"
> > keywords, in the absence of AT communication otherwise.
> 
> Dropping keywords and specifying -* are a world apart of each other.
> 
> The former means that it is not ready for wide stable or testing users,
> the latter means that it has been tested to not work at all;
> furthermore, we need to explicitly specify which arches in that case.
> 
The complaint is slow to stable arches - by specifying "-* arch" it
would signify that ONLY that arch uses that version of the ebuild - and
it would be up to the arch team to remove it once they've stabled the
new version - and considering the complaint is only about slow arches,
there's nothing additional to specify in there - it's REMOVING arches
that have stabled a newer version already, so they are unaffected.  

On the other hand, you're suggesting that we don't actually bother with
stabling things - or actually testing that things are properly stable,
allowing anyone to decide when something is stable, whether they have
access to the hardware to actually test that it works.  You and a few
others keep talking in the theoretical while I've shown an actual
problem but you and the others conveniently ignore ACTUAL problems in
favor of your possible problems.  Please stop.

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 23 Jan 2014 14:55:34 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> On Thu, 2014-01-23 at 20:13 +0100, Tom Wijsman wrote:
> The complaint is slow to stable arches

Yes.

> by specifying "-* arch" it would signify that ONLY that arch uses
> that version of the ebuild - and it would be up to the arch team to
> remove it once they've stabled the new version - and considering the
> complaint is only about slow arches, there's nothing additional to
> specify in there - it's REMOVING arches that have stabled a newer
> version already, so they are unaffected.  

As this is a suggestion that is made by someone else, whom I have
already replied to stating this is a world apart from the discussion
in this thread; I am skipping this entire paragraph, I think you meant
to send the reply to the other person with his/her post as In-Reply-To.

> On the other hand, you're suggesting that we don't actually bother
> with stabling things or actually testing that things are properly
> stable, allowing anyone to decide when something is stable, whether
> they have access to the hardware to actually test that it works.

This is missing reference, and thus I doubt if that is my suggestion.
Looking back at the entire context of this thread, I have made several
"ideas" as various options; which was done as to feed the discussion to
consider several viewpoints.

> You and a few others keep talking in the theoretical

This thread is based on an actual problem.

> while I've shown an actual problem but you and the others
> conveniently ignore ACTUAL problems in favor of your possible
> problems.  Please stop.

Well, as seen on #gentoo-dev you shoot down solutions. Please consider.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Peter Stuge]

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

Tom Wijsman wrote:
> you shoot down solutions

Maybe it wasn't a very good solution that deserved to be shot down.


//Peter

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 23 Jan 2014 23:42:28 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > you shoot down solutions
> 
> Maybe it wasn't a very good solution that deserved to be shot down.

Maybe it was; what is needed here, is the feedback that makes it better.

Work towards a very good solution deserves more than a plain /dev/null;
if they end up in /dev/null when provided, solutions appear unwelcome.

Constructivism has to come from both sides to have an useful discussion.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Fri, 2014-01-24 at 00:50 +0100, Tom Wijsman wrote:
> On Thu, 23 Jan 2014 23:42:28 +0100
> Peter Stuge <peter@stuge.se> wrote:
> 
> > Tom Wijsman wrote:
> > > you shoot down solutions
> > 
> > Maybe it wasn't a very good solution that deserved to be shot down.
> 
> Maybe it was; what is needed here, is the feedback that makes it better.
> 
> Work towards a very good solution deserves more than a plain /dev/null;
> if they end up in /dev/null when provided, solutions appear unwelcome.
> 
> Constructivism has to come from both sides to have an useful discussion.
> 

Your "suggestion" was expanding the "arm" keyword to "armv4-linux",
"armv5-linux", "armv6-linux", "armv6-hardfloat-linux",
"armv7-softfp-linux", "armv7-hardfloat-linux",
"armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution.
The /dev/null comment was about wanting others to do the work and not
contributing anything more than (imo) a stupid idea - if you aren't
willing to put in the work, don't expect others to.


And yes, I see what you mean now re: my reply seeming off - it would
seem when I hit group reply, for some reason, Evolution is putting Peter
Stuge into the CC, and not Tom Wijsman (despite hitting group reply from
your email.  Maybe there should have been more testing of Gnome 3.8
before it was stabled on x86...

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 23 Jan 2014 18:04:19 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> Your "suggestion" was expanding the "arm" keyword to "armv4-linux",
> "armv5-linux", "armv6-linux", "armv6-hardfloat-linux",
> "armv7-softfp-linux", "armv7-hardfloat-linux",
> "armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution.

We've ran over the reasons and they have appeared as fit for this idea.

It can be prejudged as "nowhere near a good solution"; but for it to
actually be that, it would need solid reasoning that people agree on.

Reasoning is also needed to be able to figure out which conditions are
fit for another solution; that way, the other solutions could be shaped
with the help of that feedback to make the other solutions better.

> The /dev/null comment was about wanting others to do the work and not
> contributing anything more than (imo) a stupid idea

The idea moves work from one place to another, which yields the same
amount of work; your work statement seems like another topic, which you
are making basic assumptions on. Solutions to the stated actual problem
are neglected, as more time for research and consideration is needed.

To get on the topic of your work statement; consider that one can find
7 people whom each have one arm configuration much faster than one can
find 1 person that has all of them.

> if you aren't willing to put in the work, don't expect others to.

If you are unwilling to work towards solutions, don't expect others to.

> And yes, I see what you mean now re: my reply seeming off - it would
> seem when I hit group reply, for some reason, Evolution is putting
> Peter Stuge into the CC, and not Tom Wijsman (despite hitting group
> reply from your email.  Maybe there should have been more testing of
> Gnome 3.8 before it was stabled on x86...

http://www.unicom.com/pw/reply-to-harmful.html
http://woozle.org/~neale/papers/reply-to-still-harmful.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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Fri, 2014-01-24 at 04:04 +0100, Tom Wijsman wrote:
> On Thu, 23 Jan 2014 18:04:19 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > Your "suggestion" was expanding the "arm" keyword to "armv4-linux",
> > "armv5-linux", "armv6-linux", "armv6-hardfloat-linux",
> > "armv7-softfp-linux", "armv7-hardfloat-linux",
> > "armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution.
> 
> We've ran over the reasons and they have appeared as fit for this idea.
> 
> It can be prejudged as "nowhere near a good solution"; but for it to
> actually be that, it would need solid reasoning that people agree on.
> 
> Reasoning is also needed to be able to figure out which conditions are
> fit for another solution; that way, the other solutions could be shaped
> with the help of that feedback to make the other solutions better.
> 
> > The /dev/null comment was about wanting others to do the work and not
> > contributing anything more than (imo) a stupid idea
> 
> The idea moves work from one place to another, which yields the same
> amount of work; your work statement seems like another topic, which you
> are making basic assumptions on. Solutions to the stated actual problem
> are neglected, as more time for research and consideration is needed.
> 

> To get on the topic of your work statement; consider that one can find
> 7 people whom each have one arm configuration much faster than one can
> find 1 person that has all of them.
> 

The idea moves the work around, it doesn't lessen the workload at all.
You can easily find 7 people who have an armv7, and even v6, since the
rpi is quite popular.  Getting them into the arch team and willing to
run stable and actually test programs is a whole other story, which lead
to you saying:

"People that have certain architectures can just add themselves, no
extra work again."

And that's a show stopper, just randomly adding yourself to an arch team
and claiming you've tested it is a nonstarter.  Considering if there IS
an issue, we then have to track you down and figure out why/what is
different in the configuration that it's failing for others.  You being
on the QA team even offering that up as an option makes it questionable
as to why you're on the QA team.  That should never even be thought of
as an option.

What you've thrown out as a possible solution is akin to taking a pile
of peas on the plate and moving them around the plate so that the pile
doesn't look so big.  

It doesn't change the amount of work, but you do need to look in more
places for the work.  Finding people with the hardware is the main
issue, and I think I mentioned before, some people are simply unwilling
to invest in "slow" hardware, so we have to rely on the people who DO
have it.  And if that means things take longer to stable, well, why is
that an issue?  Stable is supposed to be that - stable.  

> > if you aren't willing to put in the work, don't expect others to.
> 
> If you are unwilling to work towards solutions, don't expect others to.
> 
> > And yes, I see what you mean now re: my reply seeming off - it would
> > seem when I hit group reply, for some reason, Evolution is putting
> > Peter Stuge into the CC, and not Tom Wijsman (despite hitting group
> > reply from your email.  Maybe there should have been more testing of
> > Gnome 3.8 before it was stabled on x86...
> 
> http://www.unicom.com/pw/reply-to-harmful.html
> http://woozle.org/~neale/papers/reply-to-still-harmful.html
> 

I don't care of "reply to" is considered harmful, I care that something
that worked with the previous stable is suddenly not working with the
new stable.  It obviously shows that it wasn't tested properly, and yet
was marked stable.  So, as QA, shouldn't you be doing something about
that, rather than pointing to some URLs on the web, telling me I'm in
the wrong for using the option that is supposed to handle that properly
in my stable software?

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steven J. Long]

Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > What? Without a stable tree, Gentoo is useless afaic.
> 
> It moves us closer to upstream releases, a little more bleeding edge; a
> lot of users and developers run that already, it is found to be useful.

What? More vague. As are many of your philosophical statements in later
and prior mails, so I'll ignore those.

> > I don't think that's what was being proposed, though. The question was
> > really the old complaint about slow architectures; the "-* arch"
> > solution sounds like the most reasonable definition of "dropping"
> > keywords, in the absence of AT communication otherwise.
> 
> Dropping keywords and specifying -* are a world apart of each other.

That's why it's in quotes.

> The former means that it is not ready for wide stable or testing users,
> the latter means that it has been tested to not work at all;
> furthermore, we need to explicitly specify which arches in that case.

You're missing the point, again. The question was what does "dropping
keywords" mean, when the maintainer has stabilised a newer version on
the arch/s s/he has available, but feels that slower archs are holding
up that process. I'm slightly at a loss as to why it's such a big deal
to just leave the old ebuild as-is, given that anyone on a stabled
arch should upgrade automatically.

But given that the maintainer feels they don't want that old ebuild
around, and that the arch in question has not got round to testing the
new one, for whatever reason (it's their call, after all, as to how
their arch progresses), instead of simply removing that ebuild, or
bumping it to unstable (which makes zero sense), just leave it stable
on the slow arch/s in question, and remove the others.

If you must do anything, which I'm unpersuaded about, but it's your
call, as maintainer.

This seems like a rarity, but when it's an issue, people get annoyed on
either side. The solution proposed by the ARM team, seems like a simple
way round, and indicates clearly to anyone perusing the ebuild, that a
newer version needs stabling on the "slow" archs.

By all means, raise technical objections; just not a philosophical one.

Again this is a minor issue afaic, in terms of frequency, need for
change, and how difficult it is to solve. Resolve it, and let's get back
to the fun stuff instead.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Thu, 23 Jan 2014 21:52:47 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> The idea moves the work around, it doesn't lessen the workload at all.

It is an idea to solve your actual problem, which isn't workload.

> You can easily find 7 people who have an armv7, and even v6, since the
> rpi is quite popular.

They are easier to find than someone that has everything.

> Getting them into the arch team and willing to run stable and
> actually test programs is a whole other story, which lead to you
> saying:
> 
> "People that have certain architectures can just add themselves, no
> extra work again."

Which is for people already on the arm arch; consider the context you
quote this from, rather than assuming what is not explicitly stated.

> What you've thrown out as a possible solution is akin to taking a pile
> of peas on the plate and moving them around the plate so that the pile
> doesn't look so big.  

In other words, using separation to organize them properly.

> It doesn't change the amount of work, but you do need to look in more
> places for the work.

Which you can collect back into one place.

> Finding people with the hardware is the main issue, and I think I
> mentioned before, some people are simply unwilling to invest in
> "slow" hardware, so we have to rely on the people who DO have it.
> And if that means things take longer to stable, well, why is that an
> issue?  Stable is supposed to be that - stable.  

That is because you only look for people that have all the hardware.

> > > if you aren't willing to put in the work, don't expect others to.
> > 
> > If you are unwilling to work towards solutions, don't expect others
> > to.
> > 
> > > And yes, I see what you mean now re: my reply seeming off - it
> > > would seem when I hit group reply, for some reason, Evolution is
> > > putting Peter Stuge into the CC, and not Tom Wijsman (despite
> > > hitting group reply from your email.  Maybe there should have
> > > been more testing of Gnome 3.8 before it was stabled on x86...
> > 
> > http://www.unicom.com/pw/reply-to-harmful.html
> > http://woozle.org/~neale/papers/reply-to-still-harmful.html
> > 
> 
> I don't care of "reply to" is considered harmful,

It however caused problems with your e-mail.

> I care that
> something that worked with the previous stable is suddenly not
> working with the new stable.  It obviously shows that it wasn't
> tested properly, and yet was marked stable.

Which is your actual problem that we are trying to solve here.

> So, as QA, shouldn't you be doing something about that, rather than
> pointing to some URLs on the web, telling me I'm in the wrong for
> using the option that is supposed to handle that properly in my
> stable software?

The problem lies in a different place than the software itself.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Fri, 2014-01-24 at 18:26 +0100, Tom Wijsman wrote:
> On Thu, 23 Jan 2014 21:52:47 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > The idea moves the work around, it doesn't lessen the workload at all.
> 
> It is an idea to solve your actual problem, which isn't workload.
> > You can easily find 7 people who have an armv7, and even v6, since the
> > rpi is quite popular.
> 
> They are easier to find than someone that has everything.
> 

The problem isn't finding someone that has everything - we have people
that test on ARMv5, some that test on ARMv6, we have some that test on
ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM.  So
again, it just shuffles around the work, and does nothing to address the
actual problem which is manpower with people that have the slower
machines to finish their testing.  Unless you would like to suggest that
we maybe just say fuck anyone using a slow machine?  I disagree, and
think we should take care of all of our users, not just the bleeding
edge and fast users.


> > Getting them into the arch team and willing to run stable and
> > actually test programs is a whole other story, which lead to you
> > saying:
> > 
> > "People that have certain architectures can just add themselves, no
> > extra work again."
> 
> Which is for people already on the arm arch; consider the context you
> quote this from, rather than assuming what is not explicitly stated.
> 

That doesn't make any sense - if they are already on the arm arch team,
they are already in the list.  That wasn't the context of the quote AT
ALL.  And I told you when you said that it would allow people to add or
remove themselves willy nilly, and that is NOT going to happen - and
would NOT be good for QA.

> > What you've thrown out as a possible solution is akin to taking a pile
> > of peas on the plate and moving them around the plate so that the pile
> > doesn't look so big.  
> 
> In other words, using separation to organize them properly.
> 
> > It doesn't change the amount of work, but you do need to look in more
> > places for the work.
> 
> Which you can collect back into one place.
> 
> > Finding people with the hardware is the main issue, and I think I
> > mentioned before, some people are simply unwilling to invest in
> > "slow" hardware, so we have to rely on the people who DO have it.
> > And if that means things take longer to stable, well, why is that an
> > issue?  Stable is supposed to be that - stable.  
> 
> That is because you only look for people that have all the hardware.
> 

No, we do not look ONLY for people that have all the hardware.  But
until it's tested on all of the arm arches, it doesn't get stabled. So
your suggestion is "split it out to blah blah blah blah" - so that moves
it around - but you know what?  the slower machines are STILL going to
take forever (because they are slow!) and the ebuilds will still need to
stick around, because we will still be waiting.  Problem NOT solved,
problem just moved around a tiny bit.  

> > So, as QA, shouldn't you be doing something about that, rather than
> > pointing to some URLs on the web, telling me I'm in the wrong for
> > using the option that is supposed to handle that properly in my
> > stable software?
> 
> The problem lies in a different place than the software itself.
> 
Spoken like a true QA person.  Glad this is the type of person we have
on our QA team.

This is why everyone makes fun of our QA team, because we allow people
in who don't actually give a shit about QA, only about covering up
issues so they appear good but don't actually fix shit.

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Fri, 24 Jan 2014 10:46:06 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Tom Wijsman wrote:
> > "Steven J. Long" wrote:
> > > What? Without a stable tree, Gentoo is useless afaic.
> > 
> > It moves us closer to upstream releases, a little more bleeding
> > edge; a lot of users and developers run that already, it is found
> > to be useful.
> 
> What? More vague. As are many of your philosophical statements in
> later and prior mails, so I'll ignore those.

It is reality; and thus, without a stable tree, Gentoo is still useful
for a lot of users and developers. What is vague about that?

> > > I don't think that's what was being proposed, though. The
> > > question was really the old complaint about slow architectures;
> > > the "-* arch" solution sounds like the most reasonable definition
> > > of "dropping" keywords, in the absence of AT communication
> > > otherwise.
> > 
> > Dropping keywords and specifying -* are a world apart of each other.
> 
> That's why it's in quotes.

Why is there at all if you intend it to be irrelevant to this thread?

> > The former means that it is not ready for wide stable or testing
> > users, the latter means that it has been tested to not work at all;
> > furthermore, we need to explicitly specify which arches in that
> > case.
> 
> You're missing the point, again. The question was what does "dropping
> keywords" mean, when the maintainer has stabilised a newer version on
> the arch/s s/he has available, but feels that slower archs are holding
> up that process.

Where is that question? 

> I'm slightly at a loss as to why it's such a big deal to just leave
> the old ebuild as-is, given that anyone on a stabled arch should
> upgrade automatically.

It is when you are running the arch that only has the old version.

> But given that the maintainer feels they don't want that old ebuild
> around, and that the arch in question has not got round to testing the
> new one, for whatever reason (it's their call, after all, as to how
> their arch progresses), instead of simply removing that ebuild, or
> bumping it to unstable (which makes zero sense), just leave it stable
> on the slow arch/s in question, and remove the others.

There are situations (security, stability, incompatibility) where
keeping it in place becomes a much harder task; at which point, removal
is bound to happen. At that point, such action is required.

It becomes faster than you think; if you depend on a library, and the
compatible range of that library gets wiped by a security bug, your
package will suddenly depend on an incompatible newer stabilized
version of the library at which point you are up for either a lot of
hard work or plain out starting the progress of masking and removing it.

> This seems like a rarity, but when it's an issue, people get annoyed
> on either side. The solution proposed by the ARM team,

Where is this solution?

> seems like a simple way round, and indicates clearly to anyone
> perusing the ebuild, that a newer version needs stabling on the
> "slow" archs.

Masking works fine for that too; what this does is make clear to the
user that (1) the current stable version has breakage for a specific
reason, (2) a newer stable version is not yet available and (3) that the
user can choose to keep the breakage or upgrade to an unstable version.

> By all means, raise technical objections; just not a philosophical
> one.

Where are these philosophical objections?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Fri, 24 Jan 2014 12:10:30 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> The problem isn't finding someone that has everything - we have people
> that test on ARMv5, some that test on ARMv6, we have some that test on
> ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM.
> So again, it just shuffles around the work, and does nothing to
> address the actual problem which is manpower with people that have
> the slower machines to finish their testing.  Unless you would like
> to suggest that we maybe just say fuck anyone using a slow machine?

Consider how packages would rarely get stabilized if we had to wait for
all arches to test them first before adding any stable keyword at all.

Organize first, then get more manpower; otherwise we say the F-word to
everyone with a faster machine. Joining arm with a slower configuration
and have everyone waiting on you is a working condition to avoid; so,
we could have the slower configuration stabilize at its own pace.

Would we say F-word to 'em? No, we give them better working conditions.

> I disagree, and think we should take care of all of our users, not
> just the bleeding edge and fast users.

Theoretically, yes, everyone wants that; in practice, manpower as well
as performance is limited, which makes "taking care of all" a rather
hard to aim goal.

We still aim to satisfy everyone; I look at discussions from multiple
sides to see how we can satisfy as much people as possible, hence
providing multiple solutions. It however is rare that a solution works
for everyone, there are too much requirements for that to be possible.

But, making it hold up other people's work is a recipe for problems, to
which point someone comes up with a forced stabilization as you gave as
an example. In other words, minor configurations shouldn't stall things
forever; just like minor arches shouldn't stall things forever, which
would have been a huge problem if we would only allow stable keywords
to be added when all the arch teams have tested it.

> > > Getting them into the arch team and willing to run stable and
> > > actually test programs is a whole other story, which lead to you
> > > saying:
> > > 
> > > "People that have certain architectures can just add themselves,
> > > no extra work again."
> > 
> > Which is for people already on the arm arch; consider the context
> > you quote this from, rather than assuming what is not explicitly
> > stated.
> > 
> 
> That doesn't make any sense - if they are already on the arm arch
> team, they are already in the list.

Being on the arm arch team alias, they can add themselves to the
individual configuration teams aliases; as per the context.

> That wasn't the context of the quote AT ALL.

It was:

@TomWij | Why would it result in more emails? When you are part of
multiple aliases you can have it filter down to one; or otherwise, you
can just sort them down to folders and only keep the revelant ones.
@steev  | so we should have armvX aliases?
@steev  | what if you want package X to be stable on only armv5 and
armv7 
@TomWij | Yes, then you just CC those.
@steev  | and those go to the arm alias, or we have to create armvX
aliases, and add people to that - again, more work for me, less work
for you - nothx
@TomWij | steev: People that have certain architectures can just add
themselves, no extra work again.

> And I told you when you
> said that it would allow people to add or remove themselves willy
> nilly, and that is NOT going to happen - and would NOT be good for QA.

You keep bringing up this assumption; it has been made clear multiple
times that so far, like for instance right after you have made it:

@steev  | no.
@steev  | the point of the arch team isn't so people can randomly pop
in, add themselves, do something, then leave the team willy nilly
@TomWij | Indeed, as I said half an hour ago.

Note that this comes right after the previous quote of the context.

And that reference to half an hour ago points to this:

@steev  | TomWij: because people are breaking stable, and if
someone isn't happy with the arch team's speed, they should join the
arch team to help out, and realize just how much work it ACTUALLY is
@steev  | should we allow anyone with an android phone to stable for
arm because they can throw a gentoo chroot onto their phone?
@TomWij | Under the condition proper arch testing is done, thus
according to arm's arch policies; that should be fine to do yes. If you
need it tested on multiple configurations, then I guess the person
could use multiple phones.

> > > What you've thrown out as a possible solution is akin to taking a
> > > pile of peas on the plate and moving them around the plate so
> > > that the pile doesn't look so big.  
> > 
> > In other words, using separation to organize them properly.
> > 
> > > It doesn't change the amount of work, but you do need to look in
> > > more places for the work.
> > 
> > Which you can collect back into one place.
> > 
> > > Finding people with the hardware is the main issue, and I think I
> > > mentioned before, some people are simply unwilling to invest in
> > > "slow" hardware, so we have to rely on the people who DO have it.
> > > And if that means things take longer to stable, well, why is that
> > > an issue?  Stable is supposed to be that - stable.  
> > 
> > That is because you only look for people that have all the hardware.
> > 
> 
> No, we do not look ONLY for people that have all the hardware.  But
> until it's tested on all of the arm arches, it doesn't get stabled. So
> your suggestion is "split it out to blah blah blah blah" - so that
> moves it around - but you know what?  the slower machines are STILL
> going to take forever (because they are slow!) and the ebuilds will
> still need to stick around, because we will still be waiting.
> Problem NOT solved, problem just moved around a tiny bit.  

Your configurations problem would be solved, which is a good start;
so, let us fix actually fix it, instead of covering it up and waiting.

> > > So, as QA, shouldn't you be doing something about that, rather
> > > than pointing to some URLs on the web, telling me I'm in the
> > > wrong for using the option that is supposed to handle that
> > > properly in my stable software?
> > 
> > The problem lies in a different place than the software itself.
> > 
>
> Spoken like a true QA person.  Glad this is the type of person we have
> on our QA team.
> 
> This is why everyone makes fun of our QA team, because we allow people
> in who don't actually give a shit about QA, only about covering up
> issues so they appear good but don't actually fix shit.

Can we talk about the matter instead of about the person?

So, how to fix a problem in software when it is not in the software?

PS: Note that I have been devaway for almost two weeks.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Fri, 2014-01-24 at 20:29 +0100, Tom Wijsman wrote:
> On Fri, 24 Jan 2014 12:10:30 -0600
> Steev Klimaszewski <steev@gentoo.org> wrote:
> 
> > The problem isn't finding someone that has everything - we have people
> > that test on ARMv5, some that test on ARMv6, we have some that test on
> > ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM.
> > So again, it just shuffles around the work, and does nothing to
> > address the actual problem which is manpower with people that have
> > the slower machines to finish their testing.  Unless you would like
> > to suggest that we maybe just say fuck anyone using a slow machine?
> 
> Consider how packages would rarely get stabilized if we had to wait for
> all arches to test them first before adding any stable keyword at all.
> 

Theoretical, again, as always, and not even worth considering because it
doesn't reflect reality.

> Organize first, then get more manpower; otherwise we say the F-word to
> everyone with a faster machine. Joining arm with a slower configuration
> and have everyone waiting on you is a working condition to avoid; so,
> we could have the slower configuration stabilize at its own pace.
> 
> Would we say F-word to 'em? No, we give them better working conditions.
> 

We're all adults here, you can say fuck.  And the entire point of the
emails were that the slow arches were bringing us down, and we need to
zomg stable fastar fastar fastar.  


For the record, the ARM team does just fine in stabling things in a
reasonable amount of time, so no, we aren't going to change our working
methods.  The point of this email thread was we all need to stable
faster, and slower arches need to just become unstable only, and fuck
them.  And I'm saying everyone needs to step back because stabling
things faster and faster doesn't allow for proper testing.

As QA, you should be focusing on making stable, actually stable, not
more bleeding edge.

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Fri, 24 Jan 2014 14:29:02 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> On Fri, 2014-01-24 at 20:29 +0100, Tom Wijsman wrote:
> > On Fri, 24 Jan 2014 12:10:30 -0600
> > Steev Klimaszewski <steev@gentoo.org> wrote:
> > 
> > > The problem isn't finding someone that has everything - we have
> > > people that test on ARMv5, some that test on ARMv6, we have some
> > > that test on ARMv7 - until ALL of them are tested, it doesn't get
> > > stabled on ARM. So again, it just shuffles around the work, and
> > > does nothing to address the actual problem which is manpower with
> > > people that have the slower machines to finish their testing.
> > > Unless you would like to suggest that we maybe just say fuck
> > > anyone using a slow machine?
> > 
> > Consider how packages would rarely get stabilized if we had to wait
> > for all arches to test them first before adding any stable keyword
> > at all.
> > 
> 
> Theoretical, again, as always, and not even worth considering because
> it doesn't reflect reality.

We are talking about reality here, while expanding it on a larger scale;
as to make it more clear how that wouldn't work out well in reality.

> > Organize first, then get more manpower; otherwise we say the F-word
> > to everyone with a faster machine. Joining arm with a slower
> > configuration and have everyone waiting on you is a working
> > condition to avoid; so, we could have the slower configuration
> > stabilize at its own pace.
> > 
> > Would we say F-word to 'em? No, we give them better working
> > conditions.
> > 
> 
> We're all adults here, you can say fuck.

What about better working conditions?

> For the record, the ARM team does just fine in stabling things in a
> reasonable amount of time, so no, we aren't going to change our
> working methods.

That is a contradiction with what you have said earlier.

So, is there an ACTUAL problem with the ARM team or not?

In context, you have demonstrated a result of that problem here:

@steev  | and then you end up with stuff like git is broken on armv7
uclibc
@TomWij | steev: Better to know that than to know that it is broken on
arm uclibc.
@steev  | TomWij: it was known that it's broken, it was stabled anyway,
which makes it worse
@steev  | because i commented and said DO NOT STABLE IT

> The point of this email thread was we all need to stable faster,

That is just a deduction from your point of view; as stated before,
that's a possible deduction you can easily make now. But, deducing it
every time without guaranteeing that the arch teams improve can lead
to it worsening over time; which is something we need to look out for.

> and slower arches need to just become unstable only,

What about slower configurations keeping up slower arches?

> and fuck them.  And I'm saying everyone needs to step back because
> stabling things faster and faster doesn't allow for proper testing.
> 
> As QA, you should be focusing on making stable, actually stable, not
> more bleeding edge.

That's the task of the mentors, recruiters and the arch teams; the QA
team is there to ensure quality, not performance. If performance limits
us from stabilizing everything we want to see stabilized properly, that
means that there is simply a lack of interest; then this thread as well
as QA comes in to reorganize our efforts as well as policy to be more
efficient and effective.

The delays that can be witnessed in the actual problem you have brought
forward is one example of what can be reorganized to not delay
stabilization; another example of what I am working towards is to try
to get more people by making our documents for new developers more
accessible, some examples:

 - Revised
   https://wiki.gentoo.org/index.php?title=Contributing_to_Gentoo&oldid=11534
   to
   https://wiki.gentoo.org/index.php?title=Contributing_to_Gentoo&oldid=83101

 - Added reference in the devmanual to the developer handbook:
   https://github.com/gentoo/devmanual.gentoo.org/commit/ced738e2cf213f7001a4f39cd561983f71631582

 - Start a guide that introduces how to write an ebuild from scratch:
   https://wiki.gentoo.org/wiki/Basic_guide_to_write_Gentoo_Ebuilds

Yes, QA is doing something about that. To take this whole thread a step
further, it is proposed as an agenda topic for the first QA meeting.

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

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

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Tom Wijsman posted on Fri, 24 Jan 2014 19:26:41 +0100 as excerpted:

> On Fri, 24 Jan 2014 10:46:06 +0000 "Steven J. Long"
> <slong@rathaus.eclipse.co.uk> wrote:
> 
>> Tom Wijsman wrote:
>> > "Steven J. Long" wrote:
>> > > What? Without a stable tree, Gentoo is useless afaic.
>> > 
>> > It moves us closer to upstream releases, a little more bleeding edge;
>> > a lot of users and developers run that already, it is found to be
>> > useful.
>> 
>> What? More vague. As are many of your philosophical statements in later
>> and prior mails, so I'll ignore those.
> 
> It is reality; and thus, without a stable tree, Gentoo is still useful
> for a lot of users and developers. What is vague about that?

[TL;DR readers may simply skip this one entirely. =:^) ]

Indeed.  While I recognize that in free software people scratch their own 
itches to a large extent, and thus that for some gentoo devs, they'd not 
be gentoo devs or contributing at all if there wasn't a stable tree for 
them to ultimately contribute to, and thus don't begrudge them all the 
time and effort they spend on stabilizing things, at the same time...

Being a ~arch and sometimes live-build/overlay user since I switched to 
gentoo now a decade ago[1], in part because my previous distro of choice 
(Mandrake) fell three kde releases (3.x.y, so it'd be 90 days behind with 
kde's current monthly micro-release schedule, tho IIRC it was a bit 
slower back then) behind, even for their beta/cooker release...

I've often wondered just how much faster gentoo could move, and how much 
better we could keep up with upstream, if we weren't so focused on 30+day 
outdated stab?l3 bumping all the time.  All that effort... from my 
viewpoint going to waste on something that gentoo really isn't going to 
be that great at anyway, certainly in comparison to other distros which 
REALLY provide a stab?le service, up to a /decade/ outdated, supporting 
often trailing edge software, in an effort to slow down progress for 
people that don't want to move so fast.

There's simply no way gentoo's going to compete well with either the 
commercial enterprise distros like RHEL and SLED/SLES, nor are we going 
to compete well with Debian stable.  That's not gentoo's strength, and 
from a certain viewpoint, any effort sunk into that is simply sunk.  How 
much better could gentoo be for those where the /real/ action is, at 
upstream release or even live-development versions, if all that effort 
wasn't being sunk into useless trailing edge stuff that we never have a 
chance of out-supporting other distros with anyway?

Tho as I said, I realize that FLOSS is very much a scratch your own itch 
thing in many cases, particularly for a community distro such as gentoo, 
and that for a lot of arch-dev folks, if arch-stable wasn't there for 
them to work on, those folks simply wouldn't be working on gentoo at all, 
but on other distros or even out of FLOSS entirely, so it's very much 
*NOT* a zero-sum game, and I can't begrudge them all the work they put 
into making gentoo the best it can be for their particular stable-arch 
itch, either.  So I appreciate that they're there and the work that they 
do, expanding gentoo's practical reach, even if it's not something I'm 
likely to be using or even particularly interested in any time soon.

My point being... yes indeed, there's a LOT of folks for whom gentoo 
without a stable tree would be a gentoo freed of a to-them useless 
weight, allowing gentoo to move even faster, and be even better in areas 
that are already its strength, heavily automated leading edge releases 
and live-development level packages.  And I'm one of those folks!

But that doesn't mean that I consider gentoo's stable tree entirely 
useless, even if in practice it is so for me, because I /do/ recognize 
it's not a zero-sum game -- killing the stable trees wouldn't get us 
/that/ much more work on the leading edge stuff, as most of that present 
contribution would simply go away.  At best, I'd guess we'd get /maybe/ 
20% of it, likely half that.  And we'd shrink as a distro and lose a lot 
of donated services, etc, as well, so what /might/ be a 10% gain in 
leading edge contribution could well actually end up being an overall 
loss, too.

But certainly, in a thought experiment, gentoo without the stable tree 
would be at least as useful as it is now, for some of us, were it not for 
the practical effect I mention above.

---
[1] I remember that I tried with 2004.0, but didn't actually get switched 
until 2004.1, thus... early 2014.... almost exactly a decade ago now, 
depending on whether you count from when I started trying or when I 
finally got a functional and complete install.

-- 
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: rfc: revisiting our stabilization policy

[Peter Stuge]

Duncan wrote:
> My point being... yes indeed, there's a LOT of folks for whom gentoo 
> without a stable tree would be a gentoo freed of a to-them useless 
> weight, allowing gentoo to move even faster, and be even better in areas 
> that are already its strength, heavily automated leading edge releases 
> and live-development level packages.  And I'm one of those folks!

+1


//Peter

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Rich Freeman]

On Fri, Jan 24, 2014 at 11:02 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> I've often wondered just how much faster gentoo could move, and how much
> better we could keep up with upstream, if we weren't so focused on 30+day
> outdated stab?l3 bumping all the time.  All that effort... from my
> viewpoint going to waste on something that gentoo really isn't going to
> be that great at anyway, certainly in comparison to other distros which
> REALLY provide a stab?le service, up to a /decade/ outdated, supporting
> often trailing edge software, in an effort to slow down progress for
> people that don't want to move so fast.

I get what you're saying, and I'm going to use a bit of hyperbole so
don't take this too seriously, but couldn't you just as easily argue
that Gentoo could go much faster if we actually took advantage of the
fact that we DO have a stable tree, and stop being so careful about
not breaking the testing tree?

Honestly, I think both trees represent a pretty decent balance. It is
pretty safe to run ~arch for the packages you really are interested
in, and run stable for the stuff that you don't care so much about,
thus limiting your exposure to problems while getting cutting-edge
where you care for it.

Most of the concern in this thread has been about some minor archs
that struggle to keep up.  It seems like the simplest solution in
these cases is to just have them focus on @system packages for the
stable tree, and let users deal with more breakage outside of that set
(where it isn't super-disruptive).  If you're running a minor arch
chances are that you're happy to have any support at all, since you
sure aren't going to be running Ubuntu...

Rich

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Peter Stuge]

Rich Freeman wrote:
> It seems like the simplest solution in these cases is to just have
> them focus on @system packages for the stable tree, and let users
> deal with more breakage outside of that set

Why not make stable completely optional for arch teams?


//Peter

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Rich Freeman]

On Sat, Jan 25, 2014 at 11:53 PM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>> It seems like the simplest solution in these cases is to just have
>> them focus on @system packages for the stable tree, and let users
>> deal with more breakage outside of that set
>
> Why not make stable completely optional for arch teams?
>

Stable already is completely optional for the arch teams, and that is
why we have concerns over stable requests taking forever on minor
archs in the first place.  If the package wasn't marked as stable in
the first place the maintainer could just drop old versions anytime
they saw fit, but in the cases that cause problems the arch team
exercises their option to stabilize something, and then they also
exercise their option to not stabilize something newer.

Rich

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Peter Stuge]

Rich Freeman wrote:
> > Why not make stable completely optional for arch teams?
> 
> Stable already is completely optional for the arch teams, and that is
> why we have concerns over stable requests taking forever on minor
> archs in the first place.  If the package wasn't marked as stable in
> the first place the maintainer could just drop old versions anytime
> they saw fit, but in the cases that cause problems the arch team
> exercises their option to stabilize something, and then they also
> exercise their option to not stabilize something newer.

Aha, I understand. Thanks!

I don't think that's "completely optional" though, it sounds like a
one-way function. If have ever stabilized a package once then must
ensure a stable package forever.

I think arbitrarily removing stable versions should also be an option,
and I think package managers would be able to deal with that without
much extra effort?

Stabilization is the distribution stretching time of upstream
development. I think it's more healthy for upstream (and thus
also for the distribution) to have the distribution be very thin,
so that users rather interact directly with upstream.

But that's of course not everyone's ideal, and that's fine. :)


//Peter

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Rich Freeman]

On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge <peter@stuge.se> wrote:
>
> I don't think that's "completely optional" though, it sounds like a
> one-way function. If have ever stabilized a package once then must
> ensure a stable package forever.
>
> I think arbitrarily removing stable versions should also be an option,
> and I think package managers would be able to deal with that without
> much extra effort?

Well, I think we certainly should be able to de-stabilize packages.
I've seen this happen in the past, especially when the need to not be
stable is inherent in the package itself (such as game clients that
need to be synchronized with servers - only one version will ever work
at any time buggy or not).

Ideally this should really be the result of communication between the
maintainer and arch team.  What we definitely don't want is a package
that gets stabilized, and then six months later the whole package is
back at ~arch, and then six months later there is a stable version
again, and so on.  That just isn't, well, stable.

However, if an arch team is feeling overwhelmed I'd strongly encourage
them to put out a bulletin telling maintainers to stop STABLEREQs for
non-system packages, or whatever other guidance they want to issue.
It has been pointed out that on these archs system packages often
don't work, so having those be stable at least lets them target
versions they want to fix up and lets users get a bootable system
without too much fuss.  Falling back to a defensible position and all
that...

But, nobody needs anybody's permission to do any of this.  Ideally the
arch team should take the leadership to establish a policy on their
arch which is maintainable.  If they don't do that, well, then
maintainers complain and we get threads like this one.  The arch team
has the greatest interest in having the arch work - I'd strongly
support them in creating any policy for their arch that they can
follow-through on.

Rich

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Rich Freeman posted on Sat, 25 Jan 2014 19:59:19 -0500 as excerpted:

> On Fri, Jan 24, 2014 at 11:02 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> I've often wondered just how much faster gentoo could move, and how
>> much better we could keep up with upstream, if we weren't so focused on
>> 30+day outdated stab?le bumping all the time.  All that effort... from
>> my viewpoint going to waste on something that gentoo really isn't going
>> to be that great at anyway, certainly in comparison to other distros
>> which REALLY provide a stab?le service, up to a /decade/ outdated,
>> supporting often trailing edge software, in an effort to slow down
>> progress for people that don't want to move so fast.
> 
> I get what you're saying, and I'm going to use a bit of hyperbole so
> don't take this too seriously, but couldn't you just as easily argue
> that Gentoo could go much faster if we actually took advantage of the
> fact that we DO have a stable tree, and stop being so careful about not
> breaking the testing tree?

If that was hyperbole it was a bit too subtle for me. =:^)

Actually, I'd support something like this too.  After all, I've already 
stated that on some packages I run from the project overlay and/or the 
live-vcs version.  In a way, that's arguably what testing should /be/, 
tho it'd certainly be a departure from how gentoo handles things now.

Basically in my ideal gentoo, what's now stable would disappear entirely, 
and what's now testing would be the new stable, with what's now hard-
masked and/or only available in the overlays being testing.

But obviously I recognize that's totally broken for a lot of people who 
do depend on gentoo stable, and as such, I don't really consider it an 
entirely practical option... But it'd be nice for me anyway! =:^)

So it's far from hyperbole in my world.  In my world it's the ideal. =:^)

> Honestly, I think both trees represent a pretty decent balance. It is
> pretty safe to run ~arch for the packages you really are interested in,
> and run stable for the stuff that you don't care so much about, thus
> limiting your exposure to problems while getting cutting-edge where you
> care for it.

Except, well, ~arch is if anything safe enough to be stable, and 
unfortunately, isn't always that cutting edge after all.  One has to run 
overlays and hard-unmask live-vcs versions to actually get cutting edge 
testing, which is in my view... unfortunate.

> Most of the concern in this thread has been about some minor archs that
> struggle to keep up.  It seems like the simplest solution in these cases
> is to just have them focus on @system packages for the stable tree, and
> let users deal with more breakage outside of that set (where it isn't
> super-disruptive).  If you're running a minor arch chances are that
> you're happy to have any support at all, since you sure aren't going to
> be running Ubuntu...

Agreed.

Tho AFAIK both Ubuntu and Fedora have an arm variants...  But also AFAIK, 
due to them being binary distros these variants are closer to the sub-arm-
keyword-variants I believe someone else proposed in this thread (??) for 
gentoo/arm as well, consequently leaving other sub-arch-variants that 
gentoo/arm supports out in the cold.

-- 
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: rfc: revisiting our stabilization policy

[Duncan]

Duncan posted on Sun, 26 Jan 2014 22:56:24 +0000 as excerpted:

> Tho AFAIK both Ubuntu and Fedora have an arm variants...

Ugh!  Incomplete editing!  Me ungrammatical caveman!

s/have an arm variants/have arm variants/

-- 
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: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Sun, 2014-01-26 at 16:35 -0500, Rich Freeman wrote:
> On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge <peter@stuge.se> wrote:
> >
> > I don't think that's "completely optional" though, it sounds like a
> > one-way function. If have ever stabilized a package once then must
> > ensure a stable package forever.
> >
> > I think arbitrarily removing stable versions should also be an option,
> > and I think package managers would be able to deal with that without
> > much extra effort?
> 
> Well, I think we certainly should be able to de-stabilize packages.
> I've seen this happen in the past, especially when the need to not be
> stable is inherent in the package itself (such as game clients that
> need to be synchronized with servers - only one version will ever work
> at any time buggy or not).
> 
> Ideally this should really be the result of communication between the
> maintainer and arch team.  What we definitely don't want is a package
> that gets stabilized, and then six months later the whole package is
> back at ~arch, and then six months later there is a stable version
> again, and so on.  That just isn't, well, stable.
> 
> However, if an arch team is feeling overwhelmed I'd strongly encourage
> them to put out a bulletin telling maintainers to stop STABLEREQs for
> non-system packages, or whatever other guidance they want to issue.
> It has been pointed out that on these archs system packages often
> don't work, so having those be stable at least lets them target
> versions they want to fix up and lets users get a bootable system
> without too much fuss.  Falling back to a defensible position and all
> that...
> 

It's not necessarily the STABLEREQs stopping, some of the issues are (at
least on some arches!) that some of the unstable software doesn't quite
work properly anymore, and we are failing at communicating.  And in
those cases, we on the arch teams should definitely be pointing this
out, and filing bugs so that the issues can be sorted.

> But, nobody needs anybody's permission to do any of this.  Ideally the
> arch team should take the leadership to establish a policy on their
> arch which is maintainable.  If they don't do that, well, then
> maintainers complain and we get threads like this one.  The arch team
> has the greatest interest in having the arch work - I'd strongly
> support them in creating any policy for their arch that they can
> follow-through on.
> 
> Rich
> 

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Rich Freeman]

On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski <steev@gentoo.org> wrote:
> It's not necessarily the STABLEREQs stopping, some of the issues are (at
> least on some arches!) that some of the unstable software doesn't quite
> work properly anymore, and we are failing at communicating.  And in
> those cases, we on the arch teams should definitely be pointing this
> out, and filing bugs so that the issues can be sorted.

Well, if the package or some version of it doesn't work at all, you
can always mask it on the arch or drop keywords.  The arch team
doesn't need permission to do this stuff - the keywords and profiles
really "belong" to the arch team, and we just allow maintainers to do
their best job with them to make the job of the arch team easier.

Obviously if you actually want the problem fixed that requires
bugs/etc.  But you don't need a bug to drop a keyword and at least
make it clear that the package doesn't work.

Rich

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Mon, 2014-01-27 at 09:52 -0500, Rich Freeman wrote:
> On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski <steev@gentoo.org> wrote:
> > It's not necessarily the STABLEREQs stopping, some of the issues are (at
> > least on some arches!) that some of the unstable software doesn't quite
> > work properly anymore, and we are failing at communicating.  And in
> > those cases, we on the arch teams should definitely be pointing this
> > out, and filing bugs so that the issues can be sorted.
> 
> Well, if the package or some version of it doesn't work at all, you
> can always mask it on the arch or drop keywords.  The arch team
> doesn't need permission to do this stuff - the keywords and profiles
> really "belong" to the arch team, and we just allow maintainers to do
> their best job with them to make the job of the arch team easier.
> 

Right, but, afaik, an "unstable" ebuild can go away at any point in
time, and then we'd be back in this same place - newer ebuilds are
around, older working ones are gone... 

> Obviously if you actually want the problem fixed that requires
> bugs/etc.  But you don't need a bug to drop a keyword and at least
> make it clear that the package doesn't work.
> 

Right, and this goes as a point towards splitting out the arm keywords,
and maybe I'll bring it up at the next ARM team meeting... I don't think
it would get much traction, but I suppose it wouldn't hurt to at least
throw it out there and see what sticks.

> Rich
> 

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steven J. Long]

Please set your client not to embed people's email addresses in your
responses: it's spambait in web archives. Thanks.

Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > Tom Wijsman wrote:
> > > "Steven J. Long" wrote:
> > > > What? Without a stable tree, Gentoo is useless afaic.
> > > 
> > > It moves us closer to upstream releases, a little more bleeding
> > > edge; a lot of users and developers run that already, it is found
> > > to be useful.
> > 
> > What? More vague. As are many of your philosophical statements in
> > later and prior mails, so I'll ignore those.
> 
> It is reality; and thus, without a stable tree, Gentoo is still useful
> for a lot of users and developers. What is vague about that?

"moves us closer to bleeding-edge" is completely useless; there are
already an immense amount of ways to run more up to date software, or
you wouldn't have users already doing it. That doesn't detract from
the merits of the stabilisation process, which you apparently don't get
despite trumpeting your QA membership.

The latter leaves me rather worried, to be frank.
 
> > > > I don't think that's what was being proposed, though. The
> > > > question was really the old complaint about slow architectures;
> > > > the "-* arch" solution sounds like the most reasonable definition
> > > > of "dropping" keywords, in the absence of AT communication
> > > > otherwise.
> > > 
> > > Dropping keywords and specifying -* are a world apart of each other.
> > 
> > That's why it's in quotes.
> 
> Why is there at all if you intend it to be irrelevant to this thread?

What? OFC it's relevant; it's just not dropping keywords, it's dropping
the ebuild from most archs, and leaving it in-place for those which
haven't stabilised a newer version.

You could have worked that out: in fact I assumed you had since it's
been stated several times. Thanks for the show of "good faith" you
demand from users: always good to have an example to follow.

> > > The former means that it is not ready for wide stable or testing
> > > users, the latter means that it has been tested to not work at all;
> > > furthermore, we need to explicitly specify which arches in that
> > > case.
> > 
> > You're missing the point, again. The question was what does "dropping
> > keywords" mean, when the maintainer has stabilised a newer version on
> > the arch/s s/he has available, but feels that slower archs are holding
> > up that process.
> 
> Where is that question? 

*sigh* Are you really saying you don't understand the point of this
thread? It's yaf "slow archs are slow and i don't want them" complaint,
which recur every year or so, going back at least 10, though we haven't
had this for the last couple of years that I recall; Gentoo has moved
pretty quickly.

It comes up more from openrc, imo, since the upstream maintainer is
also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds
for a core system package. That's an old argument, though, and his call.
I mention it simply because the QA process for that package is squashed,
in comparison to its importance within the framework. Git ebuilds are
not the same as distribution stabilisation.

No, I'm not expecting it to change. I'm just pointing out that it's
very different to the other packages in the tree (being in-house it
hasn't gone through any upstream testing at all, since Gentoo is
effectively the upstream), and a case could be made that in fact its
QA needs better handling, rather than changing policy to the detriment
of archs across the board in response to this complaint.

> > I'm slightly at a loss as to why it's such a big deal to just leave
> > the old ebuild as-is, given that anyone on a stabled arch should
> > upgrade automatically.
> 
> It is when you are running the arch that only has the old version.

FGS that's up the AT and their users to collaborate on them with. It's
not up to some external "developer" to tell the AT which ebuilds are
stable for their arch: that's their *job*. The ebuild dev only gets to
request testing, just like users only get to request a version bump.

> > But given that the maintainer feels they don't want that old ebuild
> > around, and that the arch in question has not got round to testing the
> > new one, for whatever reason (it's their call, after all, as to how
> > their arch progresses), instead of simply removing that ebuild, or
> > bumping it to unstable (which makes zero sense), just leave it stable
> > on the slow arch/s in question, and remove the others.
> 
> There are situations (security, stability, incompatibility) where
> keeping it in place becomes a much harder task; at which point, removal
> is bound to happen. At that point, such action is required.
> 
> It becomes faster than you think; if you depend on a library, and the
> compatible range of that library gets wiped by a security bug, your
> package will suddenly depend on an incompatible newer stabilized
> version of the library at which point you are up for either a lot of
> hard work or plain out starting the progress of masking and removing it.

Security bugs have a separate process, as you know, and reverse dep
checking is a standard thing. No-one said maintaining the tree is easy:
that's why there's so many of you collaborating on it, rather than a team
of 5. Nor that you can't mask ever: just that the standard stabilisation
cycle should not involve you removing the prior stable ebuild on an arch
before a newer version is stabilised.

The latter becomes an issue when someone wants to remove the ebuild, for
whatever reason. If you do find yourself wanting to remove the ebuild,
and it's still not stable, then just remove the keywords on all archs
except the specific slow ones. There must be a bug for stabilisation
already, so note it there, and get on with your life without whinging.
It's not your problem, it's the AT's: let them get on with it without
you messing up their arch with no warning.

If it's a question of who'll field the bug-reports, change the maintainer
if that's possible per-ebuild, or "auto"-reassign.
(eg use a new alias if more than one arch, or the arch alias if only one.)

> > This seems like a rarity, but when it's an issue, people get annoyed
> > on either side. The solution proposed by the ARM team,
> 
> Where is this solution?

What? Pay attention: "-* arch"

> > seems like a simple way round, and indicates clearly to anyone
> > perusing the ebuild, that a newer version needs stabling on the
> > "slow" archs.
> 
> Masking works fine for that too; what this does is make clear to the
> user that (1) the current stable version has breakage for a specific
> reason, (2) a newer stable version is not yet available and (3) that the
> user can choose to keep the breakage or upgrade to an unstable version.

It's more work, and there's no reason for it: "-* arch" is a lot quicker,
simple to do and blindingly obvious as to its intent. Note we are not
talking about "breakage" for security (a separate process and team are in
place for that.) It indicates 1) The arch is lagging on this ebuild and
2) there is a newer ebuild which the maintainer has stabilised on other
archs, so work on that if you want a newer version, and *know that the
work will be much welcomed*, and 3) the user can unmask a newer ebuild
should they wish to (and thus feedback for stabilisation.)

It's much better metadata, easily detectable via script, in the right
place: the ebuild, not a profile mask file somewhere in the stack. If
we agree on it as a mechanism (and I still have not seen why not, for
the case that started this thread and other standard cases) then it's
trivial for portage/pkgcore to flag it in output, leading to better
user feedback and the chance of quicker stabilisation.

> > By all means, raise technical objections; just not a philosophical
> > one.
> 
> Where are these philosophical objections?

All over the shop. "Where is this solution" "Please point out X" instead
of simply reading what is in front of you, along with digression about
the nature of software, the development process and how things could be
considered, but very little practical insight, IMO, resulting in
frustrated responses, as usual.

"Good programming is not learnt from generalities."

Again, what is so wrong with removing keywords for all archs except
the ones which have not caught up and stabilised, instead of removing
the ebuild? (Or indeed forcing people through the whole mask cycle
without good cause.)

It does the same thing, without screwing other archs the maintainer has
no interest in, and package.mask is still an option for trickier cases,
but we're not talking about those, since there are processes in place
for them, and communication is _required_ to sort them out.

For the standard case, where otherwise the maintainer would drop the
ebuild altogether, and thus bork the arch and its users, or be "forced"
to maintain an ebuild, it really does seem like a complete no-brainer.

=
I concur that "QA should be focusing on making stable, actually stable,
not more bleeding edge." That's not a "performance" issue as you put it,
except in management nuspeek. It's the whole bloody point of the distro,
in overarching terms: to test and stabilise robust ebuilds. That process
is what leads to better software, not staying at the "bleeding-edge"
and forgetting about robustness since "a new version is out."

There's plenty of ways to stay on the bleeding-edge; throwing out the
baby with the bathwater will only tip you over it, and bork the distro
for the rest of us, and everyone down the line.

I'm slightly worried as to the composition of the QA team now, where I
wasn't before. "QA comes in to reorganize our efforts as well as policy"
is over-reaching afaic. But a QA team only interested in the
bleeding-edge, or even /thinking/ that losing the stable tree will
improve either quality or the distro? *shudder*

I thought QA was a hard team to get onto, and not because it's a clique,
but because it's central to the mission. Oh well.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Alan McKinnon]

On 28/01/2014 14:37, Steven J. Long wrote:
> I concur that "QA should be focusing on making stable, actually stable,
> not more bleeding edge." That's not a "performance" issue as you put it,
> except in management nuspeek. It's the whole bloody point of the distro,
> in overarching terms: to test and stabilise robust ebuilds. That process
> is what leads to better software, not staying at the "bleeding-edge"
> and forgetting about robustness since "a new version is out."


+1

Nice to see a dev echo my sentiments almost word for word exactly.

9 years later I'm still here, still running Gentoo on all my hosts (over
10 at last count excluding VMs). Why? Because Gentoo
just.works.right.every.single.time, even on ~arch - and that is an
amazing accomplishment for an distro never mind a USE based one.

If I want bleeding edge I'll use funtoo or exherbo or unmask everything
-9999. If I want the latest new! improved! shiny! crap re-implemented
yet again and badly, there's Ubuntu or nightlies from rawhide.

The joy of Gentoo is that it works on just about anything. Stable
well-tested code continues to just work for the most part even on
slacker arches even if the ebuild is years old. When stable is just a
bit too stable for a specific case, we have overlays and
/usr/local/portage/cat/pkg.

This is why Gentoo works so well, because the weird arches still get to
play on the same playground with the other kids. I work at a carrier ISP
and you'd be pleasantly surprised to see just how many gentoo-powered
vendor POC blackboxes come through the office from vendors wanting to
sell their network magic. Business seems to have cottoned onto the idea
that gentoo let's you stop wasting time with make and rather fire off
emerge, doesn't matter what the silicon is.

Slow arches is the price for supporting everything out there. But so
what? If slow_arch_X is stuck on some old version of an @system package,
who cares? It's not like portage will pick it for an amd64 box. An old
ebuild is a file, it sits next to 178,477 files and does no harm, it
only gets used on hardware that needs it.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 28 Jan 2014 12:37:40 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Please set your client not to embed people's email addresses in your
> responses: it's spambait in web archives. Thanks.

It's as much a spambait as it is listed in the From: header on the web
archives; in other words, it are the web archives that need to fix this.

Unless you want to keep spamming this sentence to everyone you talk to;
and/or besides that, wasting your time on changing the quote lines.

> Tom Wijsman wrote:
> "moves us closer to bleeding-edge" is completely useless;

It might be for you; depends, but not completely useless in general.

> there are already an immense amount of ways to run more up to date
> software, or you wouldn't have users already doing it. That doesn't
> detract from the merits of the stabilisation process, which you
> apparently don't get despite trumpeting your QA membership.
> 
> The latter leaves me rather worried, to be frank.

For there to be a stabilization process there need to be people; and
thus, other solutions need to be explored. And thus some of those other
solutions are detracting from the merits of the stabilization process.

> > > > > I don't think that's what was being proposed, though. The
> > > > > question was really the old complaint about slow
> > > > > architectures; the "-* arch" solution sounds like the most
> > > > > reasonable definition of "dropping" keywords, in the absence
> > > > > of AT communication otherwise.
> > > > 
> > > > Dropping keywords and specifying -* are a world apart of each
> > > > other.
> > > 
> > > That's why it's in quotes.
> > 
> > Why is there at all if you intend it to be irrelevant to this
> > thread?
> 
> What? OFC it's relevant; it's just not dropping keywords, it's
> dropping the ebuild from most archs, and leaving it in-place for
> those which haven't stabilised a newer version.

Dropping a keyword or ebuild means removing it; -* is a step further
than that, and thus beyond the scope of this thread. It is there to
indicate the package does not work on that particular architecture, it
is a world apart from just dropping the keyword; hence it is irrelevant.

> > > > The former means that it is not ready for wide stable or testing
> > > > users, the latter means that it has been tested to not work at
> > > > all; furthermore, we need to explicitly specify which arches in
> > > > that case.
> > > 
> > > You're missing the point, again. The question was what does
> > > "dropping keywords" mean, when the maintainer has stabilised a
> > > newer version on the arch/s s/he has available, but feels that
> > > slower archs are holding up that process.
> > 
> > Where is that question? 
> 
> *sigh* Are you really saying you don't understand the point of this
> thread? It's yaf "slow archs are slow and i don't want them"
> complaint, which recur every year or so, going back at least 10,
> though we haven't had this for the last couple of years that I
> recall; Gentoo has moved pretty quickly.
> 
> It comes up more from openrc, imo, since the upstream maintainer is
> also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds
> for a core system package. That's an old argument, though, and his
> call. I mention it simply because the QA process for that package is
> squashed, in comparison to its importance within the framework. Git
> ebuilds are not the same as distribution stabilisation.
> 
> No, I'm not expecting it to change. I'm just pointing out that it's
> very different to the other packages in the tree (being in-house it
> hasn't gone through any upstream testing at all, since Gentoo is
> effectively the upstream), and a case could be made that in fact its
> QA needs better handling, rather than changing policy to the detriment
> of archs across the board in response to this complaint.

So, where is that question?

> > > I'm slightly at a loss as to why it's such a big deal to just
> > > leave the old ebuild as-is, given that anyone on a stabled arch
> > > should upgrade automatically.
> > 
> > It is when you are running the arch that only has the old version.
> 
> FGS that's up the AT and their users to collaborate on them with. It's
> not up to some external "developer" to tell the AT which ebuilds are
> stable for their arch: that's their *job*. The ebuild dev only gets to
> request testing, just like users only get to request a version bump.

Sometimes users get to put it in their overlay because their version
bump, or even a new package request, yields no succes; in the same way,
sometimes there are no people that fill in the *job*, hence we come to
the point of this thread to look into options to change it.

> > > But given that the maintainer feels they don't want that old
> > > ebuild around, and that the arch in question has not got round to
> > > testing the new one, for whatever reason (it's their call, after
> > > all, as to how their arch progresses), instead of simply removing
> > > that ebuild, or bumping it to unstable (which makes zero sense),
> > > just leave it stable on the slow arch/s in question, and remove
> > > the others.
> > 
> > There are situations (security, stability, incompatibility) where
> > keeping it in place becomes a much harder task; at which point,
> > removal is bound to happen. At that point, such action is required.
> > 
> > It becomes faster than you think; if you depend on a library, and
> > the compatible range of that library gets wiped by a security bug,
> > your package will suddenly depend on an incompatible newer
> > stabilized version of the library at which point you are up for
> > either a lot of hard work or plain out starting the progress of
> > masking and removing it.
> 
> Security bugs have a separate process, as you know,

It affects the visibility of the package or its ebuilds.

> and reverse dep checking is a standard thing.

On new stabilizations, yes; those that were around for a long time, no.

> No-one said maintaining the tree is easy: that's why there's so many
> of you collaborating on it, rather than a team of 5. Nor that you
> can't mask ever: just that the standard stabilisation cycle should
> not involve you removing the prior stable ebuild on an arch before a
> newer version is stabilised.
> 
> The latter becomes an issue when someone wants to remove the ebuild,
> for whatever reason. If you do find yourself wanting to remove the
> ebuild, and it's still not stable, then just remove the keywords on
> all archs except the specific slow ones. There must be a bug for
> stabilisation already, so note it there, and get on with your life
> without whinging. It's not your problem, it's the AT's: let them get
> on with it without you messing up their arch with no warning.

An AT problem can quickly become a problem on the distribution level;
if it weren't a problem, we'd not even get bothered or care.

For example, it causes bugs that depend on the stabilization bug to get
blocked; delaying progress of bugs that depend on it. There might be
other reasons listed in the previous thread regarding the minor arches.

> > > This seems like a rarity, but when it's an issue, people get
> > > annoyed on either side. The solution proposed by the ARM team,
> > 
> > Where is this solution?
> 
> What? Pay attention: "-* arch"

It's irrelevant to this thread. So, maybe "arch" was meant instead?

> > > seems like a simple way round, and indicates clearly to anyone
> > > perusing the ebuild, that a newer version needs stabling on the
> > > "slow" archs.
> > 
> > Masking works fine for that too; what this does is make clear to the
> > user that (1) the current stable version has breakage for a specific
> > reason, (2) a newer stable version is not yet available and (3)
> > that the user can choose to keep the breakage or upgrade to an
> > unstable version.
> 
> It's more work, and there's no reason for it: "-* arch" is a lot
> quicker, simple to do and blindingly obvious as to its intent.

But also plain wrong, see above; maybe "arch" is thus meant, but we are
already doing that today. The problem here isn't the other listed
arches, but rather the arch itself; as it blocks progress, see above.

> Note we are not talking about "breakage" for security (a separate
> process and team are in place for that.)

It affects the visibility, as I mentioned before.

> It indicates 1) The arch is lagging on this ebuild and 2) there is a
> newer ebuild which the maintainer has stabilised on other archs, so
> work on that if you want a newer version, and *know that the work
> will be much welcomed*, and 3) the user can unmask a newer ebuild
> should they wish to (and thus feedback for stabilisation.)

3) The newer ebuild is unmasked, this means accepting the keyword?

> It's much better metadata, easily detectable via script, in the right
> place: the ebuild, not a profile mask file somewhere in the stack. If
> we agree on it as a mechanism (and I still have not seen why not, for
> the case that started this thread and other standard cases) then it's
> trivial for portage/pkgcore to flag it in output, leading to better
> user feedback and the chance of quicker stabilisation.

That stack can very well be the profile directory of the arch team,
which is a rather good place for this metadata.

> > > By all means, raise technical objections; just not a philosophical
> > > one.
> > 
> > Where are these philosophical objections?
> 
> All over the shop. "Where is this solution"

If I tell you to "check out my solution"; then which one would that be?

I've given several through-out the thread; if you were to pick one,
that would merely be an assumption. Thus this is an actual question,
rather than something philosophical; it makes the discussion harder if
you refer to matters using generic keywords instead of being specific.

> "Please point out X" instead of simply reading what is in front of
> you

Where did I use this exact wording? It's probably for a good reason to
get something clarified; clarifications are natural in a discussion,
you can't expect other individuals to fully understand each other.

> along with digression about the nature of software, the
> development process and how things could be considered, but very
> little practical insight, IMO, resulting in frustrated responses, as
> usual.

What are you talking about? IMO, this misses reference, as usual.

> Again, what is so wrong with removing keywords for all archs except
> the ones which have not caught up and stabilised, instead of removing
> the ebuild? (Or indeed forcing people through the whole mask cycle
> without good cause.)

Nothing, it is just irrelevant to this thread; it is something we
already do, it doesn't address with the problem put forward in this
thread as well as that it forms no actual solution to the problem here.

> =
> I concur that "QA should be focusing on making stable, actually
> stable, not more bleeding edge." That's not a "performance" issue as
> you put it, except in management nuspeek. It's the whole bloody point
> of the distro, in overarching terms: to test and stabilise robust
> ebuilds. That process is what leads to better software, not staying
> at the "bleeding-edge" and forgetting about robustness since "a new
> version is out."

A process needs people to fulfill it.

> There's plenty of ways to stay on the bleeding-edge; throwing out the
> baby with the bathwater will only tip you over it, and bork the distro
> for the rest of us, and everyone down the line.

Why do we have the baby in the first place?

> I'm slightly worried as to the composition of the QA team now, where I
> wasn't before. "QA comes in to reorganize our efforts as well as
> policy" is over-reaching afaic.

Consider starting a new thread about the role and/or composition of the
QA team if that is a concern.

> But a QA team only interested in the bleeding-edge,

Where is there an implication that we are /only/ interested in that?

> or even /thinking/ that losing the stable tree will improve either
> quality or the distro? *shudder*

Where is there an implication where we think we /should/ lose it?

> I thought QA was a hard team to get onto, and not because it's a
> clique, but because it's central to the mission. Oh well.

s/QA/an arch team/

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

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

On Tue, 28 Jan 2014 14:52:59 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 28/01/2014 14:37, Steven J. Long wrote:
> > I concur that "QA should be focusing on making stable, actually
> > stable, not more bleeding edge." That's not a "performance" issue
> > as you put it, except in management nuspeek. It's the whole bloody
> > point of the distro, in overarching terms: to test and stabilise
> > robust ebuilds. That process is what leads to better software, not
> > staying at the "bleeding-edge" and forgetting about robustness
> > since "a new version is out."
> 
> +1
> 
> Nice to see a dev echo my sentiments almost word for word exactly.
> 
> 9 years later I'm still here, still running Gentoo on all my hosts
> (over 10 at last count excluding VMs). Why? Because Gentoo
> just.works.right.every.single.time, even on ~arch - and that is an
> amazing accomplishment for an distro never mind a USE based one.
> 
> If I want bleeding edge I'll use funtoo or exherbo or unmask
> everything -9999. If I want the latest new! improved! shiny! crap
> re-implemented yet again and badly, there's Ubuntu or nightlies from
> rawhide.

Bleeding edge in this context is ~arch, this is a contradiction.

> The joy of Gentoo is that it works on just about anything. Stable
> well-tested code continues to just work for the most part even on
> slacker arches even if the ebuild is years old. When stable is just a
> bit too stable for a specific case, we have overlays and
> /usr/local/portage/cat/pkg.

Do you mean unstable?

> This is why Gentoo works so well, because the weird arches still get
> to play on the same playground with the other kids. I work at a
> carrier ISP and you'd be pleasantly surprised to see just how many
> gentoo-powered vendor POC blackboxes come through the office from
> vendors wanting to sell their network magic. Business seems to have
> cottoned onto the idea that gentoo let's you stop wasting time with
> make and rather fire off emerge, doesn't matter what the silicon is.

+1 but can you please consider to stay on the topic of this thread?

> Slow arches is the price for supporting everything out there. But so
> what? If slow_arch_X is stuck on some old version of an @system
> package, who cares?

The people whom process gets blocked do.

> It's not like portage will pick it for an amd64 box. An old ebuild is
> a file, it sits next to 178,477 files and does no harm, it only gets
> used on hardware that needs it.

It can harm in the long run, as shown in some of the other sub threads;
generalizations like "does no harm" can very well fit as to what you
perceive when you would try it out, but it doesn't exclude harm overall.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted:

[Seven J. Long wrote...]

>> There's plenty of ways to stay on the bleeding-edge; throwing out the
>> baby with the bathwater will only tip you over it, and bork the distro
>> for the rest of us, and everyone down the line.
> 
> Why do we have the baby in the first place?

IOW, it's not throwing the "baby" out with the bathwater any longer, as 
the "baby" long ago died of old age and is now a decaying corpse; there's 
no "baby" to throw out any longer!

Going with the analogy, that package has become an adult, grown old, got 
sick, died, and now there are rather obvious and smelly signs of decay!  
The neighbors complained (filed bugs) about the smell and when the 
authorities investigated they found the decaying body (the bugs are 
blocked pending removal of a long dead and should be gone version)!

Yet some slow arch is insisting the corpse is not only alive and well, 
but that it's still married to it, and the people coming to try and take 
it away to the morgue aka VCS archives as part of the becoming-a-biohazard 
cleanup (removing the package, thus unblocking those blocked bugs) are 
somehow abusing their authority!

Until the body becomes a biohazard (long dead package presence blocking 
bug resolution), it's arguably the business of the deluded husband still 
refusing to believe the death of his wife, but once it becomes a biohazard 
the rest of the community is now threatened as well and something must be 
done, thus this thread.

[OK, the analogy triggered my imagination and I went with it...]

-- 
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: rfc: revisiting our stabilization policy

[Steev Klimaszewski]

On Wed, 2014-01-29 at 03:15 +0000, Duncan wrote:
> Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted:
> 
> [Seven J. Long wrote...]
> 
> >> There's plenty of ways to stay on the bleeding-edge; throwing out the
> >> baby with the bathwater will only tip you over it, and bork the distro
> >> for the rest of us, and everyone down the line.
> > 
> > Why do we have the baby in the first place?
> 
> IOW, it's not throwing the "baby" out with the bathwater any longer, as 
> the "baby" long ago died of old age and is now a decaying corpse; there's 
> no "baby" to throw out any longer!
> 
> Going with the analogy, that package has become an adult, grown old, got 
> sick, died, and now there are rather obvious and smelly signs of decay!  
> The neighbors complained (filed bugs) about the smell and when the 
> authorities investigated they found the decaying body (the bugs are 
> blocked pending removal of a long dead and should be gone version)!
> 
> Yet some slow arch is insisting the corpse is not only alive and well, 
> but that it's still married to it, and the people coming to try and take 
> it away to the morgue aka VCS archives as part of the becoming-a-biohazard 
> cleanup (removing the package, thus unblocking those blocked bugs) are 
> somehow abusing their authority!
> 
> Until the body becomes a biohazard (long dead package presence blocking 
> bug resolution), it's arguably the business of the deluded husband still 
> refusing to believe the death of his wife, but once it becomes a biohazard 
> the rest of the community is now threatened as well and something must be 
> done, thus this thread.
> 
> [OK, the analogy triggered my imagination and I went with it...]
> 

That got dark rather quickly...

And the problem isn't that it's some dead thing around that no one
wants, at least, no one except the team that it's the ONLY working
version... so we go from having a decrepit but working version to... no
alternative.