lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP-PROP 13: patch management tools


From: Janek Warchoł
Subject: Re: GOP-PROP 13: patch management tools
Date: Tue, 20 Sep 2011 21:04:39 +0200

2011/9/20 Graham Percival <address@hidden>:
> On Tue, Sep 20, 2011 at 02:08:42AM +0200, Reinhold Kainhofer wrote:
>> Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival:
>> > ** Different patch and issue managment tools
>> >     * 1-3 hours: write a script that checks that every Patch-new
>> >       can apply to master, compiles correctly, and creates a
>> >       regtest comparison so the local human can check it and make
>> >       it Patch-review instead. If there’s a problem before the
>> >       regtest comparison, the script automatically changes it to
>> >       Patch-needs_work.
>>
>> The problem is that if someone pushes a broken commit, it will cause all
>> patches to Patch-needs_work, even if the patch is not to blame...
>
> That's why the script would/should check that master compiles,
> before trying any of the patches.  Naturally, if master fails, it
> sends a panic email to lilypond-devel.

"Dear developer,
Master failed.  You are well advised to run screaming in horror.
yours sincerely,
Fieldmarshal BugTracker"

> At this point, I'm not endorsing any particular behavior of these
> scripts; I'm just saying that the python gdata modules gives us an
> enormous amount of power to automate whatever we want to automate.
> I think we should pursue this option, rather than trying to move
> to different hosting tool(s).

2011/9/20 Colin Campbell <address@hidden>:
> As the Patch Meister in question, it would be nice to have a guaranteed link
> between the tracker and Rietveld, such that every patch on Rietveld has a
> corresponding tracker number.  ATM, it is pretty much impossible to find a
> list of lilypond=-related patches on Rietveld without doing a search on each
> developer's login, where they are known to the Patch Meister.  Given the
> one-to-one link, we're looking in a single, well-understood place, and
> finding everything related to issues (bugs and enhancements) with associated
> patches (bug fixes and proposed enhancements).

My impression is that the main problem is the "duplicancy" of data and
e-mail threads.  Over and over again i'm getting lost, for example:
"where did i saw that complaint from Neil about patch adding Kievan
notation? was it posted as a comment on Rietveld, a comment to google
tracker issue (which one it was? tracker issues usually contain link
to rietveld, but rietveld issues often don't contain links to
tracker), or maybe an e-mail in a general thread that started before
tracker and rietveld issues were created?  Maybe it was sent in that
thread, but only to me?"  I struggle to keep my inbox clean (in other
words: if i don't have anything to do with a thread, archivize or
delete it - this means that every thread present in my inbox requires
some action from me.  It gets difficult when there are three threads
about the same topic...).

One thing comes to my mind: there is some code revieving tool on
Google Code.  I remember that i saw it being used in some other
project.  It's a bit hidden, but i managed to found some info:
http://code.google.com/p/support/wiki/CodeReviews
Looks that we need to add our source code to the Google Code to be
able to use that.
I think this may be worth considering.  Could we add our source to
Google Code and see what we can do then?

Another thing: i'd consider adding a policy about separating
discussion about code and notation: comments on issue tracker should
be about notation/features (i.e. what should the output be?  What
syntax do we want to use?) and all comments about code itself (is the
indentation correct?  Does it pass regtests?) should be done at code
revieving tool.

cheers,
Janek



reply via email to

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