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
signature.asc
Description: This is a digitally signed message part
