On Mon, Jan 16, 2012 at 04:31:33PM +0100, m...@apollinemike.com wrote:
> > Instead, I will end with a plea for more automation.
>
> I have dabbled in this, mostly because I do not know what is
> needed. Python is my native language, so if people could start
> an automation wishlist, I can get things done over the next few
> months. I'm terrible at brainstorming this type of stuff but ok
> at implementing anything that falls outside of git. Just lemme
> know.
git-cl:
- for each branch, store the issue number in the git config file
(like it does for reitveld number). that way you don't need to
type in the issue number whenever you update a patch
- after getting a new code.google.com issue tracker number, update
the rietveld issue with a link to the appropriate issue number.
Patchy patch-new test:
- automatically update code.google.com issue, and send email to
owner, to reject a patch which:
- fails to apply to master
- fails to compile make
- fails to compile make test
- fails any other automatic test
- when writing the show-1234.sh scripts,
- properly escape ( \ , characters because echo can't handle
them
- possibly replace the whole .sh file with a .py file
- prompt the user for accept/reject patch, then do the
right thing. Currently I manually type in the issue id
when running accept-patch.py or reject-patch.py manually.
- for that matter, make accept-patch.py prompt the user for
comments, so that I don't have to manually type silly stuff
like
./reject-patch.py 1234 sorry\, the patch wreck\'s stuff\: \
by not compiling the regtest\'s.
[sic] for the grammar there.
- correctly build new fonts when necessary. Maybe consult with
others about fixing our general build system rather than making
this Patchy-specific.
that's just off the top of my head with no pause to think.
There's a *ton* of things that can be automated to make our lives
easier (git-cl is the best cost-benefit ratio, since everybody
uses that and curses the lack of remembering the issue number)
* NB: with the new git branches discussion in the CG that Carl
is working on, you *can* assuming that work on each issue is in a
separate branch, so tracking that on a per-branch basis makes much
more sense.
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
