Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Richard Freeman <rich@thefreemanclan.net>]

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

Fernando J. Pereda wrote:
> Some of the packages I maintain are better removed when a new
> maintenance version is released. And I plan to keep it that way :)
> 

Can you clarify this?  What scenarios do you run into where it isn't 
good for stable users to have access to more than one version of the 
software?

One thing that I noticed is that in many cases there are multiple 
testing versions of a package available, and one stable version.  So, if 
you run unstable you can pick and choose, but if you're running stable 
(which in theory should be the target audience gentoo aims for) then you 
get your choice of only one.

I tend to think that unless something unusual is going on that old 
packages should be kept around for a while (a few weeks at least).  The 
same should apply to packages in testing as well.  Actually, that could 
be a whole separate topic.  There have been many times that I've had to 
upgrade to a package in testing to get some needed feature, but then it 
gets deleted in favor of some other package in testing - and the stable 
package sits at its current version for ages.  Unless a package in 
testing has a reasonably serious problem of some kind it would seem to 
make more sense to me to have ebuilds not removed until they've been 
stabilized and then obsoleted.  An exception would be revision bumps - 
no sense stabilizing an ebuild revision that has a simple bugfix 
available without an upstream version change.

Others have pointed out that inflexible rules aren't always the answer. 
  I'd agree in general, but there should be guidelines.  Maybe certain 
packages shouldn't have multiple stable versions to choose from.  But 
when "certain packages" becomes 80% of them then I'd wonder if there 
really is a good reason for this...

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]