[gentoo-dev] reminding slacker arch's to handle bugs

[gentoo-dev] reminding slacker arch's to handle bugs

[William Hubbs]

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

On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote:
> * Petteri R?ty <betelgeuse@gentoo.org>:
> > So let's summarize for assigning to the single arch:
> 
> > In support (and my comments in support):
> >  - Can be used as a gentle reminder for slacker arches
> 
> And if not "only one arch" or "single arch" is slacking?
> I guess you would find another gentle way to remind them.
> 
> 
> How about a tool generating mails to arch teams, which lists all
> STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month?
> (Or probably easier or possible at all: which weren't changed for 30 days.)
 
 I know that I have several bugs right now with minor arch's on them
 waiting to be stabilized.  A couple have been waiting for a very long
 time.  I have even pinged some of the bugs several times with no response.

 Is there anything else I can do to get these arch teams attention?

 William


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

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Maciej Mrozowski]

On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
> On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote:
> > * Petteri R?ty <betelgeuse@gentoo.org>:
> > > So let's summarize for assigning to the single arch:
> > > 
> > > In support (and my comments in support):
> > >  - Can be used as a gentle reminder for slacker arches
> > 
> > And if not "only one arch" or "single arch" is slacking?
> > I guess you would find another gentle way to remind them.
> > 
> > 
> > How about a tool generating mails to arch teams, which lists all
> > STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month?
> > (Or probably easier or possible at all: which weren't changed for 30
> > days.)
> 
>  I know that I have several bugs right now with minor arch's on them
>  waiting to be stabilized.  A couple have been waiting for a very long
>  time.  I have even pinged some of the bugs several times with no response.
> 
>  Is there anything else I can do to get these arch teams attention?

Yes, I think getting from them the privilege of being the only ones able to 
stabilize applications should do the job.

No, seriously - given the fact that some of my packages were even stabilized 
without contacting me (app-misc/hal-cups-utils, app-admin/system-config-
printer-common) - I think it should be:

* solely up to the package maintainers to stabilize application on arches 
they're using or on any arch if package is arch-agnostic (optionally, but 
preferably with some peer review from other project members or arch team 
members).

* to arch team members in other cases (like now)

* other rules (30 days 'waiting' period, bugzilla bug with STABLEREQ) applied 
as they are now

Role of arch teams would be decreased to peer review and solving KEYWORD 
requests.

It's really freaking silly to wait months for stabilization of some random 
php/perl library that's known to work.

Comments?

-- 
regards
MM

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Alistair Bush]

> On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
> 
> It's really freaking silly to wait months for stabilization of some random
> php/perl library that's known to work.

Have you ever just considered closing the stabilization bug and ignoring the 
arch.  If they take so long to mark your packages as stable why do you care 
about them enough to even attempt to stabilize anything on their arch.

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Brian Harring]

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

On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote:
> > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
> > 
> > It's really freaking silly to wait months for stabilization of some random
> > php/perl library that's known to work.
> 
> Have you ever just considered closing the stabilization bug and ignoring the 
> arch.  If they take so long to mark your packages as stable why do you care 
> about them enough to even attempt to stabilize anything on their arch.

If the pkg isn't a leaf node, you wind up keeping older and older 
versions lingering across multiple pkgs to keep it from breaking 
stable.

This is assuming that it's still heavily frowned upon to remove the 
only stable version available for a non-dead arch...
~harring

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

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Alistair Bush]

> On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote:
> > > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
> > > 
> > > It's really freaking silly to wait months for stabilization of some
> > > random php/perl library that's known to work.
> > 
> > Have you ever just considered closing the stabilization bug and ignoring
> > the arch.  If they take so long to mark your packages as stable why do
> > you care about them enough to even attempt to stabilize anything on
> > their arch.
> 
> If the pkg isn't a leaf node, you wind up keeping older and older
> versions lingering across multiple pkgs to keep it from breaking
> stable.

Oh no,  I mean you stop filing stable requests for the arch *period*.   So it 
just means you have to keep the last stable release for that arch around.

> 
> This is assuming that it's still heavily frowned upon to remove the
> only stable version available for a non-dead arch...
> ~harring

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Ciaran McCreesh]

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

