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

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

[Tomáš Chvátal]

Hi guys,

In last 3 days i recompiled chromium 3x

1x rebuild for cups useflag
1x update
1x rebuild for cups useflag

If you screw the ebuild up then always think if the change is worth
the stupid long recompile time.
Like it is not enough there is version bump every few days...
Just alter only live ebuild and branch of it with each release and do
not alter the releases unless really critical bug is there. People are
patient and they can wait for bugfixes.

Imagine that I would adopt your approach with libreoffice. I suppose
people would chain me to some wall and use as target practice as
result fo my actions :)

Cheers

Tom

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

[Alec Warner]

2011/11/10 Tomáš Chvátal <scarabeus@gentoo.org>:
> Hi guys,
>
> In last 3 days i recompiled chromium 3x
>
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag
>
> If you screw the ebuild up then always think if the change is worth
> the stupid long recompile time.

I tentatively agree in terms of USe flag mixups...however...

> Like it is not enough there is version bump every few days...
> Just alter only live ebuild and branch of it with each release and do
> not alter the releases unless really critical bug is there. People are
> patient and they can wait for bugfixes.

I actually like that chromium releases at a high rate of speed. Does
that mean it sucks for Gentoo? Sure.
However if I want to stay on a particular rev (so I don't recompile
all the time) I can pmask it (and so can you.)

>
> Imagine that I would adopt your approach with libreoffice. I suppose
> people would chain me to some wall and use as target practice as
> result fo my actions :)

Well one; I care a lot less about having an up to date libre office
since it is not typically a target for attacks (unlike my browser
which has a large attack surface.)
That being said; if upstream did an actual release every week I
wouldn't be offended if those releases made it into the tree; again it
is up to me as a user to decide if i am recompiling or not.

-A

>
> Cheers
>
> Tom
>
>

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

[Michał Górny]

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

On Fri, 11 Nov 2011 00:22:34 -0800
Alec Warner <antarus@gentoo.org> wrote:

> > Like it is not enough there is version bump every few days...
> > Just alter only live ebuild and branch of it with each release and
> > do not alter the releases unless really critical bug is there.
> > People are patient and they can wait for bugfixes.
> 
> I actually like that chromium releases at a high rate of speed. Does
> that mean it sucks for Gentoo? Sure.
> However if I want to stay on a particular rev (so I don't recompile
> all the time) I can pmask it (and so can you.)

Maybe you could consider some of the releases major and other minor,
and just keep a mask for those minor. Much like we did with Opera some
time ago.

-- 
Best regards,
Michał Górny

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

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

[Jeroen Roovers]

On Fri, 11 Nov 2011 09:45:29 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Maybe you could consider some of the releases major and other minor,
> and just keep a mask for those minor. Much like we did with Opera some
> time ago.

I have no idea what you mean. It didn't look like that when I was
doing it :)



     jer

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

[Michał Górny]

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

On Fri, 11 Nov 2011 15:44:07 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Fri, 11 Nov 2011 09:45:29 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Maybe you could consider some of the releases major and other minor,
> > and just keep a mask for those minor. Much like we did with Opera
> > some time ago.
> 
> I have no idea what you mean. It didn't look like that when I was
> doing it :)

I simply mean that weekly builds were masked.

-- 
Best regards,
Michał Górny

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

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

[Jeroen Roovers]

On Fri, 11 Nov 2011 15:58:10 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> I simply mean that weekly builds were masked.

I still do it like that with snapshots and in fact with
the entire www-client/opera-next series.


     jer

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

[Tomáš Chvátal]

2011/11/11 Alec Warner <antarus@gentoo.org>:
>
>> Like it is not enough there is version bump every few days...
>> Just alter only live ebuild and branch of it with each release and do
>> not alter the releases unless really critical bug is there. People are
>> patient and they can wait for bugfixes.
>
> I actually like that chromium releases at a high rate of speed. Does
> that mean it sucks for Gentoo? Sure.
> However if I want to stay on a particular rev (so I don't recompile
> all the time) I can pmask it (and so can you.)

I am not bitching about that updates, I am pissed that even if I
update the ebuild is altered afterwards so I again have to recompile
it for no obvious benefits. Even those bugfixes can wait for next damn
release that will happen in few days...
>
>>
>> Imagine that I would adopt your approach with libreoffice. I suppose
>> people would chain me to some wall and use as target practice as
>> result fo my actions :)
>
> Well one; I care a lot less about having an up to date libre office
> since it is not typically a target for attacks (unlike my browser
> which has a large attack surface.)
> That being said; if upstream did an actual release every week I
> wouldn't be offended if those releases made it into the tree; again it
> is up to me as a user to decide if i am recompiling or not.
>
You would be suprised how much people try to exploit your documents
and how interesting that gets :)

Tom

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

[Brian Harring]

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

On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
> Hi guys,
> 
> In last 3 days i recompiled chromium 3x
> 
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag

<snip>

Chromium moves fast and you're obviously running unstable keywording.  
Meaning you're *intentionally* getting every beta channel release.

