FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-25-2011, 11:30 AM
Markos Chandras
 
Default Slacker arches

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
 
Old 01-25-2011, 02:49 PM
Jeremy Olexa
 
Default Slacker arches

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
 
Old 01-25-2011, 02:56 PM
Tomáš Chvátal
 
Default Slacker arches

-----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-----
 
Old 01-26-2011, 01:14 AM
Ryan Hill
 
Default Slacker arches

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
 
Old 01-26-2011, 05:45 AM
"Paweł Hajdan, Jr."
 
Default Slacker arches

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ł
 
Old 01-30-2011, 05:12 PM
"Paweł Hajdan, Jr."
 
Default Slacker arches

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ł
 

Thread Tools




All times are GMT. The time now is 02:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org