[gentoo-dev] Proposal for how to handle stable ebuilds

[gentoo-dev] Proposal for how to handle stable ebuilds

[Mark Loeser]

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

Instead of addressing archs as being slackers or not, this addresses it
as a more granular layer of looking at ebuilds.  Thanks to Richard
Freeman for the initial proposal that I based this off of.  Please give me
feedback on this proposal, if you think it sucks (preferably with an
explanation why), or if you think it might work.

Ebuild Stabilization Time

Arch teams will normally have 30 days from the day a bug was filed, keyworded
STABLEREQ, the arch was CCed, and the maintainer either filed the bug or
commented that it was OK to stabilize (clock starts when all of these
conditions are met).

Security bugs are to be handled by the policies the Security Team has
established.

Technical Problems with Ebuild Revisions

If an arch team finds a technical problem with an ebuild preventing
stabilization, a bug will be logged as a blocker for the keyword request.  The
bug being resolved resets the time for the 30 days the arch team has to mark
the ebuild stable.

Removing Stable Ebuilds

If an ebuild meets the time criteria above, and there are no technical issues
preventing stabilization, then the maintainer MAY choose to delete an older
version even if it is the most recent stable version for a particular arch.

If an ebuild meets the time criteria above, but there is a technical issue
preventing stabilization, and there are no outstanding security issues, then
the maintainer MUST not remove the highest-versioned stable ebuild for any
given arch without the approval of the arch team.

Security issues are to be handled by the recommendations of the Security Team.

Spirit of Cooperation

Ebuild maintainer and arch teams are encouraged to work together for the sake
of each other and end users in facilitating the testing and maintenance of
ebuilds on obscure hardware, or where obscure expertise is needed.  Package
maintainers are encouraged to use discretion when removing ebuilds in
accordance with this policy.


--
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

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

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Ciaran McCreesh]

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

On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser <halcy0n@gentoo.org> wrote:
> Arch teams will normally have 30 days from the day a bug was filed,
> keyworded STABLEREQ, the arch was CCed, and the maintainer either
> filed the bug or commented that it was OK to stabilize (clock starts
> when all of these conditions are met).

30 days is a minimum, not a maximum.

> If an ebuild meets the time criteria above, and there are no
> technical issues preventing stabilization, then the maintainer MAY
> choose to delete an older version even if it is the most recent
> stable version for a particular arch.

All this does is screw over users. The impact of a forced downgrade is
far higher than the impact of leaving things in the tree for as long as
is necessary.

You are proposing giving maintainers carte blanche to screw over users
and encouraging rather than reducing the kind of "us vs them" behaviour
that a few package maintainers like to engage in where arch teams are
treated as being in the way rather than there to help.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Mart Raudsepp]

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

On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote:
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no technical issues
> preventing stabilization, then the maintainer MAY choose to delete an older
> version even if it is the most recent stable version for a particular arch.

Even if that is a package that other packages depend on? Lets say I want
to delete an ancient version of gtk+, but arch ABC has that as the only
stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and
break the whole stable tree of arch ABC, unkeyword hundreds of other
packages, or I'm just allowed to remove it but should really apply a
common sense as usual and you don't want to go into details in this
document?


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Steev Klimaszewski]

On Mon, Nov 10, 2008 at 12:23 PM, Mart Raudsepp <leio@gentoo.org> wrote:
> On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote:
>> Removing Stable Ebuilds
>>
>> If an ebuild meets the time criteria above, and there are no technical issues
>> preventing stabilization, then the maintainer MAY choose to delete an older
>> version even if it is the most recent stable version for a particular arch.
>
> Even if that is a package that other packages depend on? Lets say I want
> to delete an ancient version of gtk+, but arch ABC has that as the only
> stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and
> break the whole stable tree of arch ABC, unkeyword hundreds of other
> packages, or I'm just allowed to remove it but should really apply a
> common sense as usual and you don't want to go into details in this
> document?

*MAY* choose - you don't *have* to do it - I'd prefer something along
the lines of, may stablize it - if after a minimum of 30 days - maybe
90 days max - if the arch team hasn't had enough time to stablize
it... when will they ever?

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Jeremy Olexa]

Mark Loeser wrote:
<snip>

I really don't understand why it is better to break the stable trees of 
$ARCH instead of just making them all ~ARCH. (ie. ~mips, ~x86-fbsd, 
etc). If the $ARCH doesn't have the manpower to do stable reqs then they 
don't have the manpower to fix broken stable trees either or do security 
bugs. So, IMHO, this proposal doesn't solve anything. With the key 
problem being that the 'slacker' arches can't keep up with the stable 
reqs and hence a large number of stale ebuilds and stale bugs being kept 
around.

-Jeremy

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Santiago M. Mola]

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

El lun, 10-11-2008 a las 13:13 -0500, Mark Loeser escribió:
> 
> Ebuild Stabilization Time
> 
> Arch teams will normally have 30 days from the day a bug was filed, keyworded
> STABLEREQ, the arch was CCed, and the maintainer either filed the bug or
> commented that it was OK to stabilize (clock starts when all of these
> conditions are met).

> 
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no technical issues
> preventing stabilization, then the maintainer MAY choose to delete an older
> version even if it is the most recent stable version for a particular arch.
> 
> If an ebuild meets the time criteria above, but there is a technical issue
> preventing stabilization, and there are no outstanding security issues, then
> the maintainer MUST not remove the highest-versioned stable ebuild for any
> given arch without the approval of the arch team.
> 
> Security issues are to be handled by the recommendations of the Security Team.
> 

If this proposal had been approved a year ago as is, amd64 stable
keywords could have been dropped all over the place, making stable tree
unsupported on amd64 de facto (guess how many users would have left
Gentoo) and agravating our past workload problems.

So the consequences of this policy being applied on a regular basis can
be far worse than arches lagging behind.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Jose Luis Rivero]

Mark Loeser wrote:
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no technical issues
> preventing stabilization, then the maintainer MAY choose to delete an older
> version even if it is the most recent stable version for a particular arch.

Mark, I think you are looking at the problem only with the ebuild 
maintainer hat put on. We have other players in our business, being one 
of them the users. This policy would bring too many problems to them so 
.. nono by my side.

I would prefer to analyze the causes of the slacker arch (manpower, 
hardware, etc) and if we are not able to solve the problem by any way 
(asking for new devs, buying hardware, etc) go for mark it as 
experimental and drop all stable keywords.

Thanks.

-- 
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Alpha Gentoo/Doc

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Mark Loeser]

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

