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 03-28-2010, 05:47 AM
Maciej Mrozowski
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 06:31 AM
Alistair Bush
 
Default Reworking package stabilization policies

> 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.
 
Old 03-28-2010, 06:34 AM
Brian Harring
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 06:56 AM
Alistair Bush
 
Default Reworking package stabilization policies

> 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
 
Old 03-28-2010, 07:39 AM
Ciaran McCreesh
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 09:43 AM
Duncan
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 10:04 AM
Tomáš Chvátal
 
Default Reworking package stabilization policies

-----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-----
 
Old 03-28-2010, 11:32 AM
Richard Freeman
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 03:18 PM
Maciej Mrozowski
 
Default Reworking package stabilization policies

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
 
Old 03-28-2010, 08:35 PM
William Hubbs
 
Default Reworking package stabilization policies

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
 

Thread Tools




All times are GMT. The time now is 10:56 PM.

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