[gentoo-dev] Slacker arches

[gentoo-dev] Slacker arches

[Tomáš Chvátal]

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

Hi,
Given the talk on last council meeting I would like this policy to be in
effect over main tree:

Every arch teams should stabilise OR write out reason why they can't do
so to stable bug in 90 days. If any arch team fails to do so the
maintainer can decide to drop their keywords to testing. Given depgraph
breakages the maintainer can coordinate with the QA team to drop all
reverse dependencies to testing too.
Only exception from this rule are toolchain and base-system bugs, since
testing-only effectively means that the arch lost stable status as whole.
In order to accommodate this goals Arch Teams can generate Arch Testers
which can comment on the bugs in their name, where maintainer then can
act upon their comments (eg: if ARM at say that everything is ok,
maintainer can stabilise it on arm...). (Come on for most stable testing
you don't really need to be fully fledged Gentoo dev, but you just need
the named hardware and working brain :))

Cheers

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+thsACgkQHB6c3gNBRYfW4wCfXbctXUgKoK53Pd45QuAMgY7r
Sy4AoMU6z/oS/JvUum6/29SHYsmuoQBs
=LQj9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Slacker arches

[Tomáš Chvátal]

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

Dne 25.1.2011 12:38, Tomáš Chvátal napsal(a):
> Hi,
> Given the talk on last council meeting I would like this policy to be in
> effect over main tree:
> 
> Every arch teams should stabilise OR write out reason why they can't do
> so to stable bug in 90 days. If any arch team fails to do so the
> maintainer can decide to drop their keywords to testing. Given depgraph
> breakages the maintainer can coordinate with the QA team to drop all
> reverse dependencies to testing too.
> Only exception from this rule are toolchain and base-system bugs, since
> testing-only effectively means that the arch lost stable status as whole.
> In order to accommodate this goals Arch Teams can generate Arch Testers
> which can comment on the bugs in their name, where maintainer then can
> act upon their comments (eg: if ARM at say that everything is ok,
> maintainer can stabilise it on arm...). (Come on for most stable testing
> you don't really need to be fully fledged Gentoo dev, but you just need
> the named hardware and working brain :))
> 
> Cheers
> 
> Tom
AAnd as Mark told me I actually didn't say that i want feedback and
opinions on those two mails i just sent to this ML, so please tell us
how do you feel about it and what would you like to be done differently :)
These two mails (slacker arches, eapi usage) are not policies in effect
but stuff council would like to decide about and want to know the
devhood opinions.

Cheers
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+vJMACgkQHB6c3gNBRYc4+wCeLPeysLA/xTacnofptQBbai5z
jpEAn0jyipxEV/U/IQylCmzj3IVbe3NZ
=LHQi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Slacker arches

["Paweł Hajdan, Jr."]

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

On 1/25/11 12:38 PM, Tomáš Chvátal wrote:
> Every arch teams should stabilise OR write out reason why they can't do
> so to stable bug in 90 days. If any arch team fails to do so the
> maintainer can decide to drop their keywords to testing. Given depgraph
> breakages the maintainer can coordinate with the QA team to drop all
> reverse dependencies to testing too.

Seconded. Reality++

Be prepared for some issues though. Sometimes maintainers don't agree
with reasons arch teams provide that block stabilizations. In those
cases, who makes the decision? My suggestion is QA.

Also, we should have someone to check for stale stabilization bugs. I'm
not sure if all reporters are able to take care of that, especially if
they have a lot of bugs open.

Paweł


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

Re: [gentoo-dev] Slacker arches

[Markos Chandras]

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