Jose Luis Rivero <yoswink@gentoo.org> said:
> Mark Loeser wrote:
>> Removing Stable Ebuilds
>> If an ebuild meets the time criteria above, and there are no technical 
>> issues
>> preventing stabilization, then the maintainer MAY choose to delete an 
>> older
>> version even if it is the most recent stable version for a particular 
>> arch.
>
> Mark, I think you are looking at the problem only with the ebuild 
> maintainer hat put on. We have other players in our business, being one of 
> them the users. This policy would bring too many problems to them so .. 
> nono by my side.

I purposely did this.  I like the proposal, but I also know that it has
a lot of problems.  It was better than sending something out asking what
people think though.

> I would prefer to analyze the causes of the slacker arch (manpower, 
> hardware, etc) and if we are not able to solve the problem by any way 
> (asking for new devs, buying hardware, etc) go for mark it as experimental 
> and drop all stable keywords.

This is one way to resolve it.  We need to establish how an arch gets
pushed to "experimental" and how maintainers need to deal with that
though.  An example is removing the only version of a package that works
on that specific arch, is this a problem if the arch is declared to be
experimental?

If this is the path we want to go down, lets set up some rules for how
to handle experimental archs and what it means to go from
stable->experimental and experimental->stable.

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

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

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Jose Luis Rivero]

Mark Loeser wrote:
> Jose Luis Rivero <yoswink@gentoo.org> said:
>> Mark, I think you are looking at the problem only with the ebuild 
>> maintainer hat put on. We have other players in our business, being one of 
>> them the users. This policy would bring too many problems to them so .. 
>> nono by my side.
> 
> I purposely did this.  I like the proposal, but I also know that it has
> a lot of problems.  It was better than sending something out asking what
> people think though.

Indeed.

>> I would prefer to analyze the causes of the slacker arch (manpower, 
>> hardware, etc) and if we are not able to solve the problem by any way 
>> (asking for new devs, buying hardware, etc) go for mark it as experimental 
>> and drop all stable keywords.
> 
> This is one way to resolve it.  We need to establish how an arch gets
> pushed to "experimental" and how maintainers need to deal with that
> though.  An example is removing the only version of a package that works
> on that specific arch, is this a problem if the arch is declared to be
> experimental?
> 
> If this is the path we want to go down, lets set up some rules for how
> to handle experimental archs and what it means to go from
> stable->experimental and experimental->stable.

Now we are thinking the same, brother. Clear procedures and rules for 
moving an arch to experimental and what keyword policy applies to 
experimental. Also, what is needed to allow an experimental arch to 
start its stable branch and be sure we are not going to be moving from 
experimental <-> stable every month.

If someone want to start thinking more seriously about this, count me in.

--
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Alpha Gentoo/Doc

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Richard Freeman]

Jose Luis Rivero wrote:
> I would prefer to analyze the causes of the slacker arch (manpower, 
> hardware, etc) and if we are not able to solve the problem by any way 
> (asking for new devs, buying hardware, etc) go for mark it as 
> experimental and drop all stable keywords.

How is that better?  Instead of dropping one stable package you'd end up 
dropping all of them.  A user could accept ~arch and get the same 
behavior without any need to mark every other package in the tree 
unstable.  An arch could put a note to that effect in their installation 
handbook.  The user could then choose between a very narrow core of 
stable packages or a wider universe of experimental ones.

I guess the question is whether package maintainers should be forced to 
maintain packages that are outdated by a significant period of time. 
Suppose something breaks a package that is 3 versions behind stable on 
all archs but one (where it is the current stable).  Should the package 
maintainer be required to fix it, rather than just delete it?  I suspect 
that the maintainer would be more likely to just leave it broken, which 
doesn't exactly leave things better-off for the end users.

I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise 
discretion on removing stable versions of these packages.  However, for 
some obscure utility that next-to-nobody uses, does it really hurt to 
move from stable back to unstable if the arch maintainers can't keep up?

I guess it comes down to the driving issues.  How big a problem are 
stale packages (with the recent movement of a few platforms to 
experimental, is this an already-solved problem?)?  How big of a problem 
do arch teams see keeping up with 30-days as (or maybe 60/90)?  What are 
the practical (rather than theoretical) ramifications?

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Peter Volkov]

Why it's so hard not to delete ebuilds from the tree? Also it was
already discussed that if maintainer wishes he/she could drop some
keywords from old ebuild, e.g. if you have more recent version of
package stabilized on arch, just drop arch keyword from the old ebuild.

В Пнд, 10/11/2008 в 20:21 -0500, Richard Freeman пишет:
> I guess the question is whether package maintainers should be forced
> to maintain packages that are outdated by a significant period of
> time. Suppose something breaks a package that is 3 versions behind
> stable on all archs but one (where it is the current stable).  Should
> the package maintainer be required to fix it, rather than just delete
> it?  I suspect that the maintainer would be more likely to just leave
> it broken, which doesn't exactly leave things better-off for the end
> users.

The package maintainer just should add depend on stabilization bug and
leave resolution of the issue to arch team. Package maintainer already
fixed things on his end so he has nothing to do...

-- 
Peter.

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Jose Luis Rivero]

Richard Freeman wrote:
> Jose Luis Rivero wrote:
>> I would prefer to analyze the causes of the slacker arch (manpower, 
>> hardware, etc) and if we are not able to solve the problem by any way 
>> (asking for new devs, buying hardware, etc) go for mark it as 
>> experimental and drop all stable keywords.
> 
> How is that better?  Instead of dropping one stable package you'd end up 
> dropping all of them.  A user could accept ~arch and get the same 
> behavior without any need to mark every other package in the tree 
> unstable.  

Accept ~arch for the random package which has lost the stable keyword a 
random day? And next week .. which is going to be the next? The key is 
the concept 'stable' and what you hope of it.

A long/middle-term solution for arches with very few resources instead 
of generating problems to users seems a much better approach to me.

> An arch could put a note to that effect in their installation 
> handbook.  The user could then choose between a very narrow core of 
> stable packages or a wider universe of experimental ones.

Mixing software branches is very easy in the Gentoo world but it has 
some problems. Are you going to install in your stable (production, 
critial, important,...) system a combination of packages not tested 
before? Because the arch teams or the maintainers are not going to test 
every posible combination of core stable + universe of experimental 
packages. This is why branches exists.

> I guess the question is whether package maintainers should be forced to 
> maintain packages that are outdated by a significant period of time. 
> Suppose something breaks a package that is 3 versions behind stable on 
> all archs but one (where it is the current stable).  Should the package 
> maintainer be required to fix it, rather than just delete it?  

Maintainer has done all he can do, this means: that is broken, this 
version fix the problem, go for it. Maintainer's job finishes here, now 
  it's the problem of your favorite arch team.

> I suspect 
> that the maintainer would be more likely to just leave it broken, which 
> doesn't exactly leave things better-off for the end users.

