[gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sergei Trofimovich]

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

TL;DR;TL;DR:
------------

This email seeks for one step towards less toil tied to gentoo's
keywording/stabilization process. I've CCed a few groups who
might be interested in making this area better:

- gentoo-dev@ as it affects most devs (and non-devs!)
- wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ
  (should I join? :)
- arch-leads@ as it directly helps (or breaks everything for) arch teams
- all individual arches for wider visibility

TL;DR
-----

I see the problem of lagging stable and unstable trees as:

1. lack of automation
2. lack of manpower

The PROPOSAL to solve the '1. automation' part is to draft
a new GLEP. If there is any interest (I assume there is!) I'll start one.
Let's call that fufure 'life of KEYWORDS'. It will cover:

- Update on GLEP-40 ("x86 stabilization can do only x86@ team")
  to allow package maintainers to do ARCH=x86 stabilization.
  It will be an arch-agnostic way: each arch will have minimal requirements
  to setup environment suitable for stabilization and keywording:
  CFLAGS to have, hardware required, whatever else is practical.
- Formalize list of stable arches as such (will be covered by
  'arches.desc' GLEP)
- Formalize what is a "stable arch". In short:
  - arch is marked as such in 'arches.desc'
  - performs most of STABLEREQ/KEYWORDREQ or gives rationale
    why progress can't be easily done before 90-days timeout
- Formalize and automate process of dropping keywords for timed out
  STABLEREQ/KEYWORDREQ requests.
- Automate process of restoring dropped KEYWORDS due to bumps
  adding new unkeyworded dependencies. repoman already complains
  about those. What is left is to grab them in batches time to time
  and handle those as if those were KEYWORDREQ.
- File more automated STABLEREQs to rely less on lazy maintainers
  (I am example of lazy maintainer not siling STABLEREQs enough).
- Formalize which STABLEREQ/KEYWORDREQ can be done automatically
  by arch teams (or maybe anyone else having the hardware!).
  In short: anything not marked as "Runtime testing required"
  on bugzilla and not having any blocker bugs.

The proposal to solve the '2. manpower' part is:
- Write more docs and make stabilisation process easier for everyone.

Important detail: the list is not in set in stone but rather a guideline
of things to cover.

Please feel free to propose other topics, questions, concerns, likes or
any other actionable feedback!

Story mode
----------

Hi all!

As you might suspect arch testing (an important process part of
gentoo's health). Recently arch testing became a point of contentions
among gentoo developers.

The non-exhaustive list of complaints is:

- Minor (usually understaffed) arch ${A} is slow and does not process
  STABLEREQ/KEYWORDREQ packages for many months. Lag forces maintainers
  to keep more old versions in the tree prohibiting removal of not
  really-maintained packages.

  In theory policy allows dropping stable keywords from such packages
  but in practice people frequently do not do it because it's a large
  and tedious tree-wide change.

- Packages on major arch (amd64 or x86) are not stabilized frequently
  enough. Packages fall through the cracks in bugzilla, STABLEREQs don't
  get filed by maintainers.

- <Add your problem here so we can understand and analyze it better>

What are the actual problems?
-----------------------------

- Arch testing is complicated, repetitive and (somethat) unrewarding.

  People only notice when things don't work.

- Arch testing is complicated: each architecture (or OS) has it's own
  quirks.

  It's hard for a developer to join empty arch team as documentation
  on specifics is frequently lacking.

  Some example questions could arise:

  - When keywording for ARCH=ppc64 should we test on both powerpc64 and
    powerpc64le or only one of them?

  - Does -Wl,--as-needed work on ia64?

- There seem to be a little of coordination between arch teams which
  tools to use to handle stabilization pipeline.

  Some examples:

  - Q: How to grab a list for keywording?

    A: use 'getatoms.py' from https://wiki.gentoo.org/wiki/Package_testing#Tools
       but there is a few caveats.

  - Q: How to keyword a package before stabilization?

    A: $ ekeyword ~ia64 <a long-list-of-packages>

    Caveat: can easily drop a keyword from ia64 down to ~ia64 for a
    package or two causing tree breakage.

  - Q: How to mark a package as explicitly not working or an ${arch}?

    A: Use KEYWORDS="-${arch}" but bots and ekeyword ignore it.

  - Q: How to mark a single package version as broken for a particular
       arch?

  - Q: What is the format of commit message for arch commit? Should
       package version be there? Should it be one commit per package?
       Per bug? Per arch?

    A: Everyone does it their own way.

What can we do about it?
------------------------

The short answer is: we need more automation and more manpower.

Both are related: in an ideal world robots would do all package testing
for us. People would only need to add new packages into system.

More detailed plan (actions and changes)
----------------------------------------

The plan is to get feedback from gentoo community and form a new
GLEP that will supersede GLEP-40.

We will need input from many active members: arch teams, wg-stable team
and gentoo devs.

The questions that will be covered in the new GLEP:

1. Q: What is a supported stable arch?

   A: - Arch is marked 'stable' in 'profiles.desc' (and upcoming
        'arches.desc')
      - Arch that has at least one team member willing to do
        STABLEREQ/KEYWORDREQ processing
      - The STABLEREQ/KEYWORDREQ request timeout is 90 days

        After timeout expires all keywords for requested package
        will be demoted. To avoid tedious manual de-keywording we
        will need tooling for that.

2. Q: How to make arch testing faster and easier?

   A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
        required" will be automatically tested and keyworded.

        [handwave] automated tinderbox setup would help a lot
        to now upfront what fails to built, fails tests.

3. Q: How to programmatically get "readiness" status for a particular
      package? Say, how many STABLE-blocking bugs the package has?

   A: Suggestions welcome! Maybe add "package list" field for bugs?

4. Q: How to push more packages into STABLE?

   A: File automatic STABLEREQ bugs more aggressively if no known bugs
      exist for a package version. The rough workflow is the following:

      - Grab a list of candidates for stabilization (will need
        additional tooling)
      - File STABLEREQ against maintainer only first.
      - Maintainer will have a 2-week timeout to either proceed with
        request:
        - add "runtime testing required fields", CC relevant arches to
          start stabilization
        - or set blocking bugs against STABLEREQ to stop stabilization
      - After 2-week timeout tooling automatically CCes arches and
        stabilization happens (ideally with minimal manual work)
      - Profit!

5. Q: <you questions you always wanted to ask>

What do you think of all that?
==============================

Can this proposal make a difference and make gentoo better and easier to
work with?

Does it try to attack the right thing?

Does it completely miss the point?

Does it sound fun?

Please do share your thoughts!

Thank you!

--

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El lun, 24-07-2017 a las 22:22 +0100, Sergei Trofimovich escribió:
> 4. Q: How to push more packages into STABLE?
> 
>    A: File automatic STABLEREQ bugs more aggressively if no known bugs
>       exist for a package version. The rough workflow is the following:
> 
>       - Grab a list of candidates for stabilization (will need
>         additional tooling)
>       - File STABLEREQ against maintainer only first.
>       - Maintainer will have a 2-week timeout to either proceed with
>         request:
>         - add "runtime testing required fields", CC relevant arches to
>           start stabilization
>         - or set blocking bugs against STABLEREQ to stop stabilization
>       - After 2-week timeout tooling automatically CCes arches and
>         stabilization happens (ideally with minimal manual work)
>       - Profit!

I think the tools for this were already developed... but they were relying on
some of us remembering to run them from time to time :/
https://gitweb.gentoo.org/proj/arch-tools.git/tree/file-stabilization-bugs.py
https://gitweb.gentoo.org/proj/arch-tools.git/tree/maintainer-timeout.py
https://gitweb.gentoo.org/proj/arch-tools.git/tree/stabilization-candidates.py

Thanks specially for sharing https://wiki.gentoo.org/wiki/Package_testing#Tools
link, it summarizes all the process really well :O

Also, it seems that tatt-9999 is able to do most of the work... then only thing
that maybe has no official script to get it, for example, what would be the best
way of getting the list of bug numbers that are pending to handle?

For example, if I go to the list manually and pick 10 random bugs, it's ok to
run tatt and copy&paste every bug number but, if the arch queue has 300 pending
bugs. Do we have a way to simply get a plain text with all the bug numbers from
bugzilla interface? Having links per arch pointing to that list of bugs with
arches CCed and sanity-check=+ would be probably helpful ;)

Thanks

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Stuge]

Thank you for working on this.

Sergei Trofimovich wrote:
> Can this proposal make a difference and make gentoo better and
> easier to work with?
> 
> Does it try to attack the right thing?
> 
> Does it completely miss the point?

I hold a perhaps radical view: I would like to simply remove stable.

I continue to feel that maintaining two worlds (stable+unstable)
carries with it an unneccessary cost.

Based solely on how excellently unstable (and similar approaches before
using Gentoo) works for me in practice, I believe that skipping stable
and instead focusing efforts on resolving problems reported in unstable
a little quicker would yield a much better end result - and would net
positive dev time.


> Does it sound fun?

Sorry, no, not to me. It sounds like "double" overhead. :\


I consider dev time a precious resource. Devs should need to do as
few things as possible, to keep things going, and should be able to
immediately reuse as much input from the wider community as possible.

More troubleshooting and fixing "hard" problems, less routine work.


//Peter

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge <peter@stuge.se> wrote:
>
> I hold a perhaps radical view: I would like to simply remove stable.
>
> I continue to feel that maintaining two worlds (stable+unstable)
> carries with it an unneccessary cost.
>

The question is whether devs would start being more conservative with
~arch if it essentially turned into the new stable?

If ~arch doesn't break then we're probably delaying updates too much.
If it does start breaking and we don't have any alternative, we'll
probably start losing users who just can't deal with their systems
breaking.

Personally I'd rather see stable stick around.  If it isn't updated
often that isn't a big deal (to me at least).

-- 
Rich

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

Rich Freeman posted on Mon, 24 Jul 2017 19:52:40 -0400 as excerpted:

> On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge <peter@stuge.se> wrote:
>>
>> I hold a perhaps radical view: I would like to simply remove stable.
>>
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries with it an unneccessary cost.
>>
>>
> The question is whether devs would start being more conservative with
> ~arch if it essentially turned into the new stable?
> 
> If ~arch doesn't break then we're probably delaying updates too much.
> If it does start breaking and we don't have any alternative, we'll
> probably start losing users who just can't deal with their systems
> breaking.
> 
> Personally I'd rather see stable stick around.  If it isn't updated
> often that isn't a big deal (to me at least).

Indeed, while along with Peter I have little personal use for stable 
(~arch is my stable, live-git my unstable, and stale arch, well, stale), 
I've come to realize over the years that there's enough gentooers, both 
users and devs, that do stable, that killing it isn't going to be the 
boon people only looking at all that "wasted" effort might believe it to 
be.

Instead, were gentoo to lose stable, it'd ultimately shrink as both users 
and devs that previously found gentoo stable the most effective 'scratch' 
to their 'configurable stability itch', were forced to look elsewhere to 
scratch that itch.  While there's a small chance it'd be an incremental 
gain for gentoo ~arch, there's a far larger chance it'd be the beginning 
of the end as without stable, the gentoo community could easily shrink 
into unsustainability -- too few people ever considering being users to 
produce enough incoming developers to maintain gentoo ~arch at anything 
close to the level we have now.


OTOH, there may be a case to be made for the implications of Rich's 
suggestion... and mine above.  Arguably just lose the pretense and simply 
rename stable -> stale, and let people that want/need it continue to deal 
with it on those terms.  At least that way gentoo security advisories, 
etc could then be for "gentoo stale", and as such wouldn't look so dated 
when they come out half a year after the upstream public vulnerability 
and patch and/or unaffected release announcements, because that's what it 
took to stabilize the patched version on some platform or other that was 
holding up the glsa.

