| 1 |
First thanks for the feedback about chromium, and sorry for the |
| 2 |
annoyances. I'm not sure how we can "fix" that though. |
| 3 |
|
| 4 |
I've batched my replies to several people in this e-mail. |
| 5 |
|
| 6 |
On 11/11/11 8:58 AM, Tomáš Chvátal wrote: |
| 7 |
> In last 3 days i recompiled chromium 3x |
| 8 |
|
| 9 |
So the timeline is: |
| 10 |
|
| 11 |
26 Oct <https://bugs.gentoo.org/388497> is filed. |
| 12 |
01 Nov cups USE is dropped from 16.x while still hard masked |
| 13 |
03 Nov 16.x is unmasked (dev -> beta release) |
| 14 |
10 Nov cups USE restored for 16.x while in ~arch |
| 15 |
|
| 16 |
I'm not sure which update you've applied (there are many in that time |
| 17 |
range), but the data suggests you're running hard masked package |
| 18 |
(otherwise you shouldn't see those cups USE flag changes). |
| 19 |
|
| 20 |
> If you screw the ebuild up then always think if the change is worth |
| 21 |
> the stupid long recompile time. |
| 22 |
|
| 23 |
Sorry about the recompile time, but then you're not required to actually |
| 24 |
apply the update every time it's available. Also, if you sync and update |
| 25 |
every day, that in itself increases number of updates, just most |
| 26 |
packages are smaller than chromium. |
| 27 |
|
| 28 |
Note that changes that don't require revbumps are done without revbumps. |
| 29 |
USE flag changes are only picked up with -N emerge option. All other |
| 30 |
changes require a revbump, which is usually compensated by hard mask on |
| 31 |
the dev channel releases. |
| 32 |
|
| 33 |
I avoid needlessly revbumping beta and especially stable. If you have a |
| 34 |
case where this happened and I just didn't realize what I was doing, |
| 35 |
please let me know. |
| 36 |
|
| 37 |
> Like it is not enough there is version bump every few days... |
| 38 |
|
| 39 |
That's how upstream does it. Stable channel releases are roughly every |
| 40 |
2-3 weeks from each other (the release cycle is 6 weeks, but there are |
| 41 |
usually 1-2 security updates in between). |
| 42 |
|
| 43 |
> Just alter only live ebuild and branch of it with each release and do |
| 44 |
> not alter the releases unless really critical bug is there. People are |
| 45 |
> patient and they can wait for bugfixes. |
| 46 |
|
| 47 |
The problem here is that at least for me it's hard to work with live |
| 48 |
ebuild (upstream moves very fast at ~200 commits per day |
| 49 |
chromium+webkit), so I mostly work on dev channel releases which are |
| 50 |
roughly weekly. They're hard masked though. |
| 51 |
|
| 52 |
And then if we want stable and ~arch to be unaffected, the fix should be |
| 53 |
pushed as fast as possible, so we can test it before that branch is |
| 54 |
promoted to a more stable channel, which happens within weeks, much |
| 55 |
faster than with many other projects. |
| 56 |
|
| 57 |
On 11/11/11 9:45 AM, Michał Górny wrote: |
| 58 |
> Maybe you could consider some of the releases major and other minor, |
| 59 |
> and just keep a mask for those minor. |
| 60 |
|
| 61 |
Yup, stable is stable, beta is ~arch, and dev is hard masked. |
| 62 |
|
| 63 |
On 11/11/11 3:58 PM, Michał Górny wrote: |
| 64 |
> I simply mean that weekly builds were masked. |
| 65 |
|
| 66 |
Note that in case of chromium those are actually releases, that go |
| 67 |
through upstream QA etc. |
Archives