Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Brian Harring <ferringb@gmail.com>]

On Fri, Nov 11, 2011 at 10:48:15AM +0100, Tom???? Chv??tal wrote:
> 2011/11/11 Brian Harring <ferringb@gmail.com>:
> The build issue was with -cups so useflag was removed and hard
> dependency enabled, fine with me.
> But why the fuck the bump was issued next day still hard-depending on
> it and in day after that this commit arrived in:
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-16.0.912.32.ebuild?r1=1.1&r2=1.2
> 
> You are telling me this is build time failure fix, you are telling me
> that people that already had pulled in that cups could not sleep
> thanks to it and survive for another week to get the flag back with
> bump?

I'm telling you to stop fucking bitching about running unstable 
software that probably is the fastest moving upstream in the tree in 
terms of versions, nor the simplest fucking thing to maintain, let 
alone keep everyone happy.  Libreoffice I have no doubt is a pain in 
the ass to maintain, but I'd take it over chromium any day of the 
week.

Realize you're ranting on the ML because /you choose to run unstable/ 
and don't like that it's changing to deal w/ bugs (let alone the fast 
release cycle of dev channel which you're on).

Specifically, you're ranting, and I strongly suspect you didn't bother 
talking to the people directly beyond firing off bitching to the ML.  

Nice and friendly, that.

As I said, looking through the logs it looks like this isn't 
arbitrary random fucking around w/ ebuilds as you're implying above.  
Is the cups situation a fuckup?  Perhaps, but in digging through the 
logs it ain't seeming like it's the norm.  It's more seeming like 
you're just venting about changes that went out fixing chromium 
building for others, and you had to rebuild.

Productive courses of action, enumerated:
1) change your user configuration.  You chose to run unstable after 
all.
2) talk w/ the devs directly w/ suggestions of how to slow the 
releases (doesn't frankly seem all that viable, but hey, it's your 
time to burn).  Keep in mind your original suggestion was to leave 
shit broke in unstable (but hey, at least you don't have to 
recompile).
3) add an optional feature to portage enabling you to control the 
frequency of rebuilds for an unstable pkg.  This way you get your 
bleeding edge, just control the level of pain.

Non-produtive courses of action, enumerated:
1) bitching on an ML cc'ing the maintainers rather than going to the 
maintainers directly.
2) continuing to argue with me.

~brian