Re: [gentoo-dev] Committing straight to stable

[Anders Rune Jensen <arj@gentoo.org>]

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

On Sun, 2005-04-24 at 14:44 +0100, Ciaran McCreesh wrote:
> Since keywording policy seems to be being ignored again... Don't *ever*
> commit new ebuild revisions straight to stable, even if you think it's a
> trivial fix. There are plenty of things that could go wrong even with
> simple patches -- for example, if you accidentally included some CVS Id:
> lines in your patch, they'll get nuked when you do the commit. And, if
> you commit straight to stable, you end up breaking arch rather than just
> ~arch.
> 
> The "all things must go through ~arch for a while first" rule is there
> for a good reason. It's not something you can arbitrarily ignore because
> you think you're not breaking anything...

Let me first start by saying that committing straight to stable was
clearly a mistake. I can't help wonder why CVS would change patch files
(it probably doesn't know the difference between ordinary files and
patches) or why repoman doesn't catch something like this? CVS changing
files on commit goes against the whole "test before commit" mantra and
I'm probably not the first to have encountered this problem?

-- 
Anders Rune Jensen
http://www.cs.auc.dk/~arj/

PGP/GnuPG key: 1024D/62C2D7F0 @ pgp.mit.edu
Fingerprint: 6A03 907E 92E1 47EB 4EAB  76B6 068A ACD1 62C2 D7F0


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]