It's a different approach (maybe with the same bad results) but 
different anyway. Leave the bug there, point the user to the bug and 
maybe you can gain a new dev or an arch tester.

While the proposal made here is to throw random keyword problems to 
users by policy (which in the case of amd64 some months ago would have 
created a complete disaster).

> I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise 
> discretion on removing stable versions of these packages.  However, for 
> some obscure utility that next-to-nobody uses, does it really hurt to 
> move from stable back to unstable if the arch maintainers can't keep up?

Special cases and special plans are allowed, what we are discussing here 
is a general and accepted policy.

> I guess it comes down to the driving issues.  How big a problem are 
> stale packages (with the recent movement of a few platforms to 
> experimental, is this an already-solved problem?)?  How big of a problem 
> do arch teams see keeping up with 30-days as (or maybe 60/90)?  What are 
> the practical (rather than theoretical) ramifications?

An interesting discussion. Ask our council to listen all parts: 
maintainers, current arch teams, the experience of mips, etc. and try to 
make a good choice.

Thanks Richard.

--
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Alpha Gentoo/Do

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Ferris McCormick]

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

On Tue, 2008-11-11 at 11:18 +0100, Jose Luis Rivero wrote:
> Richard Freeman wrote:
> > Jose Luis Rivero wrote:
> >> I would prefer to analyze the causes of the slacker arch (manpower, 
> >> hardware, etc) and if we are not able to solve the problem by any way 
> >> (asking for new devs, buying hardware, etc) go for mark it as 
> >> experimental and drop all stable keywords.
> > 
> > How is that better?  Instead of dropping one stable package you'd end up 
> > dropping all of them.  A user could accept ~arch and get the same 
> > behavior without any need to mark every other package in the tree 
> > unstable.  
> 
> Accept ~arch for the random package which has lost the stable keyword a 
> random day? And next week .. which is going to be the next? The key is 
> the concept 'stable' and what you hope of it.
> 
> A long/middle-term solution for arches with very few resources instead 
> of generating problems to users seems a much better approach to me.
> 
> > An arch could put a note to that effect in their installation 
> > handbook.  The user could then choose between a very narrow core of 
> > stable packages or a wider universe of experimental ones.
> 
> Mixing software branches is very easy in the Gentoo world but it has 
> some problems. Are you going to install in your stable (production, 
> critial, important,...) system a combination of packages not tested 
> before? Because the arch teams or the maintainers are not going to test 
> every posible combination of core stable + universe of experimental 
> packages. This is why branches exists.
> 
> > I guess the question is whether package maintainers should be forced to 
> > maintain packages that are outdated by a significant period of time. 
> > Suppose something breaks a package that is 3 versions behind stable on 
> > all archs but one (where it is the current stable).  Should the package 
> > maintainer be required to fix it, rather than just delete it?  
> 
> Maintainer has done all he can do, this means: that is broken, this 
> version fix the problem, go for it. Maintainer's job finishes here, now 
>   it's the problem of your favorite arch team.
> 
> > I suspect 
> > that the maintainer would be more likely to just leave it broken, which 
> > doesn't exactly leave things better-off for the end users.
> 
> It's a different approach (maybe with the same bad results) but 
> different anyway. Leave the bug there, point the user to the bug and 
> maybe you can gain a new dev or an arch tester.
> 
> While the proposal made here is to throw random keyword problems to 
> users by policy (which in the case of amd64 some months ago would have 
> created a complete disaster).
> 
> > I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise 
> > discretion on removing stable versions of these packages.  However, for 
> > some obscure utility that next-to-nobody uses, does it really hurt to 
> > move from stable back to unstable if the arch maintainers can't keep up?
> 
> Special cases and special plans are allowed, what we are discussing here 
> is a general and accepted policy.
> 
> > I guess it comes down to the driving issues.  How big a problem are 
> > stale packages (with the recent movement of a few platforms to 
> > experimental, is this an already-solved problem?)?  How big of a problem 
> > do arch teams see keeping up with 30-days as (or maybe 60/90)?  What are 
> > the practical (rather than theoretical) ramifications?
> 
> An interesting discussion. Ask our council to listen all parts: 
> maintainers, current arch teams, the experience of mips, etc. and try to 
> make a good choice.
> 
> Thanks Richard.
> 
> --
> Jose Luis Rivero <yoswink@gentoo.org>
> Gentoo/Alpha Gentoo/Do
> 

Very interesting discussion.  Let me take a more or less random post and
toss in a slight variation.  As you might know, I am an arch maintainer
(sparc) and I don't think we are a "slacker architecture."  However, I
have placed an indefinite hold on a stabalization request from the
bug-that-must-not-be-named, because in my opinion this package given the
current state of everything should not go stable on sparc (more QA
issues than functional ones).

How, I wonder, would the variations here handle such a situation?  I
don't think this situation is unique because arch developers are
sometimes going to have a different concept of "stable" than the package
developers do.

If this does not make sense, is off topic, or irrelevant feel free to
ignore it.

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Duncan]

Jose Luis Rivero <yoswink@gentoo.org> posted 49195BFA.7060404@gentoo.org,
excerpted below, on  Tue, 11 Nov 2008 11:18:34 +0100:

> Mixing software branches is very easy in the Gentoo world but it has
> some problems. Are you going to install in your stable (production,
> critial, important,...) system a combination of packages not tested
> before?

Your general post I agree with, but this part...

If it's a "production, critical, important" system, then what is one 
doing installing updates on it directly without verifying them on a 
generally identical test system first?  Either it's not actually so 
important in the grand scheme of things after all, or one will certainly 
find out eventually just how critical said machine is when it goes down 
due to "live" testing on a production critical machine.

Of course, that doesn't excuse a distribution doing its best to ensure 
that doesn't happen, but no distribution is perfect.

-- 
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] Re: Proposal for how to handle stable ebuilds

[Jeroen Roovers]

On Tue, 11 Nov 2008 16:06:02 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> If it's a "production, critical, important" system, then what is one 
> doing installing updates on it directly without verifying them on a 
> generally identical test system first?

Now you're ridiculing the idea of having a "production/ critical/
important" system. Most of our users probably use a single Gentoo
machine (I see many cases where users have multiple machines, but only
one running Gentoo, or have one machine running several operating
systems), and for them an important system is one that they cannot
readily replace. Words like "production", "critical" and "important"
can be applied as easily to the state of a company's or nation's
system as to a single person's.

The stable branch has never been about commercial systems and their
stringent requirements[1] - it's all about this level of quality that
has users up in arms about one package blocking another or one package
requiring half the system to be rebuilt at a rate of no more than once a
year[2].


