[gentoo-user] How packages are made stable

[gentoo-user] How packages are made stable

[Andrey Gerasimenko]

Looking at the Portage tree, I see that some packages are kept ~x86 for  
long time without any bugs referenced in the changelog or Bugzilla. How  
are they being made stable (or where in the docs is the process described)?

-- 
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Andrey Gerasimenko wrote:
> Looking at the Portage tree, I see that some packages are kept ~x86 
> for long time without any bugs referenced in the changelog or 
> Bugzilla. How are they being made stable (or where in the docs is the 
> process described)? 
They need to be in the tree for at least 30 days, no bugs, and if 
someone files a stable request ebuild, then an arch tester will test it, 
and then a dev will keyword it stable.

Most stuff doesnt get marked stable mostly because there aren't any 
stable requests.

Steve
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Steve Dibb wrote:
> Andrey Gerasimenko wrote:
>> Looking at the Portage tree, I see that some packages are kept ~x86 
>> for long time without any bugs referenced in the changelog or 
>> Bugzilla. How are they being made stable (or where in the docs is the 
>> process described)? 
> They need to be in the tree for at least 30 days, no bugs, and if 
> someone files a stable request ebuild, then an arch tester will test 
> it, and then a dev will keyword it stable.
>
Oh, and I forgot .... all the dependencies should be marked stable as well.

I would actually encourage users to find and file stable request ebuild 
bugs.  Just make sure you post emerge --info along there in the bug.

Steve
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Robert Cernansky]

On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:

> Andrey Gerasimenko wrote:
> > Looking at the Portage tree, I see that some packages are kept ~x86 
> > for long time without any bugs referenced in the changelog or 
> > Bugzilla. How are they being made stable (or where in the docs is the 
> > process described)? 
> They need to be in the tree for at least 30 days, no bugs, and if 
> someone files a stable request ebuild, then an arch tester will test it, 
> and then a dev will keyword it stable.
> 
> Most stuff doesnt get marked stable mostly because there aren't any 
> stable requests.

Stabilisation bug it not a requirement. Package should go to stable
after 30 days + no bugs even without stabilization bug. I have an
impresion that developers are _waiting_ for stabilization bugs which
is wrong.

I've raised a similar question few months ago. It's pretty long
discussion on -user and -dev:

http://thread.gmane.org/gmane.linux.gentoo.user/166565/
http://thread.gmane.org/gmane.linux.gentoo.devel/40719/

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Andrey Gerasimenko]

On Fri, 05 Jan 2007 11:49:30 +0300, Robert Cernansky <hslists2@zoznam.sk>  
wrote:

> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
>
>> Andrey Gerasimenko wrote:
>> > Looking at the Portage tree, I see that some packages are kept ~x86
>> > for long time without any bugs referenced in the changelog or
>> > Bugzilla. How are they being made stable (or where in the docs is the
>> > process described)?
>> They need to be in the tree for at least 30 days, no bugs, and if
>> someone files a stable request ebuild, then an arch tester will test it,
>> and then a dev will keyword it stable.
>>
>> Most stuff doesnt get marked stable mostly because there aren't any
>> stable requests.
>
> Stabilisation bug it not a requirement. Package should go to stable
> after 30 days + no bugs even without stabilization bug. I have an
> impresion that developers are _waiting_ for stabilization bugs which
> is wrong.
>
> I've raised a similar question few months ago. It's pretty long
> discussion on -user and -dev:
>
> http://thread.gmane.org/gmane.linux.gentoo.user/166565/
> http://thread.gmane.org/gmane.linux.gentoo.devel/40719/
>
> Robert
>
>

Thanks for the threads. My impression is that the way stabilization works  
should be described in a place of high visibility, at least in the FAQ. I  
beleive this question will be asked again and again if new users do not  
see how "stable" is defined early. If they see the definition, no  
questions will be asked. For example, I do not think that developers  
waiting for bug reports to stabilize an ebuild is either wrong or correct.  
It is just a part of the current definition of the term "stable".

-- 
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Robert Cernansky]

On Fri, 05 Jan 2007 17:04:26 +0300 Andrey Gerasimenko <gak@kaluga.ru> wrote:

