| 1 |
On Sun, 2005-04-24 at 14:44 +0100, Ciaran McCreesh wrote: |
| 2 |
> Since keywording policy seems to be being ignored again... Don't *ever* |
| 3 |
> commit new ebuild revisions straight to stable, even if you think it's a |
| 4 |
> trivial fix. There are plenty of things that could go wrong even with |
| 5 |
> simple patches -- for example, if you accidentally included some CVS Id: |
| 6 |
> lines in your patch, they'll get nuked when you do the commit. And, if |
| 7 |
> you commit straight to stable, you end up breaking arch rather than just |
| 8 |
> ~arch. |
| 9 |
> |
| 10 |
> The "all things must go through ~arch for a while first" rule is there |
| 11 |
> for a good reason. It's not something you can arbitrarily ignore because |
| 12 |
> you think you're not breaking anything... |
| 13 |
|
| 14 |
Let me first start by saying that committing straight to stable was |
| 15 |
clearly a mistake. I can't help wonder why CVS would change patch files |
| 16 |
(it probably doesn't know the difference between ordinary files and |
| 17 |
patches) or why repoman doesn't catch something like this? CVS changing |
| 18 |
files on commit goes against the whole "test before commit" mantra and |
| 19 |
I'm probably not the first to have encountered this problem? |
| 20 |
|
| 21 |
-- |
| 22 |
Anders Rune Jensen |
| 23 |
http://www.cs.auc.dk/~arj/ |
| 24 |
|
| 25 |
PGP/GnuPG key: 1024D/62C2D7F0 @ pgp.mit.edu |
| 26 |
Fingerprint: 6A03 907E 92E1 47EB 4EAB 76B6 068A ACD1 62C2 D7F0 |
Archives