On Tue, Jan 25, 2011 at 01:20:29PM +0100, "Paweł Hajdan, Jr." wrote:
> On 1/25/11 12:38 PM, Tomáš Chvátal wrote:
> > Every arch teams should stabilise OR write out reason why they can't do
> > so to stable bug in 90 days. If any arch team fails to do so the
> > maintainer can decide to drop their keywords to testing. Given depgraph
> > breakages the maintainer can coordinate with the QA team to drop all
> > reverse dependencies to testing too.
> 
> Seconded. Reality++
> 
> Be prepared for some issues though. Sometimes maintainers don't agree
> with reasons arch teams provide that block stabilizations. In those
> cases, who makes the decision? My suggestion is QA.
QA is not a solution to everything. The problem Tomas is trying to
counter here is the idle/slacking arches. If the arch is active but have some
concerns regarding the stabilization then let the maintainer deal with
it. This is the way we do it now anyway
> 
> Also, we should have someone to check for stale stabilization bugs. I'm
> not sure if all reporters are able to take care of that, especially if
> they have a lot of bugs open.
> 
> Paweł
> 
Thats really their problem. Arches can always remove themselves from the
bugs. No need to care about stale bugs. If the maintainers don't care
then we(arches) don't care.

Regards,
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Key ID: B4AFF2C2
Key FP: 660A 0742 84EC 26F1 9EDB  F00A FA83 5A15 B4AF F2C2

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

Re: [gentoo-dev] Slacker arches

[Jeremy Olexa]

 On Tue, 25 Jan 2011 12:38:03 +0100, Tomáš Chvátal wrote:

> Only exception from this rule are toolchain and base-system bugs, 
> since

 In both threads you recently started, you used the term "base-system 
 bugs" but I think you mean "@system packages" - there are a ton of 
 base-system packages that are not critical and wouldn't apply to either 
 of your threads. Is this an accurate assumption on my part here?

 -Jeremy

Re: [gentoo-dev] Slacker arches

[Tomáš Chvátal]

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

Dne 25.1.2011 16:49, Jeremy Olexa napsal(a):
> On Tue, 25 Jan 2011 12:38:03 +0100, Tomáš Chvátal wrote:
> 
>> Only exception from this rule are toolchain and base-system bugs, since
> 
> In both threads you recently started, you used the term "base-system
> bugs" but I think you mean "@system packages" - there are a ton of
> base-system packages that are not critical and wouldn't apply to either
> of your threads. Is this an accurate assumption on my part here?
> 
> -Jeremy
> 
Yeah you are right :P mea culpa maxima
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+8p4ACgkQHB6c3gNBRYfCHQCggR3NiP+1R/vhHU/tAHSzJC2p
ZhAAn0VHw3HaadJstoTpLgLeYG9HL63m
=HLLa
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Slacker arches

[Ryan Hill]

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

On Tue, 25 Jan 2011 12:38:03 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:

> Every arch teams should stabilise OR write out reason why they can't do
> so to stable bug in 90 days. If any arch team fails to do so the
> maintainer can decide to drop their keywords to testing. Given depgraph
> breakages the maintainer can coordinate with the QA team to drop all
> reverse dependencies to testing too.

Won't this just pile on more work on already stressed to the max arch teams?
As in, now they have to stabilize more packages to get back to where they
were in the first place?

And as I understand it, the reason maintainers are complaining is because
they want to drop old versions.  Meaning stable users of these archs can
suddenly lose large parts of the tree if this happens.  From their point of
view, we've just broken perfectly working systems.  That's pretty much the
opposite of what stable is supposed to promise.  And I've never been an arch
tester, but I bet after the first few times I tested a package only to have it
dropped to ~arch because no developer was around to commit the keyword
change, I wouldn't feel much like doing it anymore.

How about the opposite?  If everyone but $arch has stabilized the package,
and you can't get a response from them in a reasonable time, then use your
discretion as maintainer and mark it stable yourself.  This isn't ideal, and
it could cause something to break for stable users now and then, but it's
better than the guaranteed breakage of just dropping the stable keyword for
it and its dependencies.  Arch testers would remain useful by giving the
maintainer some measure of assurance that they won't accidently break
anything for that arch.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Slacker arches

["Paweł Hajdan, Jr."]

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