Kind regards,
     jer


[1] We've had calls for an über-stable project in the past that would
lock down versions and backport patches for enterprise systems.
[2] I.e. when we break the promise of [3].
]3] http://www.gentoo.org/main/en/philosophy.xml

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Duncan]

Jeroen Roovers <jer@gentoo.org> posted
20081111172450.04e02b38@epia.jer-c2.orkz.net, excerpted below, on  Tue, 11
Nov 2008 17:24:50 +0100:

> Words
> like "production", "critical" and "important" can be applied as easily
> to the state of a company's or nation's system as to a single person's.

Yes, but it's a relative thing.  They obviously do what they can with the 
resources they have (are willing to dedicate).  We do the same.  A user's 
single system will absolutely be important to him, no doubt about it, but 
if he doesn't believe it worth "superhuman" feats or prioritizing to 
ensure it's safety, neither should we.  No, we don't go around 
purposefully breaking things, but both he and we have limits to our 
resources and certain priorities in their allocation, and if he's not 
placing undue priority on the safety of his machine, why is it even a 
question if we will?  The presumption should be actions within the bounds 
of rational reality and prioritization of resources for both users and 
their distribution, us.  No more, no less.

IOW, I'd have agreed if the point was that it's a machine that's useful 
to the user and that he doesn't want broken, and we should behave 
accordingly, but the triple emphasis of important, production, critical, 
seemed a bit undue for the lengths to which an ordinary user goes or the 
priority he reveals by his own actions.  And if his actions reveal a 
SERIOUS priority in the area, than he's already covered by definition.  
That's all I was saying.

-- 
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] Re: Proposal for how to handle stable ebuilds

[Ferris McCormick]

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

On Tue, 2008-11-11 at 17:26 +0000, Duncan wrote:
> Jeroen Roovers <jer@gentoo.org> posted
> 20081111172450.04e02b38@epia.jer-c2.orkz.net, excerpted below, on  Tue, 11
> Nov 2008 17:24:50 +0100:
> 
> > Words
> > like "production", "critical" and "important" can be applied as easily
> > to the state of a company's or nation's system as to a single person's.
> 
> Yes, but it's a relative thing.  They obviously do what they can with the 
> resources they have (are willing to dedicate).  We do the same.  A user's 
> single system will absolutely be important to him, no doubt about it, but 
> if he doesn't believe it worth "superhuman" feats or prioritizing to 
> ensure it's safety, neither should we.

I think I understand what you mean here, but it's not what you wrote as
best as I can tell.  As a developer, I believe it is my responsibility
to work a bit harder just so that the users don't have to resort to
'"superhuman" feats' to keep their systems running.  I do agree that no
matter what we provide, all users (including ourselves) will have to
expend some effort to take advantage of it.

> No, we don't go around 
> purposefully breaking things, but both he and we have limits to our 
> resources and certain priorities in their allocation, and if he's not 
> placing undue priority on the safety of his machine, why is it even a 
> question if we will?  The presumption should be actions within the bounds 
> of rational reality and prioritization of resources for both users and 
> their distribution, us.  No more, no less.
> 
> IOW, I'd have agreed if the point was that it's a machine that's useful 
> to the user and that he doesn't want broken, and we should behave 
> accordingly, but the triple emphasis of important, production, critical, 
> seemed a bit undue for the lengths to which an ordinary user goes or the 
> priority he reveals by his own actions.  And if his actions reveal a 
> SERIOUS priority in the area, than he's already covered by definition.  
> That's all I was saying.

Regards,
Ferris

-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Jeroen Roovers]

On Tue, 11 Nov 2008 17:26:51 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> > Words
> > like "production", "critical" and "important" can be applied as
> > easily to the state of a company's or nation's system as to a
> > single person's.

> Yes, but it's a relative thing.
>huge snip<

That's what I said, only in many more words and with a confusing "Yes,
but" at the start, as if you were complementing or correcting what I
said.

> IOW, I'd have agreed if the point was that it's a machine that's
> useful to the user and that he doesn't want broken, and we should
> behave accordingly, but the triple emphasis of important, production,
> critical, seemed a bit undue for the lengths to which an ordinary
> user goes or the priority he reveals by his own actions.  And if his
> actions reveal a SERIOUS priority in the area, than he's already
> covered by definition. That's all I was saying.

Um, you didn't say all of that. In fact you said none of that. You said:

> If it's a "production, critical, important" system, then what is one
> doing installing updates on it directly without verifying them on a
> generally identical test system first?

Users with only one Gentoo system to work with rely on ebuild
maintainers and arch teams to run the "generally identical test
systems" on their behalf (and respectively request and establish what
the stable branch is).

yoswink said this:

> Are you going to install in your stable (production, critial,
> important,...) system a combination of packages not tested before?

He takes "stable" to mean one of three things, or maybe even something
completely different ("...") that some user out there might take to mean
"stable"[1]. Then you rip some of the punctuation out and put these
words in his mouth:

> If it's a "production, critical, important" system,

going on to talk about the discrepancy between best practices in
*corporate* software deployment and ignoring Gentoo's stable branch.

You did it again in the "IOW" quotation above explaining it as a "triple
emphasis" instead of what it was intended to denote, namely as a few
possible examples of the meaning of "stability".


Kind regards,
     jer


[1] To which I responded by pointing to Gentoo's philosophical blurb.

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Duncan]

Jeroen Roovers <jer@gentoo.org> posted
20081111191241.021ce18b@epia.jer-c2.orkz.net, excerpted below, on  Tue, 11
Nov 2008 19:12:41 +0100:

> You did it again in the "IOW" quotation above explaining it as a "triple
> emphasis" instead of what it was intended to denote, namely as a few
> possible examples of the meaning of "stability".

In that case, I misread, as I interpreted the triple as emphasis, not 
alternatives.  If it was intended as alternatives, then yes, it makes 
sense.

Thanks.  I wasn't seeing the alternatives view at all (obviously).

-- 
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] Proposal for how to handle stable ebuilds

[Tobias Scherbaum]

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

Mark Loeser wrote:
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no technical issues
> preventing stabilization, then the maintainer MAY choose to delete an older
> version even if it is the most recent stable version for a particular arch.

What if this would break deps or it's a very common package for example
belonging to the set of system packages?

If we would opt for such a fixed timeframe for architectures teams to
fix bugs I'd like to rate those bugs at least partially like security@
does - that would allow us to have different timeframes for
stabilization depending on how much the package in questions is
(expected to be) installed at our users' systems. 

In my opinion we would need to address two main concerns with this
discussion:
1) What can we do to help understaffed architecture teams?