Automating stabilization and automated keyword dropping on timeouts seems 
the only other practical choice, as unfortunately, "stale" is what we 
have today in practice, if not in name.

So yes, I support the initiative. =:^)

-- 
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] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

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

On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> [snip]
> 
> I consider dev time a precious resource.

If we were to drop stable I would have to start maintaining my own
stable lists to determine what would be ready to into production for my
company. In production "works most of the time" and "good enough"
simply aren't good enough.

I estimate that would at least equal the amount of time I'm currently
spending on Gentoo work, and consequently my contributions to Gentoo
would dwindle to a halt. Most likely I would start looking at other
solutions altogether.

> More troubleshooting and fixing "hard" problems, less routine work.

Except that some of that routine work is actually what I enjoy doing in
Gentoo. I already get plenty of the other two in my day job.

Hans

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

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

On Tue, 2017-07-25 at 04:34 +0000, Duncan wrote:
> 
> Automating stabilization and automated keyword dropping on timeouts
> seems 
> the only other practical choice, as unfortunately, "stale" is what
> we 
> have today in practice, if not in name.

Looking at https://repology.org/statistics stable isn't quite that
stale compared to other distributions. We're not doing great either, so
we should certainly try to improve.

Hans

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Dirkjan Ochtman]

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

On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich <slyfox@gentoo.org>
wrote:

> TL;DR;TL;DR:
> ------------
>
> This email seeks for one step towards less toil tied to gentoo's
> keywording/stabilization process. I've CCed a few groups who
> might be interested in making this area better:
>
> - gentoo-dev@ as it affects most devs (and non-devs!)
> - wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ
>   (should I join? :)
> - arch-leads@ as it directly helps (or breaks everything for) arch teams
> - all individual arches for wider visibility
>

Thanks for kicking off this discussion. As a stable user, this is an
important topic to me.

Your email is kind of long, and I wonder if we can condense the problem
back to simpler first principles.

First, the assumption in our processes seems to be that many or important
bugs will be due to architecture-specific differences, and I wonder if that
assumption really holds up. Do arch testers for a smaller arch often find
problems that were not noticed on one of the larger arches? With the
languages and tools that we have today, it seems like for many of our
packages, bugs due to architectural differences represent a minority of the
problems we found. In this case, the whole idea of per-arch stabilization
does not really make sense, and doing away with that idea could drastically
shortcut our process.

Second, I believe a lot of the value in our stable tree comes *just* from
the requirement that stabilization is only requested after 30 days without
major bugs/changes in the unstable tree. Assuming there are enough users of
a package on unstable, that means important bugs can be shaken out before a
version hits stable. This could mean that potentially, even if we inverted
our entire model to say we "automatically" stabilize after a 30-day period
without major bugs, we hit most of the value of the stable tree with again
drastically reduced pain/work.

Cheers,

Dirkjan

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sergei Trofimovich]

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

On Mon, 24 Jul 2017 23:22:44 +0000
Peter Stuge <peter@stuge.se> wrote:

> Thank you for working on this.
> 
> Sergei Trofimovich wrote:
> > Can this proposal make a difference and make gentoo better and
> > easier to work with?
> > 
> > Does it try to attack the right thing?
> > 
> > Does it completely miss the point?  
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> I continue to feel that maintaining two worlds (stable+unstable)
> carries with it an unneccessary cost.
> 
> Based solely on how excellently unstable (and similar approaches before
> using Gentoo) works for me in practice, I believe that skipping stable
> and instead focusing efforts on resolving problems reported in unstable
> a little quicker would yield a much better end result - and would net
> positive dev time.

Good point.

Stable is used by Gentoo to guard against wide-spread bugs sneaking
into everyone's systems: SIGSEGVing bootloaders (hard to recover),
crashing at startup browsers (hard to find a safe point to rollback),
hosed toolchains (hard to diagnose in time), widespread build breakages
due to incompatible API (or ABI) changes upstream (hard to recover).

It takes time to identify and devise mitigation for new issues. What
would be the mitigation mechanisims for those when we know something
is broken? Currently we say STABLE should work better as packages
there had wider and longer testing.

Why would removing stable speed things up?
Due to smaller amount of bugs to deal with?

Do you think Gentoo needs KEYWORDS at all?

Should packages be tracked as "seemingly working" on the arch
or package.mask is enough?

> > Does it sound fun?  
> 
> Sorry, no, not to me. It sounds like "double" overhead. :\
> 
> 
> I consider dev time a precious resource. Devs should need to do as
> few things as possible, to keep things going, and should be able to
> immediately reuse as much input from the wider community as possible.
> 
> More troubleshooting and fixing "hard" problems, less routine work.

Can you clarify what exactly you see currently as a routine work
on the dev side WRT stable?

Fixing bugs for non-latest packages?
Tracking manually lists for stabilization?
Something else?

Thanks!

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Agostino Sarubbo]

Hello Sergei,

thanks to bring into the topic which nowadays is a common point of discussion 
:)


On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> 1. lack of automation
I'd summarize the techical steps into:
1) get the list of packages
2) test
3) commit to git
4) write on bugzilla

1 is done by getatoms https://github.com/kensington/bugbot
2 is done by the tester in the manner he prefer
3 no official tool available, I used a modified version of 
https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py which is 
still based on CVS
4 no official tool available, I used my own bash script which calls pybugz

So, points 3 and 4 needs to be improved, I have the idea on how the script 
should look, but I have no time to do it and no python knowledge. I can assist 
everyone that candidate itself to make the tool/script like I did with 
kensington when he made getatoms.

> 2. lack of manpower

lack of manpower, so in my opinion reduce a bit the workload. I proposed 
something in one of my last mail to -dev, the following refers to the arches 
with very less manpower:
1) Don't file keywordreq, since noone work on them. File directly stablereq.
2) Reduce the number of the stable packages on those arches
3) Make a more visible list (like this list in term of 
visibility:https://qa-reports.gentoo.org/output/gentoo-ci/output.html) of the 
arches-dependent bugs so that everyone can contribute to maintain alive the 
exotic arches.

-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > [snip]
> > 
> > I consider dev time a precious resource.
> 
> If we were to drop stable I would have to start maintaining my own
> stable lists to determine what would be ready to into production for my
> company. In production "works most of the time" and "good enough"
> simply aren't good enough.
> 
> I estimate that would at least equal the amount of time I'm currently
> spending on Gentoo work, and consequently my contributions to Gentoo
> would dwindle to a halt. Most likely I would start looking at other
> solutions altogether.
> 
> > More troubleshooting and fixing "hard" problems, less routine work.
> 
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of the other two in my day job.
> 
> Hans

If stable goes away I will simply switch to other distribution and retire

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 2:18 AM, Hans de Graaff <graaff@gentoo.org> wrote:
>
> On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
>
> > More troubleshooting and fixing "hard" problems, less routine work.
>
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of the other two in my day job.
>

This goes to a principle of volunteer work - you can't really direct
the work of volunteers (at least not with anything close to 100%
efficiency).  If you tell a volunteer they aren't allowed to work on
x, that doesn't mean that the time they used to spend on x is now
available to the organization to work on higher priority projects.  It
just means that they won't work on x any longer.

If a volunteer wanted to be working on something they considered
higher priority, they would probably already be doing it, or they
would be the ones looking for somebody to take over the lower priority
jobs.

Paid work is an entirely different matter, because the project most
employees are really working on is the "collect a paycheck" project
and what they do to collect it tends to be secondary.  That obviously
isn't 100% the case and if you're trying to retain the next Elon Musk
the rules are different, but it holds for most normal work.

So, don't assume you can fix manpower problems by delivering less.
You might be able to fix them by relaxing rules so that you can
deliver the same with less effort, but keep in mind whether those
rules added some kind of value to the final product.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pacho@gentoo.org> napisał(a):
>El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
>> On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
>> > 
>> > I hold a perhaps radical view: I would like to simply remove
>stable.
>> > 
>> > [snip]
>> > 
>> > I consider dev time a precious resource.
>> 
>> If we were to drop stable I would have to start maintaining my own
>> stable lists to determine what would be ready to into production for
>my
>> company. In production "works most of the time" and "good enough"
>> simply aren't good enough.
>> 
>> I estimate that would at least equal the amount of time I'm currently
>> spending on Gentoo work, and consequently my contributions to Gentoo
>> would dwindle to a halt. Most likely I would start looking at other
>> solutions altogether.
>> 
>> > More troubleshooting and fixing "hard" problems, less routine work.
>> 
>> Except that some of that routine work is actually what I enjoy doing
>in
>> Gentoo. I already get plenty of the other two in my day job.
>> 
>> Hans
>
>If stable goes away I will simply switch to other distribution and
>retire

What's the "over my dead commit access" spirit? 


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pacho@gentoo.org> napisał(a):
> > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
> > > > 
> > > > I hold a perhaps radical view: I would like to simply remove
> > 
> > stable.
> > > > 
> > > > [snip]
> > > > 
> > > > I consider dev time a precious resource.
> > > 
> > > If we were to drop stable I would have to start maintaining my own
> > > stable lists to determine what would be ready to into production for
> > 
> > my
> > > company. In production "works most of the time" and "good enough"
> > > simply aren't good enough.
> > > 
> > > I estimate that would at least equal the amount of time I'm currently
> > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > would dwindle to a halt. Most likely I would start looking at other
> > > solutions altogether.
> > > 
> > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > 
> > > Except that some of that routine work is actually what I enjoy doing
> > 
> > in
> > > Gentoo. I already get plenty of the other two in my day job.
> > > 
> > > Hans
> > 
> > If stable goes away I will simply switch to other distribution and
> > retire
> 
> What's the "over my dead commit access" spirit? 
> 

Jumping from trying to maintain stable tree to arches dead for ages to drop all
stable trees looks to me like a joke promoted by people that has never handled
any stabilization request and saw on them how running a pure "testing" system is
impossible on many conditions. It seems that some people think that if it fits
ok for them, it will fit for all others like we were all using Gentoo for doing
the same.

I could of course deal with things in my personal computer like, for example,
needing to run gcc-6 (current testing) and having tons of packages failing to
build, or run python-3.6 with only a few subset of packages, or running latest
ffmpeg with random packages going to fail with it, or many other issues that
anyone doing some stabilization work would have noticed. But, of course, I
cannot pretend that all the people using Gentoo systems for working or doing
something productive and that for now rely on me for maintaining or helping them
with the issues that could arise, will now be also forced to run systems that
are likely going to break in different and new ways every time they pretend to
update.

I am also really surprised to see how we can jump from some people that were
fighting in the past against we running automatic scripts that already existed
to fill stabilization bug reports and CC arches after timeouts, to a new
situation of "oh, testing tree is good enough for all the people". We will jump
for some people asking for things like doing deeper tests runs for packages
going to stable (at a level that was really unfeasible on a large scale) to a
situation in that nothing (even no compile test) will be checked at all.

Additionally, this will also cause new issues between people that were used to
run "testing" in the way they are running it now and they pushing to unmask
things faster and, others used to "stable", pushing to keep more things hard
masked until they are fixed. It's not the first time that we see that, for
example, a new glibc version is unmasked when maintainer feels it's ready to
allow people to catch the bugs before it going to be stable. If we have no
stable tree, that couldn't be done as we couldn't use "testing" for the purpose
of "lets unmask X package it give it more visibility and let people catch the
bugs". Then, either we keep breaking "testing" even knowing there is no stable,
or we will start getting lots of packages in package.mask leading to new issues
(like those packages having less visibility and fights between people thinking
that a mid breakage is ok and others that not).

Then, in my case it will be as simply as, if Gentoo becomes testing only, I
won't be able to use it for anything productive, only for "playing" with it...
and then, I won't see much sense on staying while I will need to use a different
distribution de facto for the work and any computer that is not the laptop I use
for committing and doing Gentoo dev work.

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> 2. Q: How to make arch testing faster and easier?
> 
>    A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
>         required" will be automatically tested and keyworded.
> 
>         [handwave] automated tinderbox setup would help a lot
>         to now upfront what fails to built, fails tests.

I've had similar thoughts about this and have already been working on
some tooling for this.

We would need to establish exactly what criteria must be met for an
automated test to be considered as successful.

Here's a sample report that my tool produces:
https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html

In this case, would it be enough that it builds and tests pass? What
about the QA issues? Do we need someone to review them to determine if
they should block stabilisation, or if they're even a regression or not?

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> First, the assumption in our processes seems to be that many or
> important bugs will be due to architecture-specific differences, and I
> wonder if that assumption really holds up. Do arch testers for a smaller
> arch often find problems that were not noticed on one of the larger
> arches? With the languages and tools that we have today, it seems like
> for many of our packages, bugs due to architectural differences
> represent a minority of the problems we found. In this case, the whole
> idea of per-arch stabilization does not really make sense, and doing
> away with that idea could drastically shortcut our process.

This would be really interesting to know.

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30 days
> without major bugs/changes in the unstable tree. Assuming there are
> enough users of a package on unstable, that means important bugs can be
> shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs, we
> hit most of the value of the stable tree with again drastically reduced
> pain/work.

The 30 day waiting period is useful for smoking out major upstream bugs,
but can't replace stabilisation integration testing. For example,
package foobar may build fine in ~arch but fails in stable because it
needs a newer libbaz.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

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

On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pacho@gentoo.org> napisał(a):
> > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
> > > > > 
> > > > > I hold a perhaps radical view: I would like to simply remove
> > > 
> > > stable.
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > I consider dev time a precious resource.
> > > > 
> > > > If we were to drop stable I would have to start maintaining my own
> > > > stable lists to determine what would be ready to into production for
> > > 
> > > my
> > > > company. In production "works most of the time" and "good enough"
> > > > simply aren't good enough.
> > > > 
> > > > I estimate that would at least equal the amount of time I'm currently
> > > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > > would dwindle to a halt. Most likely I would start looking at other
> > > > solutions altogether.
> > > > 
> > > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > > 
> > > > Except that some of that routine work is actually what I enjoy doing
> > > 
> > > in
> > > > Gentoo. I already get plenty of the other two in my day job.
> > > > 
> > > > Hans
> > > 
> > > If stable goes away I will simply switch to other distribution and
> > > retire
> > 
> > What's the "over my dead commit access" spirit? 
> > 
> 
> Jumping from trying to maintain stable tree to arches dead for ages to drop all
> stable trees looks to me like a joke promoted by people that has never handled
> any stabilization request and saw on them how running a pure "testing" system is
> impossible on many conditions. It seems that some people think that if it fits
> ok for them, it will fit for all others like we were all using Gentoo for doing
> the same.
> 

I'm sorry, that was supposed to be 'where', not 'what' (stupid
autocompletion!). I simply meant to say that you should have said 'over
my dead commit access' there ;-).


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.
>