On 1/26/11 3:14 AM, Ryan Hill wrote:
> On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal
> <scarabeus@gentoo.org> wrote:
> 
> Won't this just pile on more work on already stressed to the max arch
> teams? As in, now they have to stabilize more packages to get back to
> where they were in the first place?

This seems to be a self-balancing system to me. If the arch team is so
stressed that it can't stabilize something within 90 days, and can't
even state a reason for that, just move the package back to testing.

After some time, the stable set for that arch should be small enough to
let the arch team handle it on time.

> And as I understand it, the reason maintainers are complaining is
> because they want to drop old versions.

I'm not sure why maintainers are complaining, but generally managing
bugs that sit there for a long time is harder.

> Meaning stable users of these archs can suddenly lose large parts of
> the tree if this happens.  From their point of view, we've just
> broken perfectly working systems.  That's pretty much the opposite of
> what stable is supposed to promise.

That's an important point. I think that a message should be sent
somewhere (gentoo-dev-announce?) that something like that is going to
happen, and wait some 60 days for someone to save the package.

> And I've never been an arch tester, but I bet after the first few
> times I tested a package only to have it dropped to ~arch because no
> developer was around to commit the keyword change, I wouldn't feel
> much like doing it anymore.

Good point.

> How about the opposite?  If everyone but $arch has stabilized the
> package, and you can't get a response from them in a reasonable time,
> then use your discretion as maintainer and mark it stable yourself.

Very dangerous, especially for exotic arches. I think we should not go
that way, or at least _require_ the maintainer to test on that arch. We
have some development machines for various arches so it should be
technically possible. But it generally seems to me that maintainers miss
more problems than arch testers/developers.

> Arch testers would remain useful by giving the maintainer some
> measure of assurance that they won't accidently break anything for
> that arch.

Good point, again provided the maintainer at least compile-tests the
package on that arch.

Paweł


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

[gentoo-dev] Status of sparc-fbsd, amd64-fbsd

[Torsten Veller]

Arch teams handle KEYWORDREQ bugs too.