What about using a tinderbox (yeah, i know - we have lots of tinderboxes
already around) which automatically (re)builds stable-candidates and
those of the candidates which a) includes a test phase and b) pass that
test phase might be stabled by the maintainer/herd and not only the
architecture team, for example?

2) When do we move an architecture back to ~arch?

We would need to define a threshold of when an stable architecture has
to enter a probation period (and who and what's going to start that
process) and a timeframe after which either the architecture is moved
back to ~arch or the architecture team has proven that it is able to
maintain stable keywords (define who's going to decide this).
  
  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Matti Bickel]

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

Tobias Scherbaum <dertobi123@gentoo.org> wrote:
> Mark Loeser wrote:
> > Removing Stable Ebuilds
> > 
> > If an ebuild meets the time criteria above, and there are no technical issues
> > preventing stabilization, then the maintainer MAY choose to delete an older
> > version even if it is the most recent stable version for a particular arch.
> 
> What if this would break deps or it's a very common package for example
> belonging to the set of system packages?

Then the maintainer moans and does nothing. I guess that's where the
"MAY" part from above comes in. Policy should not be an excuse to stop
thinking. And if i break a user system when i drop my stable keywords,
IMHO i'm violating the 'work as pleasently and efficiently as possible'
bit of our philosophy.

It isn't that we have arch teams denying ebuilds their blessing because
they're evil. Maybe they're overworked, maybe they even have a real
life. Or maybe they have stated that your ebuild has QA issues (as
Ferris did), which should be noted and fixed by the maintainer.

So bottom-line: i'm very much in favour of your solution to question #1.
And i'd like to stress the "automatic" bit. Yes, we can get access to
tinderboxes. But last i looked, this involved tracking down the person
responsible for it, asking for access and doing everything you need to
get your package to compile. Well, i'm lazy, so i didn't do it.

Automatic tinderbox testing would very much help in the process. Maybe
someone can write a script so that once a maintainer opens/gives his OK
to a stable bug, automatic testing could be started and the results
posted back to the bug?

After the timeframe (30 days? 60? I don't know, and it's not important
at this point) maintainers could move to stable their package themself
IF the automatic tests indicate success AND no arch member has spoken
up.

just my $0.02
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)

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

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Tobias Scherbaum]

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

Matti Bickel wrote:
> Tobias Scherbaum <dertobi123@gentoo.org> wrote:
> > What if this would break deps or it's a very common package for example
> > belonging to the set of system packages?
> 
> Then the maintainer moans and does nothing. I guess that's where the
> "MAY" part from above comes in. Policy should not be an excuse to stop
> thinking. And if i break a user system when i drop my stable keywords,
> IMHO i'm violating the 'work as pleasently and efficiently as possible'
> bit of our philosophy.

That would people require to use common sense. The past has shown that
people tend to have different views of what common sense might be in a
given case. Therefore policy in that aspect needs to be as clear and
understandable as possible to avoid unnecessary discussions.

> So bottom-line: i'm very much in favour of your solution to question #1.
> And i'd like to stress the "automatic" bit. Yes, we can get access to
> tinderboxes. But last i looked, this involved tracking down the person
> responsible for it, asking for access and doing everything you need to
> get your package to compile. Well, i'm lazy, so i didn't do it.
> 
> Automatic tinderbox testing would very much help in the process. Maybe
> someone can write a script so that once a maintainer opens/gives his OK
> to a stable bug, automatic testing could be started and the results
> posted back to the bug?

Sounds like a very good and doable idea to me. Process might be as easy
as CC'ing a arch-tinderbox on a bug, a script does parse the bug number
out of the mail being sent out and using gatt it catches the ebuild to
test, compiles it and reports back a) failure/success, b) error log as
attachment if it fails plus c) if there was a test-phase.

Might be just a quick hack using pybugz and gatt :)

> After the timeframe (30 days? 60? I don't know, and it's not important
> at this point) maintainers could move to stable their package themself
> IF the automatic tests indicate success AND no arch member has spoken
> up.

Agreed.

  Tobias
-- 
Gentoo Linux - Die Metadistribution
http://www.mitp.de/5941
http://www.metadistribution.eu

https://www.xing.com/profile/Tobias_Scherbaum

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Duncan]

Tobias Scherbaum <dertobi123@gentoo.org> posted
1226945319.3939.30.camel@homer.ob.libexec.de, excerpted below, on  Mon, 17
Nov 2008 19:08:39 +0100:

> Process might be as easy
> as CC'ing a arch-tinderbox on a bug, a script does parse the bug number
> out of the mail being sent out and using gatt it catches the ebuild to
> test, compiles it and reports back a) failure/success, b) error log as
> attachment if it fails plus c) if there was a test-phase.

Surely, you're talking something other than the publicly writable CC 
field, something writable by devs (and maybe ATs) only, right?  Otherwise 
it's a security nightmare.

-- 
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] Proposal for how to handle stable ebuilds

[Donnie Berkholz]

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

On 19:08 Mon 17 Nov     , Tobias Scherbaum wrote:
> That would people require to use common sense. The past has shown that
> people tend to have different views of what common sense might be in a
> given case. Therefore policy in that aspect needs to be as clear and
> understandable as possible to avoid unnecessary discussions.

I'd rather say people need to figure out common sense so we don't need 
to document hundreds of pages of every tiny detail. It seems like the 
vast majority of people don't have a problem with figuring this stuff 
out.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ryan Hill]

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

On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser <halcy0n@gentoo.org> wrote:

> If an ebuild meets the time criteria above, and there are no
> technical issues preventing stabilization, then the maintainer MAY
[...] mark that ebuild as stable on every keyworded arch (that has a
stable keyword).

> If an ebuild meets the time criteria above, but there is a technical
> issue preventing stabilization, and there are no outstanding security
> issues,
[...] the maintainer MUST NOT mark the ebuild stable without the
approval of the arch team.

If technical issues arise after an ebuild is stabilized automatically,
the arch team MAY revert the ebuild to ~arch if another ebuild with a
stable keyword is still available or restore the previous stable ebuild
to the tree if not, until such time that the issue is resolved, or
stabilize a later versioned ebuild that does not exhibit the issue at
the maintainer's approval.

The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the
latest stable ebuild of an arch without the approval of the arch team or
he/she will be fed to the Galrog.


and s/30 days/90 days/g.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Daniel Gryniewicz]

On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:

<snip>

> The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the
> latest stable ebuild of an arch without the approval of the arch team or
> he/she will be fed to the Galrog.

As long as the maintainer can pass off the maintenance of the (sometimes
dozens) of ancient ebuilds that need to be kept around for that one arch
to the arch team, and re-assign any resulting bugs to them, fine.  Or,
alternatively, unilaterally decide to drop all keywords for the arch in
question.