I think this is a good reason why everything should be at least
build-tested on a stable tree before getting stabilized.  Now, that
might not be on each arch if it is truly arch-independent (and if
arches keep the dependencies reasonably in sync).

This might be a situation where a compromise could exist.  Have some
kind of flag (in metadata, or maybe the ebuild) that indicates that
the maintainer believes the package is low-risk to stabilize purely on
a build test.  Then after 30 days in testing a tinderbox could
build-test the package and stabilize it automatically.

If the package is considered at-risk then it goes through manual
testing, either by the maintainer or an arch team.

This will also encourage the teams doing testing to actually do more
testing on the packages that would benefit from it.

We wouldn't set hard criteria but leave it up to maintainer
discretion, with a guideline being that past performance is probably a
good predictor of future results.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 15:19 +0200, Michał Górny escribió:
> On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> > El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pacho@gentoo.org>
> > > napisał(a):
> > > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > > On Mon, 2017-07-24 at 23:22 +0000, Peter Stuge wrote:
> > > > > > 
> > > > > > I hold a perhaps radical view: I would like to simply remove
> > > > 
> > > > stable.
> > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > I consider dev time a precious resource.
> > > > > 
> > > > > If we were to drop stable I would have to start maintaining my own
> > > > > stable lists to determine what would be ready to into production for
> > > > 
> > > > my
> > > > > company. In production "works most of the time" and "good enough"
> > > > > simply aren't good enough.
> > > > > 
> > > > > I estimate that would at least equal the amount of time I'm currently
> > > > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > > > would dwindle to a halt. Most likely I would start looking at other
> > > > > solutions altogether.
> > > > > 
> > > > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > > > 
> > > > > Except that some of that routine work is actually what I enjoy doing
> > > > 
> > > > in
> > > > > Gentoo. I already get plenty of the other two in my day job.
> > > > > 
> > > > > Hans
> > > > 
> > > > If stable goes away I will simply switch to other distribution and
> > > > retire
> > > 
> > > What's the "over my dead commit access" spirit? 
> > > 
> > 
> > Jumping from trying to maintain stable tree to arches dead for ages to drop
> > all
> > stable trees looks to me like a joke promoted by people that has never
> > handled
> > any stabilization request and saw on them how running a pure "testing"
> > system is
> > impossible on many conditions. It seems that some people think that if it
> > fits
> > ok for them, it will fit for all others like we were all using Gentoo for
> > doing
> > the same.
> > 
> 
> I'm sorry, that was supposed to be 'where', not 'what' (stupid
> autocompletion!). I simply meant to say that you should have said 'over
> my dead commit access' there ;-).
> 
> 

Ah, no problem. I am also sorry for my quick response to the thread but,
seriously, when I read the suggestion I was like =O

Best regards!

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 22:59 +1000, Michael Palimaka escribió:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> > 
> >    A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> >         required" will be automatically tested and keyworded.
> > 
> >         [handwave] automated tinderbox setup would help a lot
> >         to now upfront what fails to built, fails tests.
> 
> I've had similar thoughts about this and have already been working on
> some tooling for this.
> 
> We would need to establish exactly what criteria must be met for an
> automated test to be considered as successful.
> 
> Here's a sample report that my tool produces:
> https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df01
> 7e14-bd68-47e2-9738-554e7ba1cf10.html
> 
> In this case, would it be enough that it builds and tests pass? What
> about the QA issues?

Personally, I don't feel QA issues as major enough to block a stabilization,
usually they won't cause major issues for stable users and, if they do, for sure
they shouldn't be only QA issues :/

>  Do we need someone to review them to determine if
> they should block stabilisation, or if they're even a regression or not?
> 

Regarding general regressions, that is probably the harder point to handle
automatically. In the past, the scripts in arch-tools.git were avoiding to open
automated stable bug reports for packages having opened bugs (excluding
enhancement and QA bug reports), but that approach is not too good as, for
example, having a bug report asking for a version bump but tagged as "normal"
and not "enhancement" will lead to the bug not being opened :S

Then, I am unsure about if that part can be done automatically :/

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 23:10 +1000, Michael Palimaka escribió:
> On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> > First, the assumption in our processes seems to be that many or
> > important bugs will be due to architecture-specific differences, and I
> > wonder if that assumption really holds up. Do arch testers for a smaller
> > arch often find problems that were not noticed on one of the larger
> > arches? With the languages and tools that we have today, it seems like
> > for many of our packages, bugs due to architectural differences
> > represent a minority of the problems we found. In this case, the whole
> > idea of per-arch stabilization does not really make sense, and doing
> > away with that idea could drastically shortcut our process.
> 
> This would be really interesting to know.

Anyway, I think it depends on the arch you are running. I remember to have seen
specific issues for ia64, hppa, ppc64 or arm. But, for example, I agree that,
*at present time*, I don't remember to have seen a package failing on x86 and
not on amd64 for example (well, I now remember a past systemd upstream runtime
bug that was catched in testing period ;)). 

Then, I guess it depends on each arch. For example, for x86 it could be probably
done if things work on amd64 :/. Between ppc and ppc64 I don't know. For the
others, I don't think that we can extrapolate between amd64 and ia64 for example
(I remember important runtime issues to be catched only affecting ia64 for
example).

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

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

On wto, 2017-07-25 at 22:59 +1000, Michael Palimaka wrote:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> > 
> >    A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> >         required" will be automatically tested and keyworded.
> > 
> >         [handwave] automated tinderbox setup would help a lot
> >         to now upfront what fails to built, fails tests.
> 
> I've had similar thoughts about this and have already been working on
> some tooling for this.
> 
> We would need to establish exactly what criteria must be met for an
> automated test to be considered as successful.
> 
> Here's a sample report that my tool produces:
> https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html
> 
> In this case, would it be enough that it builds and tests pass? What
> about the QA issues? Do we need someone to review them to determine if
> they should block stabilisation, or if they're even a regression or not?
> 

There are different kinds of QA issues and they have different
significance. You can ignore some of them, some others are more
important.

GLEP 65 defines a 'eqatag' function that the checks can use to provide
machine-readable results for the checks. You should work with that
instead of parsing the verbose messages.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

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

Hi,

Before I start replying to specific bits, I think it would be reasonable
to outline the flow of a keywording/stabilization bug. I would split it
into 4 steps:

S1. Someone (anyone) files a bug requesting it.

S2. Someone (maintainer or OP) prepares a complete list of packages
(including dependencies).

S3. The maintainers approve (or reject) the request.

S4. The arch teams process the request.

Now, I think all considerations on automation should be from
the perspective of those steps.


On pon, 2017-07-24 at 22:22 +0100, Sergei Trofimovich wrote:
> TL;DR
> -----
> 
> I see the problem of lagging stable and unstable trees as:
> 
> 1. lack of automation
> 2. lack of manpower
> 
> The PROPOSAL to solve the '1. automation' part is to draft
> a new GLEP. If there is any interest (I assume there is!) I'll start one.
> Let's call that fufure 'life of KEYWORDS'. It will cover:
> 
> - Update on GLEP-40 ("x86 stabilization can do only x86@ team")
>   to allow package maintainers to do ARCH=x86 stabilization.
>   It will be an arch-agnostic way: each arch will have minimal requirements
>   to setup environment suitable for stabilization and keywording:
>   CFLAGS to have, hardware required, whatever else is practical.

I'd dare say arch-specific policies are arch team's business.
The replacement for GLEP 40 should set some base rules but allow arch
teams to override them.

I feel like this is going towards 'anybody can do keywording /
stabilization'. I'd rather not go this route right now, and just let
arch teams recruit people as they see fit.

- Formalize list of stable arches as such (will be covered by
>   'arches.desc' GLEP)
> - Formalize what is a "stable arch". In short:
>   - arch is marked as such in 'arches.desc'
>   - performs most of STABLEREQ/KEYWORDREQ or gives rationale
>     why progress can't be easily done before 90-days timeout

Just to be clear, is this going into your GLEP? I'd prefer if
the 'arches.desc' GLEP was kept purely technical wrt the file format
and not covered policies.

Oh, and when you are doing the new GLEP, don't forget to mention
ALLARCHES.

> 
> - Formalize and automate process of dropping keywords for timed out
>   STABLEREQ/KEYWORDREQ requests.
> - Automate process of restoring dropped KEYWORDS due to bumps
>   adding new unkeyworded dependencies. repoman already complains
>   about those. What is left is to grab them in batches time to time
>   and handle those as if those were KEYWORDREQ.

This might require making more proactive use of '-foo' keywords (QA
tools complain about them right now), or some other way of indicating
'I have tested it and it won't work'. Or at least checking for WONTFIX
bugs.

> - File more automated STABLEREQs to rely less on lazy maintainers
>   (I am example of lazy maintainer not siling STABLEREQs enough).

What I'm a little worried about is that this would proactively try to
stabilize package versions that are not suitable for stabilizations,
e.g. upstream development branch. Without expecting too much guesswork
on the scripting, I'd say it'd be reasonable enough if it checked for
WONTFIX bugs to avoid filing the same rejected bug again.

