[gentoo-dev] Improving the support for minor arches and less common profiles in CI

[gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Michał Górny]

Hi, everyone.

I think most of us agree that support for minor arches in Gentoo
is suboptimal, and that we've pretty much been focusing on avoiding
the problem than really solving it.


At this moment, we have 8 arches with stable profiles:
  alpha amd64 arm hppa ia64 ppc ppc64 x86

We have 8 arches whose profiles are purely dev/exp:
  arm64 m68k mips nios2 riscv s390 sh sparc

We also have dev/exp *-fbsd and prefix profiles.

Of those arches:

a. mips, *-fbsd and prefix use ~arch only,

b. arm64 and sparc have reasonably supported stable tree (the former
aiming to become stable profile, the latter recently lost the status),

c. other minor arches have stable keywords added haphazardly.


The main problems I see are:

1. The most of mainline tooling (repoman, CI, stable-bot) default to
ignoring non-stable profiles because of the inconsistencies
in dependency tree of those profiles. Sadly, this means that developers
keep making it worse by missing new breakages they're introducing. This
gives us an awful chicken-and-egg problem.

2. The meanings of 'dev' and 'exp' are really unclear to me. I'm not
really sure if anyone follows a really clear criteria in classifying
profiles to either.

3. We can't really expect to get all profiles of given type (dev or exp)
to start passing at the same time.


What I would really like to achieve is improvement of dependency tree
consistency across different profiles. Ideally, we'd check that on all
profiles, including dev and exp but realistically I don't think that
could happen.

The goal we've been originally pursuing was fixing depgraphs of
different arches (arm64, mips) to the point when it became correct
and marking them stable once that state was achieved. However, I'm not
sure if this is eventually going to fly because:

一. We don't really seem to be getting much closer, and as I mentioned
people keep committing new breakage.

二. I suppose marking mips stable would create some confusion resulting
in people trying to stabilize stuff.

三. This wouldn't help e.g. sparc which has recently lost stable status.
I'd still like to see it correct but I don't think the Council will
agree upon restoring the stable status without proper arch team backing
it.


So I'm thinking of an alternate idea: to start adding staging warnings
for additional profile class, combined with arch restriction. In other
words, change CI from:

  -p stable

to:

  -p stable,something -a alpha,amd64,...,mips,...

with a separate class for NonSolvableDeps in non-stable profiles (like
repoman's badindev/badinexp) that triggers only a staging-class warning.

However, this means that:

১. We need to settle for either dev or exp being 'more' supported,
and drop all unsupported profiles to the other group.

২. We need to fix the appropriate class of profiles for stable arches
(or move them to the other group).

৩. The arches in question still need to generate reasonably low number
of warnings.


Your thoughts?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Andreas K. Huettel]

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

Am Samstag, 6. Januar 2018, 12:10:53 CET schrieb Michał Górny:
> Hi, everyone.
> 
> I think most of us agree that support for minor arches in Gentoo
> is suboptimal, and that we've pretty much been focusing on avoiding
> the problem than really solving it.
> 

I think it would help here to get the arches.desc glep off the ground. Sorry, 
I've been busy with a lot of other things, but I'll try to get this done soon.

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

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

Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Michał Górny]

