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

2008-12-10 Thread Donnie Berkholz
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


pgpGiqkpi749i.pgp
Description: PGP signature


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

2008-12-10 Thread Donnie Berkholz
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


pgppmEnIvSt8K.pgp
Description: PGP signature


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

2008-11-15 Thread Matti Bickel
Tobias Scherbaum [EMAIL PROTECTED] 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)


pgpaOntcepuKy.pgp
Description: PGP signature


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

2008-11-13 Thread Tobias Scherbaum
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


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


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

2008-11-11 Thread 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

2008-11-11 Thread Jose Luis Rivero

Mark Loeser wrote:

Jose Luis Rivero [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Doc



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

2008-11-11 Thread 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 [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Do



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

2008-11-11 Thread Ferris McCormick
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 [EMAIL PROTECTED]
 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) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Userrel, Trustees)


signature.asc
Description: This is a digitally signed message part


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

2008-11-10 Thread Mark Loeser
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


pgpdydl9hHo6Z.pgp
Description: PGP signature


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

2008-11-10 Thread Ciaran McCreesh
On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

2008-11-10 Thread Mart Raudsepp
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: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part


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

2008-11-10 Thread Steev Klimaszewski
On Mon, Nov 10, 2008 at 12:23 PM, Mart Raudsepp [EMAIL PROTECTED] 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

2008-11-10 Thread 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

2008-11-10 Thread Santiago M. Mola
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: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


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

2008-11-10 Thread 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 [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Doc




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

2008-11-10 Thread Mark Loeser
Jose Luis Rivero [EMAIL PROTECTED] 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


pgpS6lqfqSAGz.pgp
Description: PGP signature


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

2008-11-10 Thread 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?