Those are the solution for S1 and maybe partially S2 in my flow above.
What I'd add for S2:

- make stable bot more proactive on complaining about package lists with
missing dependencies -- right now it waits for arch teams to be CC-ed;
given this might require packages from other maintainers, it'd be better
if it tried investigating earlier (guessing keywords from existing
package if they are not explicitly given in package list).

> - Formalize which STABLEREQ/KEYWORDREQ can be done automatically
>   by arch teams (or maybe anyone else having the hardware!).
>   In short: anything not marked as "Runtime testing required"
>   on bugzilla and not having any blocker bugs.

And that's S4. I'd focus on leaving it for the arch teams to have
a final say but the 'runtime testing required' part is reasonable.


All that said, I think there's one more important part of tooling we're
missing right now: reverse mapping of packages into keywording /
stabilization bugs. In other words, having a package app-foo/bar, I'd
like to know if its keywording or stabilization has been requested
anywhere. In other words, if I should include it in my bug, or just link
to some other bug, or...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Stuge]

Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.

So that's either because of an ebuild bug (incorrect DEPEND) or an
upstream bug (e.g. incorrect PKG_CONFIG_CHECK in configure.ac), right?

It seems to me that waiting (random()=30) days and then testing
against (random()=current-version) libbaz in stable isn't amazing. :)

The ebuild bug could be detected automatically for upstreams using
configure.ac and maybe also cmake.

The upstream bug, well, that's a bit more tricky.


I'll try to write a thoughtful response in the other part of this
thread later. Gotta run now. Thanks everyone for your insights!


//Peter

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 10:13 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> I feel like this is going towards 'anybody can do keywording /
> stabilization'. I'd rather not go this route right now, and just let
> arch teams recruit people as they see fit.
>

I think this depends on the arch team.

Back in the early days of amd64 I was an AT and an early adopter in
general.  There were a lot of bugs with types/etc and broken
assumptions.  It was helpful to have a team that was familiar with the
most common problems and which had the hardware to test things.

Now we never see an amd64-specific issue because that is what all the
upstream projects do their own QA using.  If anything we'd be more
likely to see x86 bugs, but most people have learned how to use types
correctly/etc, and I suspect this has benefited other architectures as
well.

I saw an analogous situation with systemd.  In the early days we were
writing a lot of units.  These days it is just dealing with one-offs
as much of the work is now upstreamed.

I think that the more mainstream something is, the less the need for
specialized teams to deal with every issue.  Sure, somebody could
always escalate a sticky problem, but having an arch team do every
stabilization seems like having the gcc team look at every build
error.

-- 
Rich

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Markus Meier]

On Tue, 25 Jul 2017 11:03:30 +0200
Agostino Sarubbo <ago@gentoo.org> wrote:

> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> > 1. lack of automation  
> I'd summarize the techical steps into:
> 1) get the list of packages
> 2) test
> 3) commit to git
> 4) write on bugzilla
> 
> 1 is done by getatoms https://github.com/kensington/bugbot
> 2 is done by the tester in the manner he prefer
> 3 no official tool available, I used a modified version of 
> https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py
> which is still based on CVS
> 4 no official tool available, I used my own bash script which calls
> pybugz
>
> So, points 3 and 4 needs to be improved, I have the idea on how the
> script should look, but I have no time to do it and no python
> knowledge. I can assist everyone that candidate itself to make the
> tool/script like I did with kensington when he made getatoms.

for 3 and 4 there's the keyword.sh script in my overlay (under scripts)
that has been working for ages (at least for me)...


Regards,
Markus

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 3:45 PM, Markus Meier <maekke@gentoo.org> wrote:
> On Tue, 25 Jul 2017 11:03:30 +0200
> Agostino Sarubbo <ago@gentoo.org> wrote:
>
>> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
>> > 1. lack of automation
>> I'd summarize the techical steps into:
>> 1) get the list of packages
>> 2) test
>> 3) commit to git
>> 4) write on bugzilla
>>
>> 1 is done by getatoms https://github.com/kensington/bugbot
>> 2 is done by the tester in the manner he prefer
>> 3 no official tool available, I used a modified version of
>> https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py
>> which is still based on CVS
>> 4 no official tool available, I used my own bash script which calls
>> pybugz
>>
>> So, points 3 and 4 needs to be improved, I have the idea on how the
>> script should look, but I have no time to do it and no python
>> knowledge. I can assist everyone that candidate itself to make the
>> tool/script like I did with kensington when he made getatoms.
>
> for 3 and 4 there's the keyword.sh script in my overlay (under scripts)
> that has been working for ages (at least for me)...
>

It is a slightly different process, but there is also the situation
where an arch is slow to respond to a stablereq and the maintainer
wishes to drop keywords.

In that case a script is needed which will remove stable keywords on
all reverse deps of the package.

Back when the council approved dropping keywords in these situations
it seemed to be that the effort required to do so was the main barrier
to maintainers taking advantage of the policy.  Awareness might be
another issue, as I don't think it really got documented outside of
the summaries.

-- 
Rich

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Daniel Campbell]

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

On 07/25/2017 06:22 AM, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>>
>> The 30 day waiting period is useful for smoking out major upstream bugs,
>> but can't replace stabilisation integration testing. For example,
>> package foobar may build fine in ~arch but fails in stable because it
>> needs a newer libbaz.
>>
> 
> I think this is a good reason why everything should be at least
> build-tested on a stable tree before getting stabilized.  Now, that
> might not be on each arch if it is truly arch-independent (and if
> arches keep the dependencies reasonably in sync).
> 
> This might be a situation where a compromise could exist.  Have some
> kind of flag (in metadata, or maybe the ebuild) that indicates that
> the maintainer believes the package is low-risk to stabilize purely on
> a build test.  Then after 30 days in testing a tinderbox could
> build-test the package and stabilize it automatically.
> 
> If the package is considered at-risk then it goes through manual
> testing, either by the maintainer or an arch team.
> 
> This will also encourage the teams doing testing to actually do more
> testing on the packages that would benefit from it.
> 
> We wouldn't set hard criteria but leave it up to maintainer
> discretion, with a guideline being that past performance is probably a
> good predictor of future results.
> 
This reads like a practical use of both developer time and machine time.
Build testing at a minimum, imo, is necessary if the word "stable" is
going to mean anything for us. So +1.

Since there are bound to be fewer manually tested packages than
automatic "it builds, ship it" packages, I think it would make a bit
more sense to add a "manually test this please" tag to metadata.xml,
rather than expect auto-stabilizers to have additional tags, which will
outnumber the manual packages and inflate the size of the tree (albeit
slightly).

Since maintainers also manage their packages in various ways, could we
extend this to a general <policy> element? Maintainers can specify how
they'd prefer bugs or commits to be done, and an additional element to
indicate hand-testing. This would solve two problems instead of just
one: indicate a package is ready for auto-stabilization, and give a
single, canonical location for a maintainer to put maintenance policy.

Just my 2¢,

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


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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

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

On Tue, 2017-07-25 at 11:03 +0200, Agostino Sarubbo wrote:
> 
> 1) Don't file keywordreq, since noone work on them. File directly
> stablereq.

This does not make sense to me.

If we want to go this route we should probably state a policy instead
that new dependencies for already keyworded packages automatically get
those keywords as well, even if untested. For packages with stable
keywords this would provide a chance to find issues before the package
is marked stable.

For KEYWORDREQ bugs we could also enlist our users. As a maintainer of
dev-ruby packages I'd be happy to add any keywords based on a "emerge
--info" and "build.log with FEATURES=test" combo added to a KEYWORDREQ
bug. Putting out a call for action and an easy way for users to scan
open KEYWORDREQ bugs for their arch might put a good dent in these.

Hans

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Denis Dupeyron]

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

On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich <slyfox@gentoo.org>
wrote:

> TL;DR;TL;DR:
>
[...]

Here's a data point you may, or may not, find relevant. in 16 years of
using Gentoo exclusively, the only one time I used stable on one machine
for about 2 years it ended up being much more of a pain than unstable.
Actually, I can't say I have anything to complain about unstable. On my
critical machines I snapshot the system subvolume before I update. I can't
remember the last time I had to roll back.

I'm sure most will disagree with me but since you're indirectly asking for
my opinion here it is: I think people working on stable are wasting their
time. But who am I to stop them...

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Thu, Jul 27, 2017 at 7:12 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
>
> Here's a data point you may, or may not, find relevant. in 16 years of using
> Gentoo exclusively, the only one time I used stable on one machine for about
> 2 years it ended up being much more of a pain than unstable. Actually, I
> can't say I have anything to complain about unstable.

When in the last 16 years was this 2 year period of running stable?
The general state of QA has varied quite a bit over that time.

Judging by the open bugs anybody running unstable systemd has been
going through a bit of pain in the last week as various scripts/etc
are updated to handle the change in install location.  Now, it could
have been masked initially, but that is really no different except it
is a different set of guinea pigs.  If unstable never breaks chances
are we aren't actually using it for its intended purpose, not that we
should be deliberately breaking things.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Denis Dupeyron]

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

On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> When in the last 16 years was this 2 year period of running stable?
> The general state of QA has varied quite a bit over that time.
>

I would say 3 or 4 years ago, roughly.


> running unstable systemd has been


Running unstable doesn't mean being stupid.


> If unstable never breaks chances are we aren't actually using it for its
> intended purpose, not that we
> should be deliberately breaking things.


There's this idea that unstable should break. But the initial idea was that
unstable is what should be sent straight to stable, barring the occasional
mistake. Unstable was never meant for ebuilds in development and very much
in flux because of that. That's what package masks are for.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andreas K. Huettel]

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

Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> I continue to feel that maintaining two worlds (stable+unstable)
> carries with it an unneccessary cost.
> 

That's not feasible. It would kill off any semi-professional or professional 
Gentoo use, where a minimum of stability is required. 

(Try keeping ~10 machines on stable running without automation. That's already 
quite some work. Now try the same with ~arch. Now imagine you're talking about 
100 or 1000 machines.)

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Marek Szuba]

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

On 2017-07-28 12:43, Andreas K. Huettel wrote:

>> I continue to feel that maintaining two worlds (stable+unstable) 
>> carries with it an unneccessary cost.
> That's not feasible. It would kill off any semi-professional or
> professional Gentoo use, where a minimum of stability is required.
This. VERY much this. I do not care about having all the latest stuff on
work machines, what I want them is to a) remain up to date
security-wise, and b) actually survive updates. In fact, problems with
the latter was what led us a couple of years ago to quickly conclude
evaluation of a certain other rolling-upgrade operating system.

-- 
MS


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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sam Jorna (wraeth)]

On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
>> 
>> I hold a perhaps radical view: I would like to simply remove stable.
>> 
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries with it an unneccessary cost.
>> 
>
>That's not feasible. It would kill off any semi-professional or
>professional 
>Gentoo use, where a minimum of stability is required. 
>
>(Try keeping ~10 machines on stable running without automation. That's
>already 
>quite some work. Now try the same with ~arch. Now imagine you're
>talking about 
>100 or 1000 machines.)

And further, try proposing that to management - that you'll be managing hosts on a platform that has no "stable" to speak of.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Alec Warner]

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

On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <dilfridge@gentoo.org>
wrote:

> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> >
> > I hold a perhaps radical view: I would like to simply remove stable.
> >
> > I continue to feel that maintaining two worlds (stable+unstable)
> > carries with it an unneccessary cost.
> >
>
> That's not feasible. It would kill off any semi-professional or
> professional
> Gentoo use, where a minimum of stability is required.
>

So my argument (for years) has been that this is the right thing all along.

If people want a stable Gentoo, fork it and maintain it downstream of the
rambunctious rolling distro.