> Thanks for the threads. My impression is that the way stabilization
> works should be described in a place of high visibility, at least in
> the FAQ. I beleive this question will be asked again and again if
> new users do not see how "stable" is defined early. If they see the
> definition, no questions will be asked. For example, I do not think
> that developers waiting for bug reports to stabilize an ebuild is
> either wrong or correct.  It is just a part of the current
> definition of the term "stable".

It is described in gentoo docs:

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4

See part "Moving package versions from ~ARCH to ARCH". I agree that
this is perhaps not "a place with high visibility". Maybe it should be
included into FAQs.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Robert Cernansky wrote:
> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
> 
>> Andrey Gerasimenko wrote:
>>> Looking at the Portage tree, I see that some packages are kept ~x86 
>>> for long time without any bugs referenced in the changelog or 
>>> Bugzilla. How are they being made stable (or where in the docs is the 
>>> process described)? 
>> They need to be in the tree for at least 30 days, no bugs, and if 
>> someone files a stable request ebuild, then an arch tester will test it, 
>> and then a dev will keyword it stable.
>>
>> Most stuff doesnt get marked stable mostly because there aren't any 
>> stable requests.
> 
> Stabilisation bug it not a requirement. Package should go to stable
> after 30 days + no bugs even without stabilization bug.

No, it's not a requirement.  It's a notice telling the developers that hey, 
someone wants it marked stable.  Plus, if a user / arch tester does the legwork 
already of checking to make sure the dependencies are good to go, then we 
appreciate the work and it creates less of a load for us.

> I have an
> impresion that developers are _waiting_ for stabilization bugs which
> is wrong.

That's not true.  But there's certainly enough work to go around that they can 
get neglected.

> I've raised a similar question few months ago. It's pretty long
> discussion on -user and -dev:
> 
> http://thread.gmane.org/gmane.linux.gentoo.user/166565/
> http://thread.gmane.org/gmane.linux.gentoo.devel/40719/

Good discussions, and my opinion is still the same -- that most packages are 
assigned to herds, or unassigned to nobody, are minor things, and nobody is 
directly looking after them.  As a result they just plain get ignored.

In summary, no a stable bug is not needed, but if its a small less popular 
package, it probably won't hit on anyones radar any other way.

Plus, I'm working on integrating some similar checks found in
http://gentoo.tamperd.net/stable/ into the GPNL website ( 
http://spaceparanoids.org/gentoo/gpnl/ ), so that we can again easily see how 
long packges have been neglected.

Steve

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Andrey Gerasimenko wrote:
> On Fri, 05 Jan 2007 11:49:30 +0300, Robert Cernansky 
> <hslists2@zoznam.sk> wrote:
> 
>> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
>>
>>> Andrey Gerasimenko wrote:
>>> > Looking at the Portage tree, I see that some packages are kept ~x86
>>> > for long time without any bugs referenced in the changelog or
>>> > Bugzilla. How are they being made stable (or where in the docs is the
>>> > process described)?
>>> They need to be in the tree for at least 30 days, no bugs, and if
>>> someone files a stable request ebuild, then an arch tester will test it,
>>> and then a dev will keyword it stable.
>>>
>>> Most stuff doesnt get marked stable mostly because there aren't any
>>> stable requests.
>>
>> Stabilisation bug it not a requirement.

Actually, everything I said in that last email was a little off.  Stabilization 
bugs are required because ultimately it is the architecture team that is going 
to mark it stable, not the developer.  There are some cases where things can go 
directly stable (such as security vulnerabilities), but those are the exception 
and not the rule.

So if you want something stable, do all the checks, file a bug, and copy all the 
arches that it applies to.  You can see which ones use it on 
http://packages.gentoo.org/

Steve
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Robert Cernansky]

On Fri, 05 Jan 2007 07:33:31 -0700 Steve Dibb <beandog@gentoo.org> wrote:

> Andrey Gerasimenko wrote:
> > On Fri, 05 Jan 2007 11:49:30 +0300, Robert Cernansky 
> > <hslists2@zoznam.sk> wrote:
> > 
> >> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
> >>> Most stuff doesnt get marked stable mostly because there aren't
> >>> any stable requests.
> >>
> >> Stabilisation bug it not a requirement.
> 
> Actually, everything I said in that last email was a little off.
> Stabilization bugs are required because ultimately it is the
> architecture team that is going to mark it stable, not the
> developer.  There are some cases where things can go directly stable
> (such as security vulnerabilities), but those are the exception and
> not the rule.
> 
> So if you want something stable, do all the checks, file a bug, and
> copy all the arches that it applies to.  You can see which ones use
> it on http://packages.gentoo.org/

I perfectly agree with your previous e-mail where you sayng that "it's
a notice telling the developers that hey, someone wants it marked
stable." And I agree that stabilisation bugs are helping developers
and everybody should write it when appropriate. But it should not be
a requirement.

In documentation [1] it is not mentioned a stabilisation bug. Is there
any other documentation specific for architecture team that have
higher priorty?

The exception because of security bug, that you mentioned, allows to
ingnore 30 days + no bugs rule, it has nothing to do with
stabilisation bugs.

1. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Robert Cernansky wrote:
> On Fri, 05 Jan 2007 07:33:31 -0700 Steve Dibb <beandog@gentoo.org> wrote:
>
>   
>> Andrey Gerasimenko wrote:
>>     
>>> On Fri, 05 Jan 2007 11:49:30 +0300, Robert Cernansky 
>>> <hslists2@zoznam.sk> wrote:
>>>
>>>       
>>>> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
>>>>         
>>>>> Most stuff doesnt get marked stable mostly because there aren't
>>>>> any stable requests.
>>>>>           
>>>> Stabilisation bug it not a requirement.
>>>>         
>> Actually, everything I said in that last email was a little off.
>> Stabilization bugs are required because ultimately it is the
>> architecture team that is going to mark it stable, not the
>> developer.  There are some cases where things can go directly stable
>> (such as security vulnerabilities), but those are the exception and
>> not the rule.
>>
>> So if you want something stable, do all the checks, file a bug, and
>> copy all the arches that it applies to.  You can see which ones use
>> it on http://packages.gentoo.org/
>>     
>
> I perfectly agree with your previous e-mail where you sayng that "it's
> a notice telling the developers that hey, someone wants it marked
> stable." And I agree that stabilisation bugs are helping developers
> and everybody should write it when appropriate. But it should not be
> a requirement.
>   

Thanks for dragging this out Robert, because I again need to make a 
correction.

AFAIK, there is no policy saying that there's a requirement for there to 
be a stablization bug.  However, since it is the architecture team's 
final decision, filing bugs is just the preferred way of notifying many 
at once.

> In documentation [1] it is not mentioned a stabilisation bug. Is there
> any other documentation specific for architecture team that have
> higher priorty?
>   

Yah, that doc doesn't really go into detail other than saying if the 
maintainer thinks it's okay to mark stable.  Again, strictly speaking 
that is correct, since the maintainer should check off if the ebuild is 
okay to mark stable, and then the arches decide if they want to do it or 
not.

The doc doesn't go into much detail.  It looks like there's no real 
strict policy on the matter, and the de facto way of doing things has 
worked pretty well besides that. :)

Steve
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Kevin O'Gorman]

On 1/5/07, Robert Cernansky <hslists2@zoznam.sk> wrote:
> On Fri, 05 Jan 2007 07:33:31 -0700 Steve Dibb <beandog@gentoo.org> wrote:
>
> > Andrey Gerasimenko wrote:
> > > On Fri, 05 Jan 2007 11:49:30 +0300, Robert Cernansky
> > > <hslists2@zoznam.sk> wrote:
> > >
> > >> On Thu, 04 Jan 2007 13:49:48 -0700 Steve Dibb <beandog@gentoo.org> wrote:
> > >>> Most stuff doesnt get marked stable mostly because there aren't
> > >>> any stable requests.
> > >>
> > >> Stabilisation bug it not a requirement.
> >
> > Actually, everything I said in that last email was a little off.
> > Stabilization bugs are required because ultimately it is the
> > architecture team that is going to mark it stable, not the
> > developer.  There are some cases where things can go directly stable
> > (such as security vulnerabilities), but those are the exception and
> > not the rule.
> >
> > So if you want something stable, do all the checks, file a bug, and
> > copy all the arches that it applies to.  You can see which ones use
> > it on http://packages.gentoo.org/
>
> I perfectly agree with your previous e-mail where you sayng that "it's
> a notice telling the developers that hey, someone wants it marked
> stable." And I agree that stabilisation bugs are helping developers
> and everybody should write it when appropriate. But it should not be
> a requirement.
>
> In documentation [1] it is not mentioned a stabilisation bug. Is there
> any other documentation specific for architecture team that have
> higher priorty?
>
> The exception because of security bug, that you mentioned, allows to
> ingnore 30 days + no bugs rule, it has nothing to do with
> stabilisation bugs.
>
> 1. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4
>
> Robert

