[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reduced development time

From: Graham Percival
Subject: Re: reduced development time
Date: Mon, 16 Jan 2012 15:44:55 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jan 16, 2012 at 04:31:33PM +0100, address@hidden 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.

- 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 issue tracker number, update
  the rietveld issue with a link to the appropriate issue number.

Patchy patch-new test:
- automatically update 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 scripts,
  - properly escape ( \ , characters because echo can't handle
  - 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 or manually.
  - for that matter, make prompt the user for
    comments, so that I don't have to manually type silly stuff
     ./ 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]