>
> (Try keeping ~10 machines on stable running without automation. That's
> already
> quite some work. Now try the same with ~arch. Now imagine you're talking
> about
> 100 or 1000 machines.)
>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Fri, 28 Jul 2017 23:10:35 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:

> On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> <dilfridge@gentoo.org> wrote:
>
> >That's not feasible. It would kill off any semi-professional or
> >professional 
> >Gentoo use, where a minimum of stability is required. 
> >
> >(Try keeping ~10 machines on stable running without automation.
> >That's already 
> >quite some work. Now try the same with ~arch. Now imagine you're
> >talking about 
> >100 or 1000 machines.)  
> 
> And further, try proposing that to management - that you'll be
> managing hosts on a platform that has no "stable" to speak of.

The professional/management argument is silly. Most avoid Gentoo.
Most companies, want to be able to pay for support. Not to mention
certifications and such for those they hire. None of which Gentoo has
regardless of stability. Not to mention reputation...

Those that tend to run Gentoo have their own interest in such.  I have
seen many migrate from rather than to Gentoo. Large companies, who's
names we would all know. One of the few left is Meetup.com. They run
Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
Sony, etc. Some tend to hire Gentoo devs...

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

Gentoo is as stable as YOU make it!!!!

I have run Gentoo exclusively as well for 14+ years, since ~2003. While
my production servers are all mostly stable, none are 100%. All
production systems have some ~arch packages, usually mine. Development
network and desktops/laptops have always been ~arch. I rarely if ever
have issues. I have long felt and state stability on such a
distro/platform is a misnomer.

If your system is unstable, it could be due to the lack of time you
spent making it stable. With some exceptions. Many time stable is more
unstable and has issues, sometimes fixed in ~arch. ~arch can be more
stable than stable.

That being said having been bit recently by a udev update that wanted a
file from /usr/lib, which I have on lvm, so it broke udev and booting
on ~arch. I reverted back, I did not file a bug.

Maybe the core profile/base system is maintained as stable and not, and
all the rest, packages are not stable or unstable, They are masked or
not. Things like tool chain, and base system should be stable. Beyond
that up to a package maintainer to mask or not. Masking new stuff is
underused.

It seems odd that upstream will release a package. Just for downstream
to consider it not stable. Did it get messed up during packaging? Did
it get messed up by the distro? The whole lag thing does not make sense
for Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
founded, reported back to upstream, etc. Speeds up development. That is
Gentoo's role in FOSS IMHO.

There are other distros if you want rock solid stability all the
way through with minimal effort. Though ever system admin I know has
changed their personal distro a few times due to one issue or another.
Even ones who work for vendors who sell Linux, and they carry 2 laptops.
While I remain on Gentoo, but telling them to avoid Gentoo. Many ran it
before and did not put in the effort. Not why I tell them to avoid.

Gentoo should get back to having the latest of all packages, and
testing integration. It is more a development distro, than mission
critical deployment. That possible and it can be rock solid for
mission critical uses. If the administrators make it such.

Gentoo is as stable as YOU make it!!!!

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[A. Wilcox]

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

On 28/07/17 15:10, William L. Thomson Jr. wrote:
> Gentoo is as stable as YOU make it!!!!

And by "YOU", that would be the people writing ebuilds and committing
them without test suites or integration testing of any kind.  The devs
who yell and complain all day about "standards" and "not breaking the
tree" then go and break the tree and violate any standard ever set.

With the possible exception of mgorny and pacho, I'm not sure if I
have any faith in anyone left in Gentoo.  I knew the political climate
in Gentoo was always yearning for better days, but I could never have
foreseen how bad the technical aspects could become.

This attitude of "the user is to blame" is the reason I moved Adélie's
upstream elsewhere.  I am still running Gentoo on a few production
servers, but this whole thread and /especially/ this message has made
me realise I'm probably better off with Fedora until Adélie is ready.

At least I have a good reason to unsubscribe now.


Farewell,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZe6i2AAoJEMspy1GSK50U9MYP/2RhhrDBTaOa11DE5IC5rkSj
1iDYX8m3hr4kFgbHMTtIf+crYaELnZXr5uR5rFTb56q2vgrTs7xHN802W9a8GJV/
uRH1R/FzT3nZ3X0tS5Yz2wq+H7SICd5WQ8241BrkPyXgXcHy7/s2ubmewKnwoQHv
sdUlA0/XCHItTApItmhOosCxaHcuAhQhbynfbSDKW5gN4dtxrnZq03xzNZL3dazh
j23gNjUEaefLb9NlxbEZIxeOqrBbeaMnKjIMjPbPdV4RUqoQup43fognKJ2TPij3
LnN52HmY/ZLgD8RYQwyBui/WuqV62i/vdi/Iy4uPNDZnOMr1va2Wscj5mawnOXcB
hpOEYrhSNykiGT1hyg1LPZqgjfw8ovAuwNU84An9vVAPkvqVGS0fCGN0W2lCT/oV
o2SYJy2IKhkxTay7R2wklCeKTmXqo1yoQjp/zuGMD/pzAgln2h5Pc/9KjiDSo6pn
mPsHOeWINjHqsUHdPeJAGjMkJaksA/my0tpzWyxkCmpxc/CVNa7HDt0HWWd5KkIO
SFv33Cyj7NYVVs+E6c8+C7BCh7XgIB1DoexicFT9vDR7ThiTNU3PJMoYjxv+t3Tp
Z7mUK19z/TQZNVst396AcujrhvyQC2zLbg03sGwRZR6m2GjlcYLeuIbZL6eS43Mc
Pf2A1DrXM6tr4MMtOQXn
=i0I9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[David Seifert]

On Fri, 2017-07-28 at 15:59 -0400, William L. Thomson Jr. wrote:
> On Fri, 28 Jul 2017 23:10:35 +1000
> "Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
> 
> > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> > <dilfridge@gentoo.org> wrote:
> > 
> > > That's not feasible. It would kill off any semi-professional or
> > > professional 
> > > Gentoo use, where a minimum of stability is required. 
> > > 
> > > (Try keeping ~10 machines on stable running without automation.
> > > That's already 
> > > quite some work. Now try the same with ~arch. Now imagine you're
> > > talking about 
> > > 100 or 1000 machines.)  
> > 
> > And further, try proposing that to management - that you'll be
> > managing hosts on a platform that has no "stable" to speak of.
> 
> The professional/management argument is silly. Most avoid Gentoo.
> Most companies, want to be able to pay for support. Not to mention
> certifications and such for those they hire. None of which Gentoo has
> regardless of stability. Not to mention reputation...
> 
> Those that tend to run Gentoo have their own interest in such.  I
> have
> seen many migrate from rather than to Gentoo. Large companies, who's
> names we would all know. One of the few left is Meetup.com. They run
> Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
> Sony, etc. Some tend to hire Gentoo devs...
> 

Seriously, can you please stop your diatribes. I am so absolutely fed
up by your DoS'ing of the ML with your pointless points.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William Hubbs]

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

On Thu, Jul 27, 2017 at 07:03:25PM -0500, Denis Dupeyron wrote:
> On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
> >
> > When in the last 16 years was this 2 year period of running stable?
> > The general state of QA has varied quite a bit over that time.
> >
> 
> I would say 3 or 4 years ago, roughly.
> 
> 
> > running unstable systemd has been
> 
> 
> Running unstable doesn't mean being stupid.
 
Exactly. If you are running unstable, you are expected to know how to
pick up the pieces if something breaks. Unstable is not meant for
people who aren't comfortable with occasional breakage.

> > If unstable never breaks chances are we aren't actually using it for its
> > intended purpose, not that we
> > should be deliberately breaking things.
> 
> There's this idea that unstable should break. But the initial idea was that
> unstable is what should be sent straight to stable, barring the occasional
> mistake. Unstable was never meant for ebuilds in development and very much
> in flux because of that. That's what package masks are for.

package masks are specifically for things that are known to cause major
system breakages.

Maintainers test things to the best of their
ability before putting them in the tree, but may not cover all possible
test cases, so packages go to the ~arch tree to get much wider coverage
before they are deamed stable. That is why there is a  recommended delay
of 30 days before the package moves to stable.

William


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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Fri, 28 Jul 2017 16:12:26 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 28/07/17 15:10, William L. Thomson Jr. wrote:
> > Gentoo is as stable as YOU make it!!!!  
> 
> And by "YOU", that would be the people writing ebuilds and committing
> them without test suites or integration testing of any kind.  

I am not one of those. I am an outsider. A user, outside ebuilder :)

Having packaged hundreds of Java packages. I do not bother with the
tests. They can take just as long if not longer to get running than the
package itself. I find best testing is real world usage.

>The devs
> who yell and complain all day about "standards" and "not breaking the
> tree" then go and break the tree and violate any standard ever set.

In most any project, breaking the tree/master is frowned on, but
happens. Long as its speedily fixed, all is well.

> This attitude of "the user is to blame" is the reason I moved Adélie's
> upstream elsewhere.  

I did not mean to imply the user was to blame per se. If you buy a car,
do not maintain it, and it falls apart. Is it the manufacturers fault?

Gentoo is not your average "car" or distro. It requires considerable
more work. The result can be better and save considerable time. Yes I
know I just contradicted myself. 

When I was racing, they said
"A fast lap around the track is a slow lap in the cockpit".

The time saving in Gentoo in part is the rolling aspect, and gained
over long periods of time. Upfront you spend considerable time.
The more time spent, the smoother and faster things go.

In part why I tell many not to run it.  They are not going to put in
the time upfront to ensure it works for them in the long run. If the
are not going to put in the time. They likely should not own high end
car, that require abnormal maintenance in ways.

> I am still running Gentoo on a few production
> servers, but this whole thread and /especially/ this message has made
> me realise I'm probably better off with Fedora until Adélie is ready.

For many other distros maybe better suited. There are quite many.
FYI Enlightenment.org runs everything on Gentoo. They have had
discussions of moving away etc. I stay out of it.

What works for one is not the best for other. Gentoo is not the best
distro for everyone. It is really up to each to decide. Gentoo to me is
a Development distro. Which should not be seen the same as many others.

-- 
William L. Thomson Jr.

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

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
excerpted:

> It seems odd that upstream will release a package. Just for downstream
> to consider it not stable. Did it get messed up during packaging? Did it
> get messed up by the distro? The whole lag thing does not make sense for
> Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
> founded, reported back to upstream, etc. Speeds up development. That is
> Gentoo's role in FOSS IMHO.

Not so odd.  Gentoo's arch-stable has a different meaning than upstream's 
stable.  As a long time gentooer I'm surprised you weren't aware of this 
already.

In general (individual packages may differ somewhat on a case-by-case 
basis, one variant being packages where gentoo /is/ upstream and ~arch is 
thus used for upstream unstable testing to some degree)...

Gentoo's stable doesn't really relate to upstream stable except that 
upstream betas and the like (well, short-term ones, not the ones that 
last years without a non-beta release...) aren't normally considered 
stable candidates because they're not released by upstream as such.  
Instead, gentoo's stable means that the packaging -- the ebuild script, 
the eclasses it calls, and the eapi as encoded in pms and deployed by the 
pm -- is considered tested and stable on a particular arch.  Gentoo-
stable also includes proper integration, making sure the header files, 
libs, configuration, documentation, etc, all end up in the place gentooers 
expect them to be, that they build with our particular toolset, etc.

Similarly, upstream-unstable isn't supposed to be a candidate for ~arch 
either, because ~arch is supposed to be upstream stable that simply 
hasn't yet had enough testing of its gentoo packaging and integration in 
ordered for that particular package to be declared stable.