Yes, that was extreme, but no more than the previous quoted statement.
There needs to be give and take here.  Yes, it's really bad to remove
the last stable ebuild for an arch.  However, its *also* bad to have to
maintain years old versions of lots of ebuilds.  And yes, it will be a
lot, since most packages don't exist in a vacuum, and require older deps
(which possibly will be maintained by other maintainers than the first
package, causing a cascade of old packages in the tree).

All this will do in practice is cause maintainers to ignore bugs for
those old packages for those few arches, since the maintainer won't have
that version installed.  In fact, in my experience, they frequently
*can't* have that version installed, since it requires older versions of
other packages that need to be upgraded to maintain newer versions of
the same package.

How much bit rot do we want in the tree?

Daniel (who is both an arch team member and gnome team lead)

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ryan Hill]

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

On Mon, 17 Nov 2008 10:10:57 -0500
Daniel Gryniewicz <dang@gentoo.org> wrote:

> On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:
> 
> <snip>
> 
> > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the
> > latest stable ebuild of an arch without the approval of the arch
> > team or he/she will be fed to the Galrog.
> 
> As long as the maintainer can pass off the maintenance of the
> (sometimes dozens) of ancient ebuilds that need to be kept around for
> that one arch to the arch team, and re-assign any resulting bugs to
> them, fine.

Since when do we maintain ancient ebuilds kept around for an arch
team now?  Drop the other keywords and get on with your life.

> Or, alternatively, unilaterally decide to drop all
> keywords for the arch in question.
> 
> Yes, that was extreme, but no more than the previous quoted statement.

You sir, have an appointment with the Galrog.

> There needs to be give and take here.  Yes, it's really bad to remove
> the last stable ebuild for an arch.  However, its *also* bad to have
> to maintain years old versions of lots of ebuilds.  And yes, it will
> be a lot, since most packages don't exist in a vacuum, and require
> older deps (which possibly will be maintained by other maintainers
> than the first package, causing a cascade of old packages in the
> tree).
> 
> All this will do in practice is cause maintainers to ignore bugs for
> those old packages for those few arches, since the maintainer won't
> have that version installed.  In fact, in my experience, they
> frequently *can't* have that version installed, since it requires
> older versions of other packages that need to be upgraded to maintain
> newer versions of the same package.
> 
> How much bit rot do we want in the tree?
> 
> Daniel (who is both an arch team member and gnome team lead)

Did you not read the first part of the suggestion?  

- maintainer files a stabilization request.
- arch testers do their thing
- arch teams gradually mark ebuild stable
- maintainer pokes arm, sh, mips, ppc (only an example, relax)
- mips reminds maintainer there is no stable mips keyword
- ppc stables
- maintainer waits
- maintainer pokes arm, sh
- maintainer waits
- maintainer marks stable on arm, sh
- maintainer removes ancient stable ebuilds that maintainer doesn't
  want to maintain anymore because everyone has a nice new stable
  ebuild.
- maintainer goes out for a frosty beverage


the idea is that arch teams are around to help the maintainer test on
architectures the maintainer doesn't have.  if the arch teams are
unable or unwilling to help at the moment, that should not stop the
maintainer from maintaining.

also keep in mind that this only occurs after the arch teams have ample
time to interject (which is why i suggested 90 days).  if an arch team
can't comment on a bug in 3 months (a simple "i'd rather this not go
stable until i can test it further" should be enough) then they have
IMO lost their opportunity to matter.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Daniel Gryniewicz]

On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
> On Mon, 17 Nov 2008 10:10:57 -0500
> Daniel Gryniewicz <dang@gentoo.org> wrote:
> 
> > On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:
> > 
> > <snip>
> > 
> > > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the
> > > latest stable ebuild of an arch without the approval of the arch
> > > team or he/she will be fed to the Galrog.
> > 
> > As long as the maintainer can pass off the maintenance of the
> > (sometimes dozens) of ancient ebuilds that need to be kept around for
> > that one arch to the arch team, and re-assign any resulting bugs to
> > them, fine.
> 
> Since when do we maintain ancient ebuilds kept around for an arch
> team now?  Drop the other keywords and get on with your life.

Since forever, at least in my experience.  See below.

> 
> Did you not read the first part of the suggestion?  

Yes.  I was not objecting to this sequence.  I was objecting to the
"MUST NOT NEVER EVER NOT EVEN A LITTLE BIT" part.

> 
> - maintainer files a stabilization request.
> - arch testers do their thing
> - arch teams gradually mark ebuild stable
> - maintainer pokes arm, sh, mips, ppc (only an example, relax)
> - mips reminds maintainer there is no stable mips keyword
> - ppc stables
> - maintainer waits
> - maintainer pokes arm, sh
> - maintainer waits
> - maintainer marks stable on arm, sh
> - maintainer removes ancient stable ebuilds that maintainer doesn't
>   want to maintain anymore because everyone has a nice new stable
>   ebuild.
> - maintainer goes out for a frosty beverage

- Arch team comes back and says the new version doesn't work.
- Maintainer is stuck maintaining the old version *forever*, at least
potentially.

Concrete example.  Gnome was keyworded on an arch.  A new version of
gnome came out that needed hal.  Hal did not work on said arch.  For a
long long time, we had to keep a very old version of gnome in the tree,
just for that arch.  This was a maintenance burden.  Gnome is not just
one or 2 packages.

> 
> the idea is that arch teams are around to help the maintainer test on
> architectures the maintainer doesn't have.  if the arch teams are
> unable or unwilling to help at the moment, that should not stop the
> maintainer from maintaining.
> 
> also keep in mind that this only occurs after the arch teams have ample
> time to interject (which is why i suggested 90 days).  if an arch team
> can't comment on a bug in 3 months (a simple "i'd rather this not go
> stable until i can test it further" should be enough) then they have
> IMO lost their opportunity to matter.

This is not about arches just being slackers.  This is about arches
denying stable (or even ~) for some reason.  If I cannot drop an old
version of something just because the new version doesn't (and won't)
work on an arch, that's really bad for me.

Daniel

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ciaran McCreesh]

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

On Tue, 18 Nov 2008 11:57:23 -0500
Daniel Gryniewicz <dang@gentoo.org> wrote:
> This is not about arches just being slackers.  This is about arches
> denying stable (or even ~) for some reason.  If I cannot drop an old
> version of something just because the new version doesn't (and won't)
> work on an arch, that's really bad for me.

What is the cost of keeping it there and not changing it?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Daniel Gryniewicz]