Nicely phrased, your complaint is that having ran unstable keywords, 
it's moving too fast for your taste.  Stable keywords seem like an 
obvious solution to it.

One thing that is less obvious is that there are essentially two 
flavors of unstable chromium- dev and beta.  Currently beta is 17.*, 
dev is 16.*.  If you don't want bleeding edge, but want faster than 
stable, pmask 17.*.

That said... you're complaining that having ran unstable, you're 
having to rebuild too much.  Stable exists for a reason.

Either way, I suggest folks flip through the changelog- not seeing 
anything egregious in bumping, refactoring appears to go out during 
upstream version bumps.

For the cups rebuild referenced above is a build compilation failure 
that was rolled out in existing versions (or in version bumps).  It 
may be an annoyance to Tommy that emerge -N picked it up, but for 
folks hitting the build failure, they obviously view it a bit 
differently (as evidenced by a fair amount of bitching on the bug in 
question).

If you really, really want to keep running bleeding edge, rebuilding 
for every change that occurs on it but selectively slowing down 
certain builds... well, patch portage and mangle the existing vcs 
rebuild code to be usable for other packages, adding a feature along 
the lines of "I want to run bleeding edge X, but rebuild it only 
weekly".

Barring that, the solutions for your user configuration problem are 
above.

~harring

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

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

[Tomáš Chvátal]

2011/11/11 Brian Harring <ferringb@gmail.com>:
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
>> Hi guys,
>>
>> In last 3 days i recompiled chromium 3x
>>
>> 1x rebuild for cups useflag
>> 1x update
>> 1x rebuild for cups useflag
>
> <snip>
>
> Chromium moves fast and you're obviously running unstable keywording.
> Meaning you're *intentionally* getting every beta channel release.
I am getting dev releases...
>
> Nicely phrased, your complaint is that having ran unstable keywords,
> it's moving too fast for your taste.  Stable keywords seem like an
> obvious solution to it.

It already happened multiple times in the past and i am not bitching
about the updates but to updates to ebuild without bump...
>
> One thing that is less obvious is that there are essentially two
> flavors of unstable chromium- dev and beta.  Currently beta is 17.*,
> dev is 16.*.  If you don't want bleeding edge, but want faster than
> stable, pmask 17.*.
As i said i am on 16 which is in testing, beta series is masked.
>
> That said... you're complaining that having ran unstable, you're
> having to rebuild too much.  Stable exists for a reason.
>
> Either way, I suggest folks flip through the changelog- not seeing
> anything egregious in bumping, refactoring appears to go out during
> upstream version bumps.
>
> For the cups rebuild referenced above is a build compilation failure
> that was rolled out in existing versions (or in version bumps).  It
> may be an annoyance to Tommy that emerge -N picked it up, but for
> folks hitting the build failure, they obviously view it a bit
> differently (as evidenced by a fair amount of bitching on the bug in
> question).
>
> If you really, really want to keep running bleeding edge, rebuilding
> for every change that occurs on it but selectively slowing down
> certain builds... well, patch portage and mangle the existing vcs
> rebuild code to be usable for other packages, adding a feature along
> the lines of "I want to run bleeding edge X, but rebuild it only
> weekly".
>
> Barring that, the solutions for your user configuration problem are
> above.
>
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?

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

[Brian Harring]

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

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

[Rich Freeman]

On Fri, Nov 11, 2011 at 4:32 AM, Brian Harring <ferringb@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
> One thing that is less obvious is that there are essentially two
> flavors of unstable chromium- dev and beta.  Currently beta is 17.*,
> dev is 16.*.  If you don't want bleeding edge, but want faster than
> stable, pmask 17.*.

I agree that the solution to this particular problem is to run stable.
 However, it is worth noting that chromium deviates from the normal
gentoo testing workflow quite a bit.

For a typical package new builds are introduced as a higher version,
stay in the tree for a month, and then get marked stable.  Often not
every version makes it to stable, so there is little churn in the
stable version.

For chromium new builds are introduced as a higher version for the
unstable branches, but never make it to stable.  Instead, typically
stable gets updated as a result of security/bugfixes with new versions
being introduced into the tree and quickly being stabilized.  Since
the new versions are lower than the existing unstable versions nobody
but the developers ever actually test them.  So, the stable branch of
chromium doesn't benefit from extended testing by the ~arch community.
 The only way it could get tested is if a particular build was
released from dev to beta without any changes, and then from beta to
stable without any changes - which never happens.

Now, this is mitigated to an extent by the fact that Google is
following a relatively strict upstream QA process.  A similar
situation exists with the kernel where new stable LTS versions get
introduced and yet never hit the ~arch users who are using versions
beyond them.

I'm not sure the current situation is "broken" per se and needs
fixing.  But, the interaction of upstream QA and Gentoo QA is
something that we might want to think about.  Since most upstream
projects have nowhere near the level of QA as either chromium or the
kernel this isn't going to be a widespread issue.

Rich

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

