Re: [gentoo-dev] rfc: stabilization policies

[Michael Orlitzky]

On 08/20/2013 02:19 PM, William Hubbs wrote:
> My question is, how can we improve our stabilization procedures/policies
> so we can convince people not to run production servers on ~arch and
> keep the stable tree more up to date?

Just delete /etc/conf.d/net with an ~arch update every once in a while,
that should convince them =)

Stable is fine for the most part. The bitrot complaint is basically "I
can't be bothered to add packages to
/etc/portage/package.accept_keywords individually."

Most of our servers have one or two packages in there, for which I've
already filed a stabilization bug. Web servers are the worst, because
we have to listen to our customers occasionally. Here is our largest
package.accept_keywords (comments added):

> =dev-php/pecl-zendopcache-7.0.2 ~amd64

PHP 5.5 is coming to stable soon, so we wanted to test this early. It
belongs in ~arch, though. Nothing to see here.

> # Should get this stabled.
> =dev-php/smarty-3.1.12 ~amd64

Just filed https://bugs.gentoo.org/show_bug.cgi?id=481780

> =sys-boot/grub-2.00-r2 ~amd64

We upgraded grub at the same time as the udev mess. The upgrade failed
on several systems (which needed to be repartitioned, ugh), but the
upgrade is opt-in since grub-legacy keeps working.

> # Our overlay
> */*::viabit-overlay ~amd64

Nothing to see here. Our company overlay.

> net-mail/postfix-logwatch ~amd64

This is stuck in Sunrise. https://bugs.gentoo.org/show_bug.cgi?id=309075

> # https://bugs.gentoo.org/show_bug.cgi?id=448558
> # https://bugs.gentoo.org/show_bug.cgi?id=475962
> =dev-php/PEAR-Mail_Mime-1.8.8 ~amd64

This isn't even in the tree, so it doesn't count. But it does fix an
annoyance, so if anyone is listening, please bump it!

> # Redmine
> =dev-ruby/builder-3.1.4 ~amd64
> =dev-ruby/rails-3.2.13 ~amd64
> =dev-ruby/railties-3.2.13 ~amd64
> =dev-ruby/actionmailer-3.2.13 ~amd64
> =dev-ruby/builder-3.0.4 ~amd64
> =dev-ruby/arel-3.0.2-r1 ~amd64
> =dev-ruby/rack-cache-1.2 ~amd64
> =dev-ruby/rack-openid-1.3.1 ~amd64
> =dev-ruby/thor-0.15.2 ~amd64
> =dev-ruby/activemodel-3.2.13 ~amd64
> =dev-ruby/sprockets-2.2.2 ~amd64
> =dev-ruby/sass-rails-3.2.6 ~amd64
> =dev-ruby/coffee-script-source-1.6.2 ~amd64
> =dev-ruby/activerecord-3.2.13 ~amd64
> =dev-ruby/rack-ssl-1.3.2 ~amd64
> =dev-ruby/mail-2.5.3 ~amd64
> =dev-ruby/activeresource-3.2.13 ~amd64
> =net-libs/nodejs-0.10.15 ~amd64
> =dev-ruby/journey-1.0.4 ~amd64
> =dev-ruby/hike-1.2.3 ~amd64
> =dev-ruby/i18n-0.6.4 ~amd64
> =dev-ruby/coffee-rails-3.2.2 ~amd64
> =dev-ruby/treetop-1.4.10-r1 ~amd64
> =dev-ruby/activesupport-3.2.13 ~amd64
> =dev-ruby/coffee-script-2.2.0 ~amd64
> =dev-ruby/polyglot-0.3.3 ~amd64
> =dev-ruby/jquery-rails-2.3.0 ~amd64
> =dev-ruby/actionpack-3.2.13 ~amd64
> =dev-ruby/execjs-1.4.0 ~amd64
> =dev-ruby/uglifier-1.3.0 ~amd64
> =dev-ruby/rack-test-0.6.2 ~amd64
> =dev-ruby/bcrypt-ruby-3.0.1 ~amd64
> =dev-ruby/mysql2-0.3.11 ~amd64
> =dev-ruby/ruby-net-ldap-0.3.1 ~amd64

Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
3.0 was released almost exactly three years ago. Every time rails-3.x
gets bumped, I have to manually update the entire list above. I need
to do it on an x86 server as well, so I get to do it twice; I can't
even copy/paste the list.

It sucks, but it's still better than running ~arch. Problems like this
should be fixed, but if you decide it's easier to
ACCEPT_KEYWORDS="~arch" than deal with the exceptions, you're asking for
trouble.