That's one reason why ~arch normally works so well for those prepared to 
manually deal with the occasional packaging or integration hiccup, missed 
or incorrect dependency, failed merge due to conflict with existing files 
because upstream moved something and the package hasn't yet adapted to 
it, etc -- it's releases that upstream has already declared reasonably 
stable, that simply aren't yet sufficiently tested in terms of the gentoo 
packaging and integration, and if a user's willing to deal with the 
occasional hiccup there it should otherwise be as stable as the upstream 
declaration.

Which is why people like me find ~arch quite stable -- it /should/ be for 
us, as it's upstream stable, and we're prepared to deal with the minor 
dependency and integration issues, etc, that the process of gentoo 
stabilization is intended to fix.

The problem this thread is seeking to at least incrementally tweak toward 
the better is that the above only works for people on stable, when people 
actually declare a package stable when there's no serious bugs left after 
the testing period.  Sometimes they forget, packages drop thru the 
cracks, etc, and stable users get further behind than they would be if 
policies were actually being followed.

And perhaps more to the point, on the minor archs which tend to be the 
bottleneck, sometimes there's simply not the resources, either 
sufficiently interested people with the time (who are volunteers after 
all, so interest and time can't be commanded) or arch hardware or both, 
available to do those stabilizations.  The proposal here hopes to 
automate much of the process as well as standardize it, hopefully 
alleviating that bottleneck.

Tho as I've said before, as one who /is/ prepared to deal with the 
occasional packaging or integration issue and thus finds ~arch perfectly 
usable, I'd personally have no problem with dropping stable, it's just 
that I know it to be a practical impossibility, because were we to do so, 
instead of freeing that time to work on what's now ~arch, we'd simply 
lose most of the volunteers who have a major interest in stable.

-- 
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] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Fri, 28 Jul 2017 21:45:57 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
> excerpted:
> 
> > It seems odd that upstream will release a package. Just for
> > downstream to consider it not stable. Did it get messed up during
> > packaging? Did it get messed up by the distro? The whole lag thing
> > does not make sense for Gentoo. Sooner released and tested on
> > Gentoo. Sooner bugs can be founded, reported back to upstream, etc.
> > Speeds up development. That is Gentoo's role in FOSS IMHO.  
> 
> Not so odd.  Gentoo's arch-stable has a different meaning than
> upstream's stable.  As a long time gentooer I'm surprised you weren't
> aware of this already.

If upstream does a new release, fixes bugs. Gentoo marks a previous
release stable. It is stabilizing a package with issues fixed upstream.
That does not make sense. Gentoo issues maybe good, but not upstreams.

I maintained packages like iText which used to have a 30 day release
cycle. Up till recently Jetty was about the same. As a end user, I
needed the bug fixes. Not the delay for it be marked stable.

I stopped running Redhat long ago due to time to vet updates. I run
Gentoo for the speed of being able to package and test out new code.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner <antarus@gentoo.org> wrote:
>
> On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <dilfridge@gentoo.org>
> wrote:
>>
>> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
>> >
>> > I hold a perhaps radical view: I would like to simply remove stable.
>> >
>> > I continue to feel that maintaining two worlds (stable+unstable)
>> > carries with it an unneccessary cost.
>> >
>>
>> That's not feasible. It would kill off any semi-professional or
>> professional
>> Gentoo use, where a minimum of stability is required.
>
>
> So my argument (for years) has been that this is the right thing all along.
>
> If people want a stable Gentoo, fork it and maintain it downstream of the
> rambunctious rolling distro.
>

What is the difference between forking the repository, and just
maintaining a keyword inside the same repository, besides the former
being easier to integrate into QA/etc?

People who are interested in working on stable already do so, and
people who are not for the most part shouldn't be bothered by it.  In
the cases where stable has caused issues with maintainers the council
has generally dropped arches from stable support so that repoman won't
complain when packages are removed.

I won't say that having stable costs us nothing, but I think the cost
is pretty low.  Asking people who want stable to leave isn't going to
make things any better.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Daniel Campbell]

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

On 07/28/2017 12:44 PM, Alec Warner wrote:
> 
> 
> On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel
> <dilfridge@gentoo.org <mailto:dilfridge@gentoo.org>> wrote:
> 
>     Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
>     >
>     > I hold a perhaps radical view: I would like to simply remove stable.
>     >
>     > I continue to feel that maintaining two worlds (stable+unstable)
>     > carries with it an unneccessary cost.
>     >
> 
>     That's not feasible. It would kill off any semi-professional or
>     professional
>     Gentoo use, where a minimum of stability is required.
> 
> 
> So my argument (for years) has been that this is the right thing all along.
> 
> If people want a stable Gentoo, fork it and maintain it downstream of
> the rambunctious rolling distro. 
>  
> 
> 
>     (Try keeping ~10 machines on stable running without automation.
>     That's already
>     quite some work. Now try the same with ~arch. Now imagine you're
>     talking about
>     100 or 1000 machines.)
> 
>     --
>     Andreas K. Hüttel
>     dilfridge@gentoo.org <mailto:dilfridge@gentoo.org>
>     Gentoo Linux developer (council, perl, libreoffice)
> 
> 
Why would we replicate that when Arch has been in that cavalier role for
over a decade? Stability is important to all users; some simply have a
lower tolerance for faults. It also gives us a reliable "product" for
others to rely on or even dogfood. I personally run on ~arch, but if I
were to put a friend on Gentoo, I'd want something that will be pretty
easy-going until they learn the skills to take on ~arch, bug reports, etc.

For many -- especially developers -- stable is only a letter away from
"stale", and that's fine. Some run mixed keywords, or go full ~arch. One
of the core values of Gentoo is choice; why take away the stable choice?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andrew Savchenko]

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

On Thu, 27 Jul 2017 18:12:52 -0500 Denis Dupeyron wrote:
> On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich <slyfox@gentoo.org>
> wrote:
> 
> > TL;DR;TL;DR:
> >
> [...]
> 
> Here's a data point you may, or may not, find relevant. in 16 years of
> using Gentoo exclusively, the only one time I used stable on one machine
> for about 2 years it ended up being much more of a pain than unstable.
> Actually, I can't say I have anything to complain about unstable. On my
> critical machines I snapshot the system subvolume before I update. I can't
> remember the last time I had to roll back.

+1
I do not use stable, even in production. Too few packages, too old
versions, too long time to stabilize newer versions. I'm just OK
with ~arch.

> I'm sure most will disagree with me but since you're indirectly asking for
> my opinion here it is: I think people working on stable are wasting their
> time. But who am I to stop them...

I support stable in my packages, but mostly because I have to. One
of the real benefits from the stable for me is stabilization
process which sometimes uncovers otherwise undetected problems.

Of course there are people who use stable, I respect their opinion;
they have different use cases, practices, experience. So I'm not
asking to abandon stable, just explaining that for me and my cases
it is mostly useless.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andreas K. Huettel]

Am Freitag, 28. Juli 2017, 23:12:26 CEST schrieb A. Wilcox:
> 
> At least I have a good reason to unsubscribe now.
> 
> 
> Farewell,
> --arw
> 

Please don't take William as a typical Gentoo developer. He isn't.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Mart Raudsepp]

> why take away the stable choice?

I think it is rather clear that stable keywords aren't going anywhere
for architectures like amd64. I suggest we drop all of the subthreads
on this topic and get back to other interesting thoughts (which may
include dropping stable for some other arches of course; I mean doing
it for all doesn't deserve e-mails imo).


Mart

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andrew Savchenko]

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

On Fri, 28 Jul 2017 12:44:20 +0200 Andreas K. Huettel wrote:
> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > I continue to feel that maintaining two worlds (stable+unstable)
> > carries with it an unneccessary cost.
> > 
> 
> That's not feasible. It would kill off any semi-professional or professional 
> Gentoo use, where a minimum of stability is required. 
> 
> (Try keeping ~10 machines on stable running without automation. That's already 
> quite some work. Now try the same with ~arch. Now imagine you're talking about 
> 100 or 1000 machines.)
 
~50 hosts here on ~arch. Stable vs unstable is not an issue for
production. The main problem (at least in my case) is upgrade path,
especially with hosts not that often updated.

Upgrade of Gentoo-based production hosts takes considerable time,
not just due to compilation time and issues, but due to the need to
update dozens (sometimes hundreds) of config files properly and
this process can't be fully automated.

Another problem is short support time: only update path for systems
up to one year old is supported more or less. IRL even half year
old system may be PITA for a full update. To make it worse there
are cases when people deliberately make such updates harder: some
developers are refusing to set minimal version requirements for
dependencies if dependency versions below minimal were below latest
stable 1 year age. While such behaviour is within established
policies I frankly do not understand such devs: having
>=cat/foo-1.2.3 instead of cat/foo doesn't hurt, but makes life of
fellow users much easier.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Christopher Head]

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

On Tue, 25 Jul 2017 09:22:08 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30
> days without major bugs/changes in the unstable tree. Assuming there
> are enough users of a package on unstable, that means important bugs
> can be shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs,
> we hit most of the value of the stable tree with again drastically
> reduced pain/work.

I’m a stable user when I can be. I use Gentoo for the configurability,
not for instant access to the newest versions of things.

I think this is a fairly reasonable proposal if stabilization is
otherwise happening too slowly right now. If 30 days with no bugs plus
an automated successful build against an otherwise-stable set of
dependencies led to an automatic stabilization, I’d be fine with that.
Some clarification would be needed on what bugs block stabilization,
and of course there would need to be a flag that maintainers could add
to specific ebuilds to indicate whether or not they’re stabilization
candidates (though I wonder if it would be better to flag the ones that
*aren’t* candidates, rather than the ones that *are*).
-- 
Christopher Head

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[David Seifert]

On Sat, 2017-07-29 at 19:41 +0300, Mart Raudsepp wrote:
> > why take away the stable choice?
> 
> I think it is rather clear that stable keywords aren't going anywhere
> for architectures like amd64. I suggest we drop all of the subthreads
> on this topic and get back to other interesting thoughts (which may
> include dropping stable for some other arches of course; I mean doing
> it for all doesn't deserve e-mails imo).
> 
> 
> Mart
> 

I demand you stop asking for dropping stable for "some other arches",
otherwise I might have to stop arch testing on ppc and sparc.

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Walter Dnes]

On Fri, Jul 28, 2017 at 05:56:25PM -0400, William L. Thomson Jr. wrote

> If upstream does a new release, fixes bugs. Gentoo marks a previous
> release stable. It is stabilizing a package with issues fixed upstream.
> That does not make sense. Gentoo issues maybe good, but not upstreams.
> 
> I maintained packages like iText which used to have a 30 day release
> cycle. Up till recently Jetty was about the same. As a end user, I
> needed the bug fixes. Not the delay for it be marked stable.
> 
> I stopped running Redhat long ago due to time to vet updates. I run
> Gentoo for the speed of being able to package and test out new code.

  What I get out of this discussion is that some people prefer to run
~arch versus stable arch.  I have no problem with that.  But I do object
to dropping "stable" altogether.  I personally run stable with the rare
occasional unstable package, where it's either not available as stable,
or the unstable version fixes a bug in the stable version.  And just for
kicks I'm running gcc 6.3.0.

  It's one thing to rush-stabilize a new package that fixes a security
hole.  But I don't see the point of rush-stabilizing everything "just
because".  I recommend mostly keeping our current setup, with one
change, i.e. allowing security-fix ebuilds to go "stable" immediately.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sam Jorna]

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