On Tue, 2008-11-18 at 17:50 +0000, Ciaran McCreesh wrote:
> On Tue, 18 Nov 2008 11:57:23 -0500
> Daniel Gryniewicz <dang@gentoo.org> wrote:
> > This is not about arches just being slackers.  This is about arches
> > denying stable (or even ~) for some reason.  If I cannot drop an old
> > version of something just because the new version doesn't (and won't)
> > work on an arch, that's really bad for me.
> 
> What is the cost of keeping it there and not changing it?
> 

Assuming no one ever uses it?  Just some sync bandwidth, emerge think
time, and disk space.  Not a lot.  However, if people use it, and
especially if they manage to get mixed versions of gnome with it (or new
versions of apps built against it), then we get lots of bugs about it.
Generally, we tend to get lots of interaction bugs about old versions of
gnome.  That's why we try to remove them.

One of the biggest problems is packages not having the correct upstream
deps, since upstream and most distros have moved on to new versions of
gnome.  There's no way we can catch those (since we, too, have moved on
to new versions) and users find them and report them.  Most users I've
encountered don't do --deep upgrades, ever.

I suppose a possible solution would be to de-keyword all those old
versions for all other arches.  That would reduce such reported bugs to
users of the arch in question.  It still leaves something unmaintained
(and probably unmaintainable, except maybe on the target arch) in the
tree marked as stable.  That's a bad thing in-and-of itself.

Daniel

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ryan Hill]

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

On Tue, 18 Nov 2008 11:57:23 -0500
Daniel Gryniewicz <dang@gentoo.org> wrote:

> On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
> > On Mon, 17 Nov 2008 10:10:57 -0500
> > Daniel Gryniewicz <dang@gentoo.org> wrote:
> > 
> > > On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:
> > > 
> > > <snip>
> > > 
> > > > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove
> > > > the latest stable ebuild of an arch without the approval of the
> > > > arch team or he/she will be fed to the Galrog.
> > > 
> > > As long as the maintainer can pass off the maintenance of the
> > > (sometimes dozens) of ancient ebuilds that need to be kept around
> > > for that one arch to the arch team, and re-assign any resulting
> > > bugs to them, fine.
> > 
> > Since when do we maintain ancient ebuilds kept around for an arch
> > team now?  Drop the other keywords and get on with your life.
> 
> Since forever, at least in my experience.  See below.
> 
> > 
> > Did you not read the first part of the suggestion?  
> 
> Yes.  I was not objecting to this sequence.  I was objecting to the
> "MUST NOT NEVER EVER NOT EVEN A LITTLE BIT" part.
> 
> > 
> > - maintainer files a stabilization request.
> > - arch testers do their thing
> > - arch teams gradually mark ebuild stable
> > - maintainer pokes arm, sh, mips, ppc (only an example, relax)
> > - mips reminds maintainer there is no stable mips keyword
> > - ppc stables
> > - maintainer waits
> > - maintainer pokes arm, sh
> > - maintainer waits
> > - maintainer marks stable on arm, sh
> > - maintainer removes ancient stable ebuilds that maintainer doesn't
> >   want to maintain anymore because everyone has a nice new stable
> >   ebuild.
> > - maintainer goes out for a frosty beverage
> 
> - Arch team comes back and says the new version doesn't work.
> - Maintainer is stuck maintaining the old version *forever*, at least
> potentially.

See, here's your problem.  If the arch team has issues and needs an
old ebuild, the arch team is effectively the maintainer of that
ebuild.  Drop the other keywords if you like, and forget it exists.

> Concrete example.  Gnome was keyworded on an arch.  A new version of
> gnome came out that needed hal.  Hal did not work on said arch.  For a
> long long time, we had to keep a very old version of gnome in the
> tree, just for that arch.  This was a maintenance burden.  Gnome is
> not just one or 2 packages.

So you would rather have the ability to just drop the keywords on
this arch and leave them and their gnome users up the creek?

> > the idea is that arch teams are around to help the maintainer test
> > on architectures the maintainer doesn't have.  if the arch teams are
> > unable or unwilling to help at the moment, that should not stop the
> > maintainer from maintaining.
> > 
> > also keep in mind that this only occurs after the arch teams have
> > ample time to interject (which is why i suggested 90 days).  if an
> > arch team can't comment on a bug in 3 months (a simple "i'd rather
> > this not go stable until i can test it further" should be enough)
> > then they have IMO lost their opportunity to matter.
> 
> This is not about arches just being slackers.  This is about arches
> denying stable (or even ~) for some reason.  If I cannot drop an old
> version of something just because the new version doesn't (and won't)
> work on an arch, that's really bad for me.

I know I've been oversimplifying things thus far, and I understand this
is a real problem for you.  However, I believe that as bad as it is for
you, dumping the problem on the user is the greater evil.

And yes, this is not an attempt to solve everything - it is directly
aimed at the slacker problem, which i think is the biggest part of the
issue.  Other problems will need other solutions.

In any case, if you still think it's unworkable and dropping keywords
is the correct solution, I won't continue pushing it.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Daniel Gryniewicz]

On Tue, 2008-11-18 at 15:18 -0600, Ryan Hill wrote:
> On Tue, 18 Nov 2008 11:57:23 -0500
> Daniel Gryniewicz <dang@gentoo.org> wrote:
> 
> > On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
> > > On Mon, 17 Nov 2008 10:10:57 -0500
> > > Daniel Gryniewicz <dang@gentoo.org> wrote:
> > > 
> > > > On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:
> > > > 
> > > > <snip>
> > > > 
> > > > > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove
> > > > > the latest stable ebuild of an arch without the approval of the
> > > > > arch team or he/she will be fed to the Galrog.
> > > > 
> > > > As long as the maintainer can pass off the maintenance of the
> > > > (sometimes dozens) of ancient ebuilds that need to be kept around
> > > > for that one arch to the arch team, and re-assign any resulting
> > > > bugs to them, fine.
> > > 
> > > Since when do we maintain ancient ebuilds kept around for an arch
> > > team now?  Drop the other keywords and get on with your life.
> > 
> > Since forever, at least in my experience.  See below.
> > 
> > > 
> > > Did you not read the first part of the suggestion?  
> > 
> > Yes.  I was not objecting to this sequence.  I was objecting to the
> > "MUST NOT NEVER EVER NOT EVEN A LITTLE BIT" part.
> > 
> > > 
> > > - maintainer files a stabilization request.
> > > - arch testers do their thing
> > > - arch teams gradually mark ebuild stable
> > > - maintainer pokes arm, sh, mips, ppc (only an example, relax)
> > > - mips reminds maintainer there is no stable mips keyword
> > > - ppc stables
> > > - maintainer waits
> > > - maintainer pokes arm, sh
> > > - maintainer waits
> > > - maintainer marks stable on arm, sh
> > > - maintainer removes ancient stable ebuilds that maintainer doesn't
> > >   want to maintain anymore because everyone has a nice new stable
> > >   ebuild.
> > > - maintainer goes out for a frosty beverage
> > 
> > - Arch team comes back and says the new version doesn't work.
> > - Maintainer is stuck maintaining the old version *forever*, at least
> > potentially.
> 
> See, here's your problem.  If the arch team has issues and needs an
> old ebuild, the arch team is effectively the maintainer of that
> ebuild.  Drop the other keywords if you like, and forget it exists.