This is interesting stuff that I didn't know.  So if I've been using
KDevelop 3.3.2 forever
because 3.3.3, 3.3.4, and 3.3.5 are all ~x86, it's not necessarily
because 3.3.5 is
broken, just that nobody's certified it?  How does this happen?
KDevelop is a pretty
big beast, and I'm only going to use the C/C++ part of it.  I'd be
hesitant to proclaim
such a thing ready for prime time based on my usage.

What's the best and most helpful thing for me to do?  Test 3.3.5 (or
whatever) as much
as I can and file a request bug stating what I've tested?  Or just use
it and be damned
with the ~x86?  Something else?

-- 
Kevin O'Gorman, PhD
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable

[Steve Dibb]

Kevin O'Gorman wrote:
>
> This is interesting stuff that I didn't know.  So if I've been using
> KDevelop 3.3.2 forever
> because 3.3.3, 3.3.4, and 3.3.5 are all ~x86, it's not necessarily
> because 3.3.5 is
> broken, just that nobody's certified it?  How does this happen?
> KDevelop is a pretty
> big beast, and I'm only going to use the C/C++ part of it.  I'd be
> hesitant to proclaim
> such a thing ready for prime time based on my usage. 

Well if it's been working for you, just file a stable request bug, post 
your emerge --info and the arch testers and teams will look at it. :)

Thats pretty much how it works.

Steve
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] How packages are made stable - suggestion for improvement

[Daevid Vincent]

This is a little upsetting to learn that effectively "stability" happens as
an after thought. 

I used to run a hybrid of ~x86 and stable, but I've gotten so tired of
seeing new package versions every day, I felt I was spending more time
compiling to get the latest versions, than actually using my system.

I recently just deleted my /etc/portage/package.keywords file and was
figuring that over time, I would then end up with a nice 'stable' system as
each package caught up with the ~x86 one I was using currently. I didn't
want to re-compile / downgrade everything either.

But as I read this thread, it seems that in effect, I won't really be
getting a more stable system, I'll just be getting an older, out of date
one, as nobody is actively monitoring packages and then flagging them as
stable. :(

This feels like there should be some sort of cronjob running in conjunction
with the bug tracker. It could go through every package, and check if it's
version is >= 30 days and also check the number of bugs. If there are some,
it should ping the maintainer (and/or) the developer of said package,
otherwise, it could automatically stabilize the package flag. So on one hand
there is a little prod to get things moving, and on another, some of the
manual task is reduced.

Alternately, how about adding some sort of 'vote' or 'request stability'
button on http://packages.gentoo.org/ for each package's detail page. This
could then help 'automate' the requests and not tie up the bug tracker with
requests (which aren't really bugs per se).

DÆVID  


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable - suggestion for improvement

[Steve Dibb]

Daevid Vincent wrote:
> But as I read this thread, it seems that in effect, I won't really be
> getting a more stable system, I'll just be getting an older, out of date
> one, as nobody is actively monitoring packages and then flagging them as
> stable. :(
>   
The problem, like many other things, comes down simply to manpower.

I should stress, again, that popular, common applications and utilities 
are going to get marked stable on a regular basis.  For the most part, 
its only the small, fringe programs that get lost in the cracks.

And getting some tools in place to display how long packages have been 
unstable is in the works.  Still though, there is just so much work to 
be done in the first place, not many developers go looking for things to 
mark stable.  It makes things a lot simpler if that offload is placed on 
the users instead, because that way 1) we don't focus manpower on 
stabilizing everything just because its been 30 days and 2) we stabilize 
stuff that people are using anyway, and want to get marked stable.

Steve
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable - suggestion for improvement

[David Relson]

On Fri, 05 Jan 2007 17:23:51 -0700
Steve Dibb wrote:

> Daevid Vincent wrote:
> > But as I read this thread, it seems that in effect, I won't really
> > be getting a more stable system, I'll just be getting an older, out
> > of date one, as nobody is actively monitoring packages and then
> > flagging them as stable. :(
> >   
> The problem, like many other things, comes down simply to manpower.
> 
> I should stress, again, that popular, common applications and
> utilities are going to get marked stable on a regular basis.  For the
> most part, its only the small, fringe programs that get lost in the
> cracks.
> 
> And getting some tools in place to display how long packages have
> been unstable is in the works.  Still though, there is just so much
> work to be done in the first place, not many developers go looking
> for things to mark stable.  It makes things a lot simpler if that
> offload is placed on the users instead, because that way 1) we don't
> focus manpower on stabilizing everything just because its been 30
> days and 2) we stabilize stuff that people are using anyway, and want
> to get marked stable.
> 
> Steve