On Fri, Jul 28, 2017 at 03:59:36PM -0400, William L. Thomson Jr. wrote:
> On Fri, 28 Jul 2017 23:10:35 +1000
> "Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
> 
> > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> > <dilfridge@gentoo.org> wrote:
> >
> > >That's not feasible. It would kill off any semi-professional or
> > >professional 
> > >Gentoo use, where a minimum of stability is required. 
> > >
> > >(Try keeping ~10 machines on stable running without automation.
> > >That's already 
> > >quite some work. Now try the same with ~arch. Now imagine you're
> > >talking about 
> > >100 or 1000 machines.)  
> > 
> > And further, try proposing that to management - that you'll be
> > managing hosts on a platform that has no "stable" to speak of.
> 
> The professional/management argument is silly. Most avoid Gentoo.
> Most companies, want to be able to pay for support. Not to mention
> certifications and such for those they hire. None of which Gentoo has
> regardless of stability. Not to mention reputation...
> 
> Those that tend to run Gentoo have their own interest in such.  I have
> seen many migrate from rather than to Gentoo. Large companies, who's
> names we would all know. One of the few left is Meetup.com. They run
> Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
> Sony, etc. Some tend to hire Gentoo devs...

Wouldn't it make more sense to make Gentoo *more* attractive to run in
corporate environments, rather than simply saying "We're not RHEL so why
bother"?

People do use Gentoo in production environments, both personally and
professionally, even if it is those that have more investment in doing
so than the average IT Joe. By removing stable, we would be reducing the
potential arguments for the few who do want to use Gentoo in that sort
of environment. We would be becoming more of a niche distro.

"Hey, lets try Gentoo - it's really configurable."
"What's their stable policy? How often does it break?"
"Stable? What's that?"

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Benda Xu]

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

Hi,

Sam Jorna <wraeth@gentoo.org> writes:

> Wouldn't it make more sense to make Gentoo *more* attractive to run in
> corporate environments, rather than simply saying "We're not RHEL so why
> bother"?
>
> People do use Gentoo in production environments, both personally and
> professionally, even if it is those that have more investment in doing
> so than the average IT Joe. By removing stable, we would be reducing the
> potential arguments for the few who do want to use Gentoo in that sort
> of environment. We would be becoming more of a niche distro.
>
> "Hey, lets try Gentoo - it's really configurable."
> "What's their stable policy? How often does it break?"
> "Stable? What's that?"

I agree with Sam.  I see several cases in academia (mainly astrophysics
and particle physics) that Gentoo stable is used and performs well.
Professtional use of Gentoo should be actively supported and even
advocated.

Benda

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Mon, 31 Jul 2017 10:28:31 +1000
Sam Jorna <wraeth@gentoo.org> wrote:
>
> Wouldn't it make more sense to make Gentoo *more* attractive to run in
> corporate environments, rather than simply saying "We're not RHEL so
> why bother"?

No disagreement. That has always been my interest. Though has not been
others. It was in part why I became a trustee. For things like vendor
certified hardware, looking into certifications,  events, and a whole
lot more. But people rather lambast, insult, and stand in the way rather
than either get out of the way or work with me.

It surely could happen without me but has not. I am definitely not
against such happening. But it would require tremendous change and
leadership. Which I do not see ever changing. I wish things were
otherwise.
 
> People do use Gentoo in production environments, both personally and
> professionally, even if it is those that have more investment in doing
> so than the average IT Joe. By removing stable, we would be reducing
> the potential arguments for the few who do want to use Gentoo in that
> sort of environment. We would be becoming more of a niche distro.

Preaching to the choir. That is not why companies I know who ran Gentoo
are leaving or left. One told me they did not want to be in the
operating system business. Stable or not, there are fewer companies
running Gentoo that were before. Due to other reasons that are not
changing, culture, etc.

Companies that run it today I doubt would change if stable went away.
If they left Gentoo, they have many reasons far beyond lack of a stable
branch/tree.

> "Hey, lets try Gentoo - it's really configurable."
> "What's their stable policy? How often does it break?"
> "Stable? What's that?"

How about no foundation. Not even a legal entity. No certifications
from vendors, nor for employees. No one to hire for official support.
There are so many things far beyond anything having to do with a stable
tree or not.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sam Jorna]

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

On Sun, Jul 30, 2017 at 10:44:58PM -0400, William L. Thomson Jr. wrote:
> On Mon, 31 Jul 2017 10:28:31 +1000
> Sam Jorna <wraeth@gentoo.org> wrote:
> >
> > Wouldn't it make more sense to make Gentoo *more* attractive to run in
> > corporate environments, rather than simply saying "We're not RHEL so
> > why bother"?
> 
> No disagreement. That has always been my interest. Though has not been
> others. It was in part why I became a trustee. For things like vendor
> certified hardware, looking into certifications,  events, and a whole
> lot more. But people rather lambast, insult, and stand in the way rather
> than either get out of the way or work with me.
> 
> It surely could happen without me but has not. I am definitely not
> against such happening. But it would require tremendous change and
> leadership. Which I do not see ever changing. I wish things were
> otherwise.
>  
> > People do use Gentoo in production environments, both personally and
> > professionally, even if it is those that have more investment in doing
> > so than the average IT Joe. By removing stable, we would be reducing
> > the potential arguments for the few who do want to use Gentoo in that
> > sort of environment. We would be becoming more of a niche distro.
> 
> Preaching to the choir. That is not why companies I know who ran Gentoo
> are leaving or left. One told me they did not want to be in the
> operating system business. Stable or not, there are fewer companies
> running Gentoo that were before. Due to other reasons that are not
> changing, culture, etc.
> 
> Companies that run it today I doubt would change if stable went away.
> If they left Gentoo, they have many reasons far beyond lack of a stable
> branch/tree.
> 
> > "Hey, lets try Gentoo - it's really configurable."
> > "What's their stable policy? How often does it break?"
> > "Stable? What's that?"
> 
> How about no foundation. Not even a legal entity. No certifications
> from vendors, nor for employees. No one to hire for official support.
> There are so many things far beyond anything having to do with a stable
> tree or not.

Sorry, I thought this thread was about whether to keep or discontinue
the separation between stable and testing branches.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[R0b0t1]

It seems like there has been a lot of discussion here that indicates
people are happy with the way it is. There seems to be differences in
how packages are updated based on their purpose - desktop packages
move very fast, a lot of server infrastructure moves more slowly. It
seems like the "best" solution is already in place for the different
usecases.

If you hadn't noticed this, you may want to go look. I'm not sure if
it's more due to choices made upstream or choices the maintainers
make.


On Sat, Jul 29, 2017 at 1:08 PM, Christopher Head <chead@chead.ca> wrote:
> I’m a stable user when I can be. I use Gentoo for the configurability,
> not for instant access to the newest versions of things.
>

It seems to be understood in this discussion why some people use ~arch
exclusively, but I would like to explain that it is a pattern I have
seen very well myself; typically it's possible to solve bugs by
keywording in the unstable package and being done with it. When
problems related to unstable keywording arise it's usually because a
system isn't completely unstable, which despite the name is very
stable on Gentoo.

It needs to be pointed out that all software in Portage is very new
compared to other distributions. Stable and unstable packages work
well together because they're closer in time to each other than other
distributions respective categories. In fact, stable packages are *so
new* compared to other distributions I think a more constructive
question to ask is whether or not Gentoo should start retaining older
packages for better interoperability with projects whose developers
use non-Gentoo distributions.[1]

On a distribution like Ubuntu or Debian a developer working for a
software firm might wish to use, say, the very latest version of Ruby
and Rails. To do this they might pull down the source release and then
try to compile it themselves. This used to be the same as opening a
portal to dependency hell,[2] but it's gotten better, and we assume
the developer gets it installed to their home directory. They spin up
a website with the new features and are done with it. The rest of
their stack is whatever was in the package manager and might be,
comparatively, very old. If they do this for more pieces of software -
like if it is done on a developer's workstation, and not a single
purpose server - eventually packages will start conflicting and things
like containers and single purpose virtual machines start making
sense.

On Gentoo, the newest software is just there, and it's updated
frequently enough that you never have to jump through breaking
changes. Most people I have met that use Gentoo use it because they
need lots of new software, or need to customize things in ways that
are hard to do on other distributions. These people tend to realize
that even if they run stable, those stable packages would probably be
considered unstable on another distribution.

R0b0t1.


[1] Personally I don't think that would be a useful thing to do, I
just install it in an Ubuntu or Debian VM if I want to play with that
project. A lot of issues that exist in this regard are hardcoded paths
and other things that come from the design of Ubuntu and Debian.

[2] Ubuntu seems to keep their packages more up to date than they used
to, because I remember having to compile 2-3 intermediate packages to
get something to the newest version a couple of times. Debian still
typically has very old software in their package repository.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andreas K. Huettel]

Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson Jr.:
> 
> How about no foundation. Not even a legal entity. No certifications
> from vendors, nor for employees. No one to hire for official support.
> There are so many things far beyond anything having to do with a stable
> tree or not.

I was *this* close to nominaing you for Trustee, until I realized you're not 
even a foundation member...

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Mon, 31 Jul 2017 14:59:25 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson
> Jr.:
> > 
> > How about no foundation. Not even a legal entity. No certifications
> > from vendors, nor for employees. No one to hire for official
> > support. There are so many things far beyond anything having to do
> > with a stable tree or not.  
> 
> I was *this* close to nominaing you for Trustee, until I realized
> you're not even a foundation member...

Wait what? You blocked me from returning as a developer. Based on my
human relation skills, or in your opinion lack there of....
https://bugs.gentoo.org/show_bug.cgi?id=135927#c43

How would you think I be fit for foundation Trustee? Which is a liason
type role, at least with outside entities. That makes  little to no
sense. A developer need technical skills more than personal. A Trustee
needs personal and not so much technical.... Great logic!

It seems that foundation membership been messed up pretty bad. This
seems to be the list of members. Which seems to only be developers.
https://wiki.gentoo.org/wiki/Foundation:Member_List

Per the by laws, one is only removed from membership via voluntary
request, and/or majority vote of the trustees to remove a member.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuation_of_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary_Withdrawal_from_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Termination_from_Membership

I may have requested removal, I seem to recall such. Though I am not
sure others have. Seems the foundation is missing many members. Unless
the trustees voted to remove many others.

Also developers are not automatically added per bylaws. They must
apply for such.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission_of_Members

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[David Seifert]

On Mon, 2017-07-31 at 10:43 -0400, William L. Thomson Jr. wrote:
> On Mon, 31 Jul 2017 14:59:25 +0200
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
> > Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson
> > Jr.:
> > > 
> > > How about no foundation. Not even a legal entity. No
> > > certifications
> > > from vendors, nor for employees. No one to hire for official
> > > support. There are so many things far beyond anything having to
> > > do
> > > with a stable tree or not.  
> > 
> > I was *this* close to nominaing you for Trustee, until I realized
> > you're not even a foundation member...
> 
> Wait what? You blocked me from returning as a developer. Based on my
> human relation skills, or in your opinion lack there of....
> https://bugs.gentoo.org/show_bug.cgi?id=135927#c43
> 
> How would you think I be fit for foundation Trustee? Which is a
> liason
> type role, at least with outside entities. That makes  little to no
> sense. A developer need technical skills more than personal. A
> Trustee
> needs personal and not so much technical.... Great logic!
> 
> It seems that foundation membership been messed up pretty bad. This
> seems to be the list of members. Which seems to only be developers.
> https://wiki.gentoo.org/wiki/Foundation:Member_List
> 
> Per the by laws, one is only removed from membership via voluntary
> request, and/or majority vote of the trustees to remove a member.
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuat
> ion_of_Membership
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary
> _Withdrawal_from_Membership
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Terminati
> on_from_Membership
> 
> I may have requested removal, I seem to recall such. Though I am not
> sure others have. Seems the foundation is missing many members.
> Unless
> the trustees voted to remove many others.
> 
> Also developers are not automatically added per bylaws. They must
> apply for such.
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission
> _of_Members
> 

https://en.wiktionary.org/wiki/sarcasm

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Alec Warner]

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