Leaving unmaintained ebuilds in the tree.  If that's what people want,
that's fine with me.

> 
> > Concrete example.  Gnome was keyworded on an arch.  A new version of
> > gnome came out that needed hal.  Hal did not work on said arch.  For a
> > long long time, we had to keep a very old version of gnome in the
> > tree, just for that arch.  This was a maintenance burden.  Gnome is
> > not just one or 2 packages.
> 
> So you would rather have the ability to just drop the keywords on
> this arch and leave them and their gnome users up the creek?

No.  But I also don't want any policy that forbids me from ever removing
that ebuild.  Which is what the above is proposing.  I don't want any
kind of absolutes in policy.  If you advocate absolutes in favor of the
arch teams to the detriment of the maintainers, then the maintainers are
going to ask for absolutes (such as I asked for above) in retaliation,
and we'll have a thermonuclear meltdown.  That's all.

Honestly, I don't want to be a dick to the arch teams.  I really don't.
But I *also* don't want them (or policy) to be a dick to me.  That's my
whole point; that requirement of never removing the last stable ebuild,
in shouting caps no less, is way too absolute, and is just going to piss
people like me off.

I think the whole policy should be more-or-less "Don't be a dick.  Take
the other guy into account."  Leave shouting-caps absolute requirements
out of it.

(For what it's worth, with my arch team hat on, I'm not in favor of
letting anyone mark things stable on arches they can't test on.  But
that's a much lesser issue IMO than absolute prohibitions on removing
ebuilds.)

Daniel

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ryan Hill]

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

On Tue, 18 Nov 2008 17:04:33 -0500
Daniel Gryniewicz <dang@gentoo.org> wrote:

> Honestly, I don't want to be a dick to the arch teams.  I really
> don't. But I *also* don't want them (or policy) to be a dick to me.
> That's my whole point; that requirement of never removing the last
> stable ebuild, in shouting caps no less, is way too absolute, and is
> just going to piss people like me off.

For the record, the all in caps bit was a tongue-in-cheek reference to
the ultra-formal format that the IETF RFC's are in that was being
emulated here.  It was included for levity, not for shouting.

http://www.rfc-editor.org/rfc/rfc2119.txt


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

[gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Ryan Hill]

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

On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser <halcy0n@gentoo.org> wrote:

> Instead of addressing archs as being slackers or not, this addresses
> it as a more granular layer of looking at ebuilds.  Thanks to Richard
> Freeman for the initial proposal that I based this off of.  Please
> give me feedback on this proposal, if you think it sucks (preferably
> with an explanation why), or if you think it might work.
> 
> Ebuild Stabilization Time
> 
> Arch teams will normally have 30 days from the day a bug was filed,
> keyworded STABLEREQ, the arch was CCed, and the maintainer either
> filed the bug or commented that it was OK to stabilize (clock starts
> when all of these conditions are met).
> 
> Security bugs are to be handled by the policies the Security Team has
> established.
> 
> Technical Problems with Ebuild Revisions
> 
> If an arch team finds a technical problem with an ebuild preventing
> stabilization, a bug will be logged as a blocker for the keyword
> request.  The bug being resolved resets the time for the 30 days the
> arch team has to mark the ebuild stable.
> 
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no
> technical issues preventing stabilization, then the maintainer MAY
> choose to delete an older version even if it is the most recent
> stable version for a particular arch.
> 
> If an ebuild meets the time criteria above, but there is a technical
> issue preventing stabilization, and there are no outstanding security
> issues, then the maintainer MUST not remove the highest-versioned
> stable ebuild for any given arch without the approval of the arch
> team.
> 
> Security issues are to be handled by the recommendations of the
> Security Team.
> 
> Spirit of Cooperation
> 
> Ebuild maintainer and arch teams are encouraged to work together for
> the sake of each other and end users in facilitating the testing and
> maintenance of ebuilds on obscure hardware, or where obscure
> expertise is needed.  Package maintainers are encouraged to use
> discretion when removing ebuilds in accordance with this policy.

Since I completely stalled out this conversation I guess it's only fair
that I try to restart it.  I'm in favor of the above.

I know it's not directly related to stabilization, but lately people
have been removing the only keyworded package for the mips arch, under
the excuse that's it's been over 30 days since they opened a keywording
bug.  This has been happening on bugs where there are technical issues
and on bugs where we just haven't replied (in which case i can see the
justification).  I don't think this is acceptable, just as I don't
think removing the only stable version of a package on an arch is
be acceptable, barring the circumstances Mark outlined above.

Yes?  No?  Get out of our treehouse?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

[Peter Volkov]

В Вск, 30/11/2008 в 16:59 -0600, Ryan Hill пишет:
> On Mon, 10 Nov 2008 13:13:34 -0500
> Mark Loeser <halcy0n@gentoo.org> wrote:
> > [proposal]

> I know it's not directly related to stabilization, but lately people
> have been removing the only keyworded package for the mips arch, under
> the excuse that's it's been over 30 days since they opened a keywording
> bug.  This has been happening on bugs where there are technical issues
> and on bugs where we just haven't replied (in which case i can see the
> justification).  I don't think this is acceptable, just as I don't
> think removing the only stable version of a package on an arch is
> be acceptable, barring the circumstances Mark outlined above.

That people should revert back that ebuilds then. Of course it's not
acceptable to remove keywords just because of one's wishes. As it was
told in this thread old ebuilds are not maintainer's concern and he/she
could touch them only after all arch teams finish their work. Until they
done all bugs in old ebuilds should be assigned on arch teams.

-- 
Peter.

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Donnie Berkholz]

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

On 13:13 Mon 10 Nov     , Mark Loeser wrote:
> Instead of addressing archs as being slackers or not, this addresses it
> as a more granular layer of looking at ebuilds.  Thanks to Richard
> Freeman for the initial proposal that I based this off of.  Please give me
> feedback on this proposal, if you think it sucks (preferably with an
> explanation why), or if you think it might work.

I'm not convinced why this needs to happen, because there's no reasoning 
behind it here. There needs to be rationale for why this should happen 
with pros and cons. dang mentioned a few pros from the maintainer side, 
the arch team ones are pretty easy to come up with.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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