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.
signature.asc
Description: OpenPGP digital signature