I've been reading this thread as well as the earlier (July) threads
(from gmane) and notice that everyone is discussing "30 days",
"automatic", and "stabilization bugs".  What if there were 2 time
periods - a minimum and a maximum.  For example:

with a 30 day min, a package would have to be bug free for 30 days
before a stabilization bug _could_ be acted upon.

If there are no open bugs and no stabilization bug was submitted , then
a maximum period (perhaps 60 days, perhaps 6 months) would cause an
_automatic_ upgrade to stable.

Having an acceptably large max period would take some of the load off
of developer shoulders and would prevent the current situation of having
really old ~ARCH packges (some of which currently seem to measure in
the hundreds of days).

Just my $.02

David
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How packages are made stable - suggestion for improvement

[Andrey Gerasimenko]

On Sat, 06 Jan 2007 04:24:58 +0300, David Relson  
<relson@osagesoftware.com> wrote:

> On Fri, 05 Jan 2007 17:23:51 -0700
> Steve Dibb wrote:
>
>
> I've been reading this thread as well as the earlier (July) threads
> (from gmane) and notice that everyone is discussing "30 days",
> "automatic", and "stabilization bugs".  What if there were 2 time
> periods - a minimum and a maximum.  For example:
>
> with a 30 day min, a package would have to be bug free for 30 days
> before a stabilization bug _could_ be acted upon.
>
> If there are no open bugs and no stabilization bug was submitted , then
> a maximum period (perhaps 60 days, perhaps 6 months) would cause an
> _automatic_ upgrade to stable.
>
> Having an acceptably large max period would take some of the load off
> of developer shoulders and would prevent the current situation of having
> really old ~ARCH packges (some of which currently seem to measure in
> the hundreds of days).
>
> Just my $.02
>
> David

The problem is that currently all that is stable has been marked so by a  
human being. Adding any automation to the process will change the meaning  
of "stable". I feel that the change will be substantial, like the  
difference between a Google search result and a report from an analyst.

My feeling is that the major part of the users is happy with what we have  
now, that is

- the most stable system that can be constructed with ARCH
- the most recent possibly usable system with ~ARCH
- the most recent system we know about with masked

Looking at the list, I feel that the key points on the "stable - unstable"  
axis has been marked. Thus, I do not really want to move any of the  
markers, especially the stable one, since it will be bad for those who  
need a really stable system.

My $0.02 is that there are 3 options:

- do nothing, possibly explain the meaning of arch, ~arch, and masked  
better in the docs.
- add a new level of stability, like ^ARCH, and move from ~ARCH to ^ARCH  
automatically.
- encourage development of tools that will make it easier to maintain  
"stable - unstable - deliberately outdated" mixture. Such a tool may,  
among other things, request the list of ~arch packages together with the  
number of days there are no unresolved bug reports other than version bump  
and stabilize.

----
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list