W dniu sob, 06.01.2018 o godzinie 12∶10 +0100, użytkownik Michał Górny
napisał:
> So I'm thinking of an alternate idea: to start adding staging warnings
> for additional profile class, combined with arch restriction. In other
> words, change CI from:
> 
>   -p stable
> 
> to:
> 
>   -p stable,something -a alpha,amd64,...,mips,...
> 
> with a separate class for NonSolvableDeps in non-stable profiles (like
> repoman's badindev/badinexp) that triggers only a staging-class warning.
> 
> However, this means that:
> 
> ১. We need to settle for either dev or exp being 'more' supported,
> and drop all unsupported profiles to the other group.
> 
> ২. We need to fix the appropriate class of profiles for stable arches
> (or move them to the other group).
> 
> ৩. The arches in question still need to generate reasonably low number
> of warnings.
> 

I'd like to follow this with a more precise proposal. Namely, redefine
the current profile statuses to apply the following:

a. stable -> fully tested, all depgraph breakages are errors,

b. exp -> fully tested, all depgraph breakages are warnings,

c. dev -> developer's playground, not tested.


This would specifically mean that:

1. Any 'exp' profiles with serious breakage will temporarily be
downgraded to 'dev'.

2. A 'dev' profile can be upgraded to 'exp' if its scale of depgraph
breakage is reasonable (i.e. doesn't clutter the QA report with too many
warnings).

3. A 'exp' profile can be upgraded to 'stable' only if it has no
depgraph breakages.

I don't have a strong opinion on whether we should pursue marking all
profiles 'stable', or if we support keeping 'exp' indefinitely.


The CI would be updated to test 'exp' profiles and report staging
warnings appropriately. Repoman would be updated to have warning-class
dependency.badinexp (like it has for .badindev right now) and to check
exp profiles by default.

Your thoughts?

-- 
Best regards,
Michał Górny

[gentoo-dev] about stable, dev and exp profile status

[Fabian Groffen]

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

On 07-01-2018 21:25:28 +0100, Michał Górny wrote:
> I'd like to follow this with a more precise proposal. Namely, redefine
> the current profile statuses to apply the following:
> 
> a. stable -> fully tested, all depgraph breakages are errors,
> 
> b. exp -> fully tested, all depgraph breakages are warnings,
> 
> c. dev -> developer's playground, not tested.

I always was under the impression the following order (and explanation)
was the case:

stable -> development -> experimental

For this reason, e.g. Prefix profiles are (still) experimental, which
means they really shouldn't bother non-Prefix people.  Prefix users and
developers work on an environment where those profiles are promoted to
development ones, such that repoman kicks in for their work.  (At least
that was the idea.)

I see you (re-)define dev as "developer's playground", and I wonder if
in that case it wouldn't be better to introduce a new one instead?

Maybe I'm just one of a few who thinks the order is reversed now.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] about stable, dev and exp profile status

[Michał Górny]

Dnia 11 stycznia 2018 08:43:32 CET, Fabian Groffen <grobian@gentoo.org> napisał(a):
>On 07-01-2018 21:25:28 +0100, Michał Górny wrote:
>> I'd like to follow this with a more precise proposal. Namely,
>redefine
>> the current profile statuses to apply the following:
>> 
>> a. stable -> fully tested, all depgraph breakages are errors,
>> 
>> b. exp -> fully tested, all depgraph breakages are warnings,
>> 
>> c. dev -> developer's playground, not tested.
>
>I always was under the impression the following order (and explanation)
>was the case:
>
>stable -> development -> experimental
>
>For this reason, e.g. Prefix profiles are (still) experimental, which
>means they really shouldn't bother non-Prefix people.  Prefix users and
>developers work on an environment where those profiles are promoted to
>development ones, such that repoman kicks in for their work.  (At least
>that was the idea.)
>
>I see you (re-)define dev as "developer's playground", and I wonder if
>in that case it wouldn't be better to introduce a new one instead?
>
>Maybe I'm just one of a few who thinks the order is reversed now.

Ulrich has pointed out good enough proof that the ordering should be as you say, so I'll correct my proposal.

>
>Thanks,
>Fabian


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

Re: [gentoo-dev] about stable, dev and exp profile status

[Paweł Hajdan, Jr.]

On 11/01/2018 08:43, Fabian Groffen wrote:
> I always was under the impression the following order (and explanation)
> was the case:
> 
> stable -> development -> experimental
> 
> For this reason, e.g. Prefix profiles are (still) experimental, which
> means they really shouldn't bother non-Prefix people.  Prefix users and
> developers work on an environment where those profiles are promoted to
> development ones, such that repoman kicks in for their work.  (At least
> that was the idea.)
> 
> I see you (re-)define dev as "developer's playground", and I wonder if
> in that case it wouldn't be better to introduce a new one instead?
> 
> Maybe I'm just one of a few who thinks the order is reversed now.

The stable -> dev -> exp order also feels more natural to me.

I don't have a strong opinion on this though.

Paweł

Re: [gentoo-dev] about stable, dev and exp profile status

[nado]

January 11, 2018 9:52 AM, "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> On 11/01/2018 08:43, Fabian Groffen wrote:
> 
>> I always was under the impression the following order (and explanation)
>> was the case:
>> 
>> stable -> development -> experimental
>> 
>> For this reason, e.g. Prefix profiles are (still) experimental, which
>> means they really shouldn't bother non-Prefix people. Prefix users and
>> developers work on an environment where those profiles are promoted to
>> development ones, such that repoman kicks in for their work. (At least
>> that was the idea.)
>> 
>> I see you (re-)define dev as "developer's playground", and I wonder if
>> in that case it wouldn't be better to introduce a new one instead?
>> 
>> Maybe I'm just one of a few who thinks the order is reversed now.
> 
> The stable -> dev -> exp order also feels more natural to me.
> 
> I don't have a strong opinion on this though.
> 
> Paweł

I got the impression that it was indeed
stable -> development -> experimental

with dev as in development, it seemed logical to put it between stable and experimental.
But now that I read these comments I wonder if it wasnt supposed to be called 'developers'
and then the other way round makes sense too.

--
Corentin “Nado” Pazdera

Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Michał Górny]

W dniu nie, 07.01.2018 o godzinie 21∶25 +0100, użytkownik Michał Górny
napisał:
> W dniu sob, 06.01.2018 o godzinie 12∶10 +0100, użytkownik Michał Górny
> napisał:
> > So I'm thinking of an alternate idea: to start adding staging warnings
> > for additional profile class, combined with arch restriction. In other
> > words, change CI from:
> > 
> >   -p stable
> > 
> > to:
> > 
> >   -p stable,something -a alpha,amd64,...,mips,...
> > 
> > with a separate class for NonSolvableDeps in non-stable profiles (like
> > repoman's badindev/badinexp) that triggers only a staging-class warning.
> > 
> > However, this means that:
> > 
> > ১. We need to settle for either dev or exp being 'more' supported,
> > and drop all unsupported profiles to the other group.
> > 
> > ২. We need to fix the appropriate class of profiles for stable arches
> > (or move them to the other group).
> > 
> > ৩. The arches in question still need to generate reasonably low number
> > of warnings.
> > 
> 
> I'd like to follow this with a more precise proposal. Namely, redefine
> the current profile statuses to apply the following:
> 
> a. stable -> fully tested, all depgraph breakages are errors,
> 
> b. exp -> fully tested, all depgraph breakages are warnings,
> 
> c. dev -> developer's playground, not tested.
> 
> 
> This would specifically mean that:
> 
> 1. Any 'exp' profiles with serious breakage will temporarily be
> downgraded to 'dev'.
> 
> 2. A 'dev' profile can be upgraded to 'exp' if its scale of depgraph
> breakage is reasonable (i.e. doesn't clutter the QA report with too many
> warnings).
> 
> 3. A 'exp' profile can be upgraded to 'stable' only if it has no
> depgraph breakages.
> 

Following the explanation from Ulrich Müller, I'm correcting this
proposal by swapping exp and dev, that is:

a. stable -> fully tested, all depgraph breakages are errors,

b. dev -> fully tested, all depgraph breakages are warnings,

c. exp -> not tested.

I will post updated patches shortly.

-- 
Best regards,
Michał Górny