On Fri, Jul 28, 2017 at 9:05 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner <antarus@gentoo.org> wrote:
> >
> > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <
> dilfridge@gentoo.org>
> > wrote:
> >>
> >> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> >> >
> >> > I hold a perhaps radical view: I would like to simply remove stable.
> >> >
> >> > I continue to feel that maintaining two worlds (stable+unstable)
> >> > carries with it an unneccessary cost.
> >> >
> >>
> >> That's not feasible. It would kill off any semi-professional or
> >> professional
> >> Gentoo use, where a minimum of stability is required.
> >
> >
> > So my argument (for years) has been that this is the right thing all
> along.
> >
> > If people want a stable Gentoo, fork it and maintain it downstream of the
> > rambunctious rolling distro.
> >
>
> What is the difference between forking the repository, and just
> maintaining a keyword inside the same repository, besides the former
> being easier to integrate into QA/etc?
>

> People who are interested in working on stable already do so, and
> people who are not for the most part shouldn't be bothered by it.  In
> the cases where stable has caused issues with maintainers the council
> has generally dropped arches from stable support so that repoman won't
> complain when packages are removed.
>

Sorry, to be clear the conclusion I was hoping to draw is that one has 2
repos instead of 1.

1) Rolling.
2) Stable.

Rolling is typical ~arch Gentoo. People in rolling can do whatever they
want; they can't affect stable at all.

Stable is an entirely separate repo, a fork, where CPVs are pulled from
Rolling into Stable. If Stable wants to keep a gnarly old version of some
package around; great! But the rolling people don't have to care.


>
> I won't say that having stable costs us nothing, but I think the cost
> is pretty low.  Asking people who want stable to leave isn't going to
> make things any better.
>

Nothing stops Gentoo (the organization / community) from housing the above
scheme in one organization. I mean, nothing but political will right? :)

-A


>
> --
> Rich
>
>

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

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

On Mon, 31 Jul 2017 12:56:18 +1000
Sam Jorna <wraeth@gentoo.org> wrote:
> 
> Sorry, I thought this thread was about whether to keep or discontinue
> the separation between stable and testing branches.

Yes and it was others that said lack of stable would effect
enterprise/professional usage. I simply said that argument was moot as
there are other objections beyond not having stable.

Most I know would say Gentoo as a whole is not stable, regardless of
any stable packages, branch, etc. They do not consider Gentoo stable.

FYI, I have always run Gentoo for professional usage. I have a
business. My business has always run Gentoo on all servers, desktops,
workstations etc. Those locally who have worked for me and in my LUG
know this fact. I have also interviewed with many companies in the US
who either did run Gentoo or still do. Thus I have some directly
knowledge on that shrinking market.

Beyond my opinion, gentoo -debian - suse -redhat
https://www.indeed.com/jobs?q=gentoo+-debian+-suse+-redhat&l=

Very few if any are after Gentoo skills. Change that to any other
distro and see the difference. Of course Gentoo is always mentioned
with others, but are they running Gentoo is the question. Seeking
Gentoo skills and companies running Gentoo are not the same.

gentoo
https://www.indeed.com/jobs?q=gentoo+&l=

It is always lumped in with others, rarely by itself.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org> wrote:
>
>
> Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> repos instead of 1.
>
> 1) Rolling.
> 2) Stable.
>
> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> want; they can't affect stable at all.
>
> Stable is an entirely separate repo, a fork, where CPVs are pulled from
> Rolling into Stable. If Stable wants to keep a gnarly old version of some
> package around; great! But the rolling people don't have to care.
>

This seems like it would be fairly painful to maintain.  You'd need to
constantly pull in new packages, and prune out old ones.  It would
duplicate many of the functions maintainers already do.  I doubt
anybody would go to the trouble to make this happen.

>
> Nothing stops Gentoo (the organization / community) from housing the above
> scheme in one organization. I mean, nothing but political will right? :)
>

That, and the fact that it will take a ton of effort to maintain.
Most likely if the tree is split stable will just be abandoned.
Anybody who is unsatisfied with the unstable tree would just quit
entirely, making their unstable packages unmaintained as well.

You need a critical mass to maintain a distro.  IMO having the stable
tree does not add all that much work for those who don't care about
it, but it gets us quite a few contributors.  Maybe we can afford to
lose them, or maybe enough will just move to unstable.  I'm not sure
it is easy to predict what the outcome of removing stable will be.

I'm all for looking for ways to make stable less of a burden on those
who aren't interested in it.  As far as I can tell the main one is not
being able to remove old packages without getting reverse deps
keyworded.  I think that all this would take is a script that would
drop the stable keywords on the reverse deps, which the council has
basically already approved (after a waiting period).

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

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

On pon, 2017-07-31 at 10:52 -0400, Alec Warner wrote:
> On Fri, Jul 28, 2017 at 9:05 PM, Rich Freeman <rich0@gentoo.org> wrote:
> 
> > On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner <antarus@gentoo.org> wrote:
> > > 
> > > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <
> > 
> > dilfridge@gentoo.org>
> > > wrote:
> > > > 
> > > > Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > > > > 
> > > > > I hold a perhaps radical view: I would like to simply remove stable.
> > > > > 
> > > > > I continue to feel that maintaining two worlds (stable+unstable)
> > > > > carries with it an unneccessary cost.
> > > > > 
> > > > 
> > > > That's not feasible. It would kill off any semi-professional or
> > > > professional
> > > > Gentoo use, where a minimum of stability is required.
> > > 
> > > 
> > > So my argument (for years) has been that this is the right thing all
> > 
> > along.
> > > 
> > > If people want a stable Gentoo, fork it and maintain it downstream of the
> > > rambunctious rolling distro.
> > > 
> > 
> > What is the difference between forking the repository, and just
> > maintaining a keyword inside the same repository, besides the former
> > being easier to integrate into QA/etc?
> > 
> > People who are interested in working on stable already do so, and
> > people who are not for the most part shouldn't be bothered by it.  In
> > the cases where stable has caused issues with maintainers the council
> > has generally dropped arches from stable support so that repoman won't
> > complain when packages are removed.
> > 
> 
> Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> repos instead of 1.
> 
> 1) Rolling.
> 2) Stable.
> 
> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> want; they can't affect stable at all.
> 
> Stable is an entirely separate repo, a fork, where CPVs are pulled from
> Rolling into Stable. If Stable wants to keep a gnarly old version of some
> package around; great! But the rolling people don't have to care.

I was considering this but it won't work for users who mix stable
and ~arch. While we don't officially support this, they're a significant
portion of our user base and they usually have good reasons for doing
that.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Volkov]

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

On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org> wrote:
> > Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> > repos instead of 1.
> >
> > 1) Rolling.
> > 2) Stable.
> >
> > Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> > want; they can't affect stable at all.
> >
> > Stable is an entirely separate repo, a fork, where CPVs are pulled from
> > Rolling into Stable. If Stable wants to keep a gnarly old version of some
> > package around; great! But the rolling people don't have to care.
> >
>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt
> anybody would go to the trouble to make this happen.
>

Long time ago releng team did something similar. We defined stable as
tested distribution that has all security updates merged back. From my
experience what made that efforts very tedious was that there were packages
that do not specify minimum required versions for dependencies. Thus we had
to duplicate maintainer's work and check lot's of dependencies again.

Also when we speak about stable tree we first should define what stability
are we talking about? What do we guarantee? ABI/API compatibility or that
it is expected "just work" (whatever this means)?

--
Peter.

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

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org>
> wrote:
>>
>>
>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>> 2 repos instead of 1.
>>
>> 1) Rolling.
>> 2) Stable.
>>
>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
>> want; they can't affect stable at all.
>>
>> Stable is an entirely separate repo, a fork, where CPVs are pulled from
>> Rolling into Stable. If Stable wants to keep a gnarly old version of
>> some package around; great! But the rolling people don't have to care.
>>
>>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt anybody
> would go to the trouble to make this happen.

FWIW, the gentoo/kde team effectively do this right now, tho only with kde 
packages and some of their deps, and it's live/prerelease/release-staging 
vs ~arch/stable, not ~arch vs stable.  But the amount of work is surely 
similar, and they've been doing it now for a number of years and over a 
major kde version bump, an upstream svn/git upgrade and general upstream 
remodularization.

They seem to have the method and routine /down/, and I'm sure many of the 
lessons they've learned could be used were such a main repo split to be 
undertaken, but I honestly have no idea whether they'd consider the 
effort huge or "painful to maintain", only that they do it -- pretty **** 
effectively if I might add from my own consumption of both the main tree 
and kde overlay.

And to address the concern over users with mixed ~arch/stable usage, as a 
user effectively doing it but with mixed ~arch-main/live-kde usage, the 
trouble of having to pull and update from both trees, managing masks, 
etc, isn't actually that bad at all, particularly given the fact that the 
main mask/unmask sets are maintained (automatically via project script) 
in the kde repo so all I have to do is symlink appropriately and add an 
occasionally temporarily overlooked one to my local exception file.


For gentoo/kde it would seem to have been worth it, but you'd have to ask 
them if it's "painful" for them.

So it's certainly doable, maintainable over years and major changes, and 
consumable, as gentoo/kde devs and their users have been and continues to 
demonstrate. =:^)  The /big/ question then is only whether that model's 
actually a good fit for the wider gentoo culture, and I still have my 
doubts on that one.

-- 
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] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>
>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org>
>> wrote:
>>>
>>>
>>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>>> 2 repos instead of 1.
>>>
>>> 1) Rolling.
>>> 2) Stable.
>>>
>>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
>>> want; they can't affect stable at all.
>>>
>>> Stable is an entirely separate repo, a fork, where CPVs are pulled from
>>> Rolling into Stable. If Stable wants to keep a gnarly old version of
>>> some package around; great! But the rolling people don't have to care.
>>>
>>>
>> This seems like it would be fairly painful to maintain.  You'd need to
>> constantly pull in new packages, and prune out old ones.  It would
>> duplicate many of the functions maintainers already do.  I doubt anybody
>> would go to the trouble to make this happen.
>
> FWIW, the gentoo/kde team effectively do this right now, tho only with kde
> packages and some of their deps, and it's live/prerelease/release-staging
> vs ~arch/stable, not ~arch vs stable.  But the amount of work is surely
> similar, and they've been doing it now for a number of years and over a
> major kde version bump, an upstream svn/git upgrade and general upstream
> remodularization.
>

The difficulty isn't in moving the ebuilds around.

The difficulty is in knowing WHICH ebuilds to move around.

In the case of KDE it is the maintainers doing the maintaining, so
they already understand which versions should move.  They've all been
tested, so I suspect it is likely a lift and place of the entire
thing.

In the proposed multi-repository approach the maintainers would not be
the ones doing the moving.

Now, I guess you could have a snapshot/release-based approach.  Take a
snapshot of the ENTIRE ~arch tree.  Then do whatever level of QA, and
after a delay move the ENTIRE ~arch tree to stable.  The problem with
this is that you'll probably pick that oddball version of some package
that is about to be replaced and isn't a good stable candidate, and so
on.  It also would be difficult to actually test it all.

And if you're going to get the maintainers to move all their own
stuff, then you're just giving them extra work compared to just using
the KEYWORDS variable.

In the current state the maintainer is at the heart of the
stabilization process, so the person who already needs to understand
the individual package is the one deciding which versions go stable.
Duplicating this level of knowledge would not be straightforward.

-- 
Rich

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

Rich Freeman posted on Mon, 31 Jul 2017 20:55:05 -0400 as excerpted:

> On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>>
>>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org>
>>> wrote:
>>>>
>>>> [T]he conclusion I was hoping to draw is that one
>>>> has 2 repos instead of 1.
>>>>
>>>> 1) Rolling.
>>>> 2) Stable.
>>>>
>>> This seems like it would be fairly painful to maintain.
>>
>> FWIW, the gentoo/kde team effectively do this right now
>>
> The difficulty isn't in moving the ebuilds around.
> 
> The difficulty is in knowing WHICH ebuilds to move around.
> 
> In the case of KDE it is the maintainers doing the maintaining,

Very good point.  Thanks.

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