On Sun, 28 Mar 2010 07:47:27 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:
> No, seriously - given the fact that some of my packages were even
> stabilized without contacting me (app-misc/hal-cups-utils,
> app-admin/system-config- printer-common) - I think it should be:

Well you'd marked them "~arch", right? That means they're candidates to
go stable.

> * solely up to the package maintainers to stabilize application on
> arches they're using or on any arch if package is arch-agnostic
> (optionally, but preferably with some peer review from other project
> members or arch team members).

There are no arch agnostic packages.

> It's really freaking silly to wait months for stabilization of some
> random php/perl library that's known to work.

How do you know it works if you don't test on the arch in question?

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: [RFC] Reworking package stabilization policies

[Duncan]

Brian Harring posted on Sat, 27 Mar 2010 23:34:43 -0700 as excerpted:

> On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote:
>> > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
>> > 
>> > It's really freaking silly to wait months for stabilization of some
>> > random php/perl library that's known to work.
>> 
>> Have you ever just considered closing the stabilization bug and
>> ignoring the arch.  If they take so long to mark your packages as
>> stable why do you care about them enough to even attempt to stabilize
>> anything on their arch.
> 
> If the pkg isn't a leaf node, you wind up keeping older and older
> versions lingering across multiple pkgs to keep it from breaking stable.
> 
> This is assuming that it's still heavily frowned upon to remove the only
> stable version available for a non-dead arch... ~harring

What I've seen maintainers (report) doing before, when they give up on a(n 
non-experimental) arch, is keep the last stable version for that arch 
around, but remove all other keywords, and reassign all bugs for that 
version to the arch in question, with a (perhaps boilerplate) comment on 
the bug to the effect that said arch refuses to stabilize any further, 
thus the only reason said version remains in the tree, so the bug is 
theirs to deal with or not deal with as they choose.

I've always wondered what happened to such bugs after that, but never 
enough to actually go find some to see...

-- 
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] Reworking package stabilization policies

[Tomáš Chvátal]

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

Dne 28.3.2010 09:39, Ciaran McCreesh napsal(a):
> On Sun, 28 Mar 2010 07:47:27 +0200
> Maciej Mrozowski <reavertm@gmail.com> wrote:
>> No, seriously - given the fact that some of my packages were even
>> stabilized without contacting me (app-misc/hal-cups-utils,
>> app-admin/system-config- printer-common) - I think it should be:
> 
> Well you'd marked them "~arch", right? That means they're candidates to
> go stable.
> 
Yes, but last time i checked we have consensus that archies should wait
onto maintainer to request the stabling.
>> * solely up to the package maintainers to stabilize application on
>> arches they're using or on any arch if package is arch-agnostic
>> (optionally, but preferably with some peer review from other project
>> members or arch team members).
> 
> There are no arch agnostic packages.
I can find some, for example kde-l10n O:P But you are right.
> 
>> It's really freaking silly to wait months for stabilization of some
>> random php/perl library that's known to work.
> 
> How do you know it works if you don't test on the arch in question?
> 

Basically you are saying that NONE tested that package on the arch until
the stablerequest. That's quite wrong and it should mean that the arch
should be ~ only, since they are stabling packages that they first
tested the day they stable them.

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

iEYEARECAAYFAkuvKa0ACgkQHB6c3gNBRYdaWACdGP3EvuvL3+GVXI8GBsU3fHqj
Kq8AoJMyVDS8P0vCXfwJuGIIEQHWPgUL
=CO3D
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Richard Freeman]

On 03/28/2010 06:04 AM, Tomáš Chvátal wrote:
>
> Basically you are saying that NONE tested that package on the arch until
> the stablerequest. That's quite wrong and it should mean that the arch
> should be ~ only, since they are stabling packages that they first
> tested the day they stable them.
>

Well, keep in mind that if a package is marked ~arch, it is getting 
used, but for the most part it isn't getting used with other packages 
that are stable.  So, if your package is ~arch for a period of time that 
gives you strong evidence that it works with openrc, but no evidence as 
to whether it works with baselayout-1, which is what stable users have.

So, I would argue that for any package to be stabilized on an arch it 
should be tested on that arch on a stable platform.

amd64 has had the policy that any dev can stabilize if they've tested it 
on a stable amd64 system, and this hasn't really caused problems.

Perhaps we should encourage understaffed arch teams to recruit more arch 
testers if possible?  Then any dev could ask an arch tester to test on 
some platform that they don't have access to, and then stabilize 
accordingly?

For arch-neutral packages a more liberal policy might be possible, but 
keep in mind that the set of stable packages is not the same across 
archs.  So, unless you check carefully you might not be testing the same 
library dependency versions from one stable platform to another, and 
that could cause problems.

Rich

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Maciej Mrozowski]

On Sunday 28 of March 2010 09:39:18 Ciaran McCreesh wrote:

> > It's really freaking silly to wait months for stabilization of some
> > random php/perl library that's known to work.

> How do you know it works if you don't test on the arch in question?
The problem is not waiting for some <instert some exotic arch here> to go 
stable so it would be possible to close bug and ignore arches.
It's not about closing bug at all.
The only inconvenience from exotic arches lagging is inability to remove 
particular old ebuild from tree, that's it.

It's about having package marked stabled on my arch (amd64 in my case, may be 
other from other developer's perspective) in a timely manner.

And I know it works on my arch because I test it and often use it on daily 
basis.

On Sunday 28 of March 2010 13:32:59 Richard Freeman wrote:
> amd64 has had the policy that any dev can stabilize if they've tested it
> on a stable amd64 system, and this hasn't really caused problems.
That would have certainly solved the problem if that policy was written and 
published anywhere.

-- 
regards
MM

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[William Hubbs]

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

On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote:
> > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
> > 
> > It's really freaking silly to wait months for stabilization of some random
> > php/perl library that's known to work.
> 
> Have you ever just considered closing the stabilization bug and ignoring the 
> arch.  If they take so long to mark your packages as stable why do you care 
> about them enough to even attempt to stabilize anything on their arch.
 
If they have old versions of the package stable on their arch, ignoring
them wouldn't be the right answer either.  That makes you keep the old
versions around because the arch team isn't keeping up.

William


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

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Peter Volkov]

В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет:
> No, seriously - given the fact that some of my packages were even stabilized 
> without contacting me (app-misc/hal-cups-utils, app-admin/system-config-
> printer-common) 

If you know packages are broken why they were not hardmasked? If they
have no problems what why it was bad idea to mark them stable?

> * solely up to the package maintainers to stabilize application on arches 
> they're using or on any arch if package is arch-agnostic (optionally, but 
> preferably with some peer review from other project members or arch team 
> members).

In general package maintainer should avoid to stabilize the packages he
worked on as one of the arch team's goal was to have second eyes on
package before it goes stable.

> Role of arch teams would be decreased to peer review and solving KEYWORD 
> requests.
> 
> It's really freaking silly to wait months for stabilization of some random 
> php/perl library that's known to work.

Why wait? amd64 team requested help and every developer who tested
package on stable profile is allowed to mark package stable. For rare
archs it's possible configure search filters to avoid stabilization
requests.

-- 
Peter.

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

[Maciej Mrozowski]

On Monday 29 of March 2010 09:30:38 Peter Volkov wrote:
> В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет:
> > No, seriously - given the fact that some of my packages were even
> > stabilized without contacting me (app-misc/hal-cups-utils,
> > app-admin/system-config- printer-common)
> 
> If you know packages are broken why they were not hardmasked? If they
> have no problems what why it was bad idea to mark them stable?

They are not broken, they're just not suitable. It's like stabilizing gcc-2.95 
now, even when it won't work with some recent KDE/boost.
hal-cups-utils is not a problem
system-config-printer-common-1.1.13 is as it's being used by maybe 
incompatible now system-config-printer-kde from testing arch (I've raised 
those deps now), besides I wanted to wait for polkit-1 with this package 
(otherwise dbus "newprinternotifications" can be received only by root or 
require tweaking dbus conf to work out of the box . That's why kde-
base/system-config-printer-kde and kde-base/printer-applet were intentionally 
left out from KDE-4.3.3 stabilization list.

-- 
regards
MM