[Nirbheek Chauhan]

On Fri, Nov 11, 2011 at 3:02 PM, Brian Harring <ferringb@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
>> Hi guys,
>>
>> In last 3 days i recompiled chromium 3x
>>
>> 1x rebuild for cups useflag
>> 1x update
>> 1x rebuild for cups useflag
>
> <snip>
>
> Chromium moves fast and you're obviously running unstable keywording.
> Meaning you're *intentionally* getting every beta channel release.
>

Actually, even in the mozilla team, we try to reduce the no. of
revbumps and USE-flag changes ebuilds get by batching them up. Even
though Firefox (and earlier xulrunner) doesn't have the crazy release
cycle of Chromium (yet), it simply helps to reduce irritation for
users. We try the same with webkit-gtk/evolution/e-d-s under GNOME
(although, they don't require many updates anyway).

Small things like these that cost little help in keeping users happy.
It's a very easy development process change. I remember a blog post by
the chromium team about this too, so they are aware of user
complaints. scarabeus isn't the only one. :)

Also, about attack vectors on beta builds of chromium, they're too
fast-moving a target with a very low target population. Excessively
unlikely that someone will release malware to attack a vulnerability
in version 17.x.y.z. We don't need to go ape-shit over security of
alpha/beta builds. Serious bugs, of course, should be fixed.

OTOH, if you're seriously concerned about personalized attacks, you
should be running adblock and noscript anyway.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

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

[Mike Gilbert]

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

On 11/11/2011 2:58 AM, Tomáš Chvátal wrote:
> Hi guys,
> 
> In last 3 days i recompiled chromium 3x
> 
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag
> 
> If you screw the ebuild up then always think if the change is worth
> the stupid long recompile time.
> Like it is not enough there is version bump every few days...
> Just alter only live ebuild and branch of it with each release and do
> not alter the releases unless really critical bug is there. People are
> patient and they can wait for bugfixes.
> 
> Imagine that I would adopt your approach with libreoffice. I suppose
> people would chain me to some wall and use as target practice as
> result fo my actions :)
> 
> Cheers
> 
> Tom

I often rebuild chromium several times a day, so I probably don't notice
the effect that small changes would have on a more typical user. I'm
sorry that the frequent updates are inconvenient for you.

I think Pawel and I do a good job of not screwing with the stable channel.

We try to limit most of the changes to the dev channel releases (hard
masked). The cups use flag change happened just before upstream pushed
16.x to the beta channel (~arch), so that put us in an odd spot when
adding the cups use flag back.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

["Paweł Hajdan, Jr."]

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

First thanks for the feedback about chromium, and sorry for the
annoyances. I'm not sure how we can "fix" that though.

I've batched my replies to several people in this e-mail.

On 11/11/11 8:58 AM, Tomáš Chvátal wrote:
> In last 3 days i recompiled chromium 3x

So the timeline is:

26 Oct <https://bugs.gentoo.org/388497> is filed.
01 Nov cups USE is dropped from 16.x while still hard masked
03 Nov 16.x is unmasked (dev -> beta release)
10 Nov cups USE restored for 16.x while in ~arch

I'm not sure which update you've applied (there are many in that time
range), but the data suggests you're running hard masked package
(otherwise you shouldn't see those cups USE flag changes).

> If you screw the ebuild up then always think if the change is worth
> the stupid long recompile time.

Sorry about the recompile time, but then you're not required to actually
apply the update every time it's available. Also, if you sync and update
every day, that in itself increases number of updates, just most
packages are smaller than chromium.

Note that changes that don't require revbumps are done without revbumps.
USE flag changes are only picked up with -N emerge option. All other
changes require a revbump, which is usually compensated by hard mask on
the dev channel releases.

I avoid needlessly revbumping beta and especially stable. If you have a
case where this happened and I just didn't realize what I was doing,
please let me know.

> Like it is not enough there is version bump every few days...

That's how upstream does it. Stable channel releases are roughly every
2-3 weeks from each other (the release cycle is 6 weeks, but there are
usually 1-2 security updates in between).

> Just alter only live ebuild and branch of it with each release and do
> not alter the releases unless really critical bug is there. People are
> patient and they can wait for bugfixes.

The problem here is that at least for me it's hard to work with live
ebuild (upstream moves very fast at ~200 commits per day
chromium+webkit), so I mostly work on dev channel releases which are
roughly weekly. They're hard masked though.

And then if we want stable and ~arch to be unaffected, the fix should be
pushed as fast as possible, so we can test it before that branch is
promoted to a more stable channel, which happens within weeks, much
faster than with many other projects.

On 11/11/11 9:45 AM, Michał Górny wrote:
> Maybe you could consider some of the releases major and other minor,
> and just keep a mask for those minor.

Yup, stable is stable, beta is ~arch, and dev is hard masked.

On 11/11/11 3:58 PM, Michał Górny wrote:
> I simply mean that weekly builds were masked.

Note that in case of chromium those are actually releases, that go
through upstream QA etc.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]