Now repoman actually makes it an error when all ebuilds are ~arch. Actually repoman should check and complain if new ebuilds are committed straight to stable. This should be easy to implement as follows: check cvs status --> new file --> check KEYWORDS --> something stable --> complain
s/complain/fatal
I can see some use of comitting straight to stable, but lets face it.. policy says otherwise and fatal is good for me.
(In reply to comment #2) > I can see some use of comitting straight to stable, but lets face it.. policy > says otherwise and fatal is good for me. Why not just make two commits then? Of course I don't recommend this practise either because it would be better that someone else than the maintainer took care of the keywording. Two pairs of eyes are better.
There does 1 exist case when commiting right into stable seems to be semi normal. Thats when moving a stable package around via epkgmove.
should be easy to detect though, things like Manifest and ChangeLog would not yet be committed so the CVS/ files would list them as [A]dded
(In reply to comment #4) > There does 1 exist case when commiting right into stable seems to be > semi normal. Thats when moving a stable package around via epkgmove. Another case is when somebody accidentally removes a stable ebuild and breaks some dependency, then has to add it back again. I suppose we can just add a --force-commit option or something.
(In reply to comment #6) > some dependency, then has to add it back again. I suppose we can just add a > --force-commit option or something. Could make all currently non-fatal warnings fail at default and this option would override them. (I can also imagine a yes/no dialogue but maybe it's safer to require re-run with this option, although I can imagine certain people, who also ignore ChangeLog's etc, to alias that option to be always used, can't be helped). Straight-to-stable could be then one of these warnings.
Created attachment 129397 [details, diff] add a KEYWORDS.stable check and a --force option (In reply to comment #7) > Could make all currently non-fatal warnings fail at default and this option > would override them. Maybe that's appropriate for some but I'm not sure about doing that for all of them until I run repoman on the full tree and see how common or uncommon they are.
This has been released in 2.1.3.8. The --force option will skip the most time consuming QA checks and the commit message will indicate when this option has been used.