I have masked the only dev-lang/perl version keyworded for "sparc-fbsd"
3 weeks ago. No user, no dev complained by now (#288028).

So I think this arch (as much as amd64-fbsd) is unsupported/dead but
repoman's dependencies check reports a lot of warnings due to the "dev"
status of their profiles.

Do we want to:
- remove "amd64-fbsd" completely (affects app-doc/pms, sys-apps/grep)?
- move "sparc-fbsd"-profiles to "exp" or kill it?

-- 
Regards Torsten

Re: [gentoo-dev] Status of sparc-fbsd, amd64-fbsd

[Samuli Suominen]

On 01/28/2011 09:31 AM, Torsten Veller wrote:
> Arch teams handle KEYWORDREQ bugs too.
> 
> I have masked the only dev-lang/perl version keyworded for "sparc-fbsd"
> 3 weeks ago. No user, no dev complained by now (#288028).
> 
> So I think this arch (as much as amd64-fbsd) is unsupported/dead but
> repoman's dependencies check reports a lot of warnings due to the "dev"
> status of their profiles.
> 
> Do we want to:
> - move "sparc-fbsd"-profiles to "exp" or kill it?

I tried to remove ~sparc-fbsd like year ago, when there was nobody to
keyword dev-lang/python requirement dev-libs/libffi and...

There is at least one user out there, with a remote server using it.
That same user gave me and aballier access to it. Unfortunately, since
then, I've lost my logins and don't know if the server is still up.

So I think your own chance is to contact aballier, ask if he still has
access (or ask for renewed opinion for the killing)

Re: [gentoo-dev] Slacker arches

["Paweł Hajdan, Jr."]

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

On 1/25/11 1:30 PM, Markos Chandras wrote:
> QA is not a solution to everything. The problem Tomas is trying to
> counter here is the idle/slacking arches. If the arch is active but have some
> concerns regarding the stabilization then let the maintainer deal with
> it. This is the way we do it now anyway
>>
>> Also, we should have someone to check for stale stabilization bugs. I'm
>> not sure if all reporters are able to take care of that, especially if
>> they have a lot of bugs open.
>>
> Thats really their problem. Arches can always remove themselves from the
> bugs. No need to care about stale bugs. If the maintainers don't care
> then we(arches) don't care.

I was mostly thinking about cases like https://bugs.gentoo.org/329633
where indeed arches remove themselves from the bug, but there is a
dispute between them and the maintainer about the correct course of action.

The usual "conflict resolution" procedure would be to contact the team
lead, and eventually the council. However, I'm not sure whether that
would be optimal for stabilization bugs.

Paweł


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

[gentoo-dev] Re: Status of sparc-fbsd

[Torsten Veller]

* Samuli Suominen <ssuominen@gentoo.org>:
> So I think your own chance is to contact aballier, ask if he still has
> access (or ask for renewed opinion for the killing)

That was the intention. I cc'ed the bsd team and am still expecting a
reply.

I will move the sparc-bsd and amd-bsd profiles to "exp" in one week.
I suggest to remove amd-bsd completely.


--- profiles.desc       14 Dec 2010 20:44:09 -0000      1.166
+++ profiles.desc       11 Feb 2011 06:49:12 -0000
@@ -147,8 +147,8 @@
 # Gentoo/FreeBSD Profiles
-amd64-fbsd     default/bsd/fbsd/amd64/7.2                      dev
-amd64-fbsd     default/bsd/fbsd/amd64/8.0                      dev
-sparc-fbsd     default/bsd/fbsd/sparc/7.2                      dev
-sparc-fbsd     default/bsd/fbsd/sparc/8.0                      dev
+amd64-fbsd     default/bsd/fbsd/amd64/7.2                      exp
+amd64-fbsd     default/bsd/fbsd/amd64/8.0                      exp
+sparc-fbsd     default/bsd/fbsd/sparc/7.2                      exp
+sparc-fbsd     default/bsd/fbsd/sparc/8.0                      exp
 x86-fbsd       default/bsd/fbsd/x86/7.2                        dev
 x86-fbsd       default/bsd/fbsd/x86/8.0                        dev

[gentoo-dev] Re: Status of sparc-fbsd

[Alexis Ballier]

On Friday, February 11, 2011 03:53:35 AM Torsten Veller wrote:
> * Samuli Suominen <ssuominen@gentoo.org>:
> > So I think your own chance is to contact aballier, ask if he still has
> > access (or ask for renewed opinion for the killing)
> 
> That was the intention. I cc'ed the bsd team and am still expecting a
> reply.
> 
> I will move the sparc-bsd and amd-bsd profiles to "exp" in one week.
> I suggest to remove amd-bsd completely.


as far as i'm concerned, you can proceed with this

A.

> 
> 
> --- profiles.desc       14 Dec 2010 20:44:09 -0000      1.166
> +++ profiles.desc       11 Feb 2011 06:49:12 -0000
> @@ -147,8 +147,8 @@
>  # Gentoo/FreeBSD Profiles
> -amd64-fbsd     default/bsd/fbsd/amd64/7.2                      dev
> -amd64-fbsd     default/bsd/fbsd/amd64/8.0                      dev
> -sparc-fbsd     default/bsd/fbsd/sparc/7.2                      dev
> -sparc-fbsd     default/bsd/fbsd/sparc/8.0                      dev
> +amd64-fbsd     default/bsd/fbsd/amd64/7.2                      exp
> +amd64-fbsd     default/bsd/fbsd/amd64/8.0                      exp
> +sparc-fbsd     default/bsd/fbsd/sparc/7.2                      exp
> +sparc-fbsd     default/bsd/fbsd/sparc/8.0                      exp
>  x86-fbsd       default/bsd/fbsd/x86/7.2                        dev
>  x86-fbsd       default/bsd/fbsd/x86/8.0                        dev