Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-04 Thread Graham Percival
On Sun, Jul 03, 2011 at 03:45:09PM -0600, Colin Campbell wrote:
 
 Given the above, perhaps it would be wise to defer any formal Patch
 Meister role until we have decided how (and if) patches are to be
 recorded.  I can carry on with keeping an eye on the tracker, but
 anything else would require either manually logging postings on
 -devel or periodic manual scans of each (known) developer's patches
 on Reitveld.

What about discussing this sooner rather than later?  Next
wednesday is already marked for Phil's build system output:
http://lilypond.org/~graham/gop/gop_5.html
but we could begin the patch handling discussion on 13 July.

That's only 2 days after I return to Canada, so I'm not likely to
have a good proposal ready.  Could you write one?  Phil wrote his
build system proposal; it would be great if you could write a
similar one for patch handling.

Remarks from the CG:
  Patch review tool: Reitveld is inconvenient in some respects: it
  requires a google account, and there’s no way to see all patches
  relating to lilypond. Should we switch to something like
  gerritt?
http://code.google.com/p/lilypond/issues/detail?id=1184

(prep: 5 hours. discuss: 15 hours)

More elabortation:
- what are the patch review frameworks out there?
- how well do they support git?  automatically tracking patches?
  ease of making reviews?  etc.
- what kind of manual administration is required for each tool?
- what policies should we have?  what should/must developers do?
  what should/must reviewers do?  what else is there left to do?


Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-04 Thread Graham Percival
On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote:
 Remarks from the CG:
   Patch review tool: Reitveld is inconvenient in some respects: it
   requires a google account, and there’s no way to see all patches
   relating to lilypond. Should we switch to something like
   gerritt?
 http://code.google.com/p/lilypond/issues/detail?id=1184

Further to that: I just merged some changes by Dmytro to the
lilypond-extra repository on github, and I was blown away by the
interface.  Github has *really* done a good job on the UI / user
experience.

It might be worth investigating this as a potential review tool.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-04 Thread Colin Campbell

On 11-07-04 03:54 AM, Graham Percival wrote:

On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote:

Remarks from the CG:
   Patch review tool: Reitveld is inconvenient in some respects: it
   requires a google account, and there’s no way to see all patches
   relating to lilypond. Should we switch to something like
   gerritt?
http://code.google.com/p/lilypond/issues/detail?id=1184

Further to that: I just merged some changes by Dmytro to the
lilypond-extra repository on github, and I was blown away by the
interface.  Github has *really* done a good job on the UI / user
experience.

It might be worth investigating this as a potential review tool.

Cheers,
- Graham



I'll see what I can put together, Graham.  I'm looking toward something 
like trac, which would combine issue tracking with patch management.


Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


RE: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-03 Thread James Lowe
Hello,

From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Colin 
Campbell [c...@shaw.ca]
Sent: 03 July 2011 05:06
To: lilypond-devel@gnu.org
Subject: Re: lilymidi: Add --pretty switch to lilymidi.py to display midi   
in  human-readable form (with --dump) (issue4628078)

On 11-07-02 05:52 PM, percival.music...@gmail.com wrote:
 On 2011/07/02 23:47:32, J_lowe wrote:
 Can't see a tracker for this, and not sure a reg test is appropriate
 :) but did
 one all the same..no problems.

 I don't think we need a tracker for this particular patch; I think
 Reinhold should push it whenever he thinks it's ready, since this isn't
 going to disrupt anything else.


 http://codereview.appspot.com/4628078/



I'd suggest we *do* create a tracker item, even if Reinhold pushes
immediately, so that we can work toward one source of record for all
changes and enhancements.  As it is, there are a an unknown number of
things added or done to lilypond, leaving no trace except in git blame
or its relatives.  Using the tracker, while it may seem overkill to the
senior devs, at least gives us a searchable database which can be tied,
if only manually, to Reitveld.  If the outstanding request on Reitveld,
to allow searching by project, were to be implemented, life could be
different.  If we had our own instance of Reitveld, we could de jure
limit it to lilypond. If wishes were fishes . . .  Long one short, by
linking every Reitveld patch to a tracker item, we have an easily
searchable list of all our activities, with somewhat less likelihood of
duplicated effort and much better review of agbe and status.

--

Yes I agree*

Because we have a 'bug squad' (and people like myself who do some reg testing 
and so touch both Rietveld and Tracker) we can add tracker items for the devs 
so that the they don't have to waste too much time worrying about this, all 
that I say we ask is that if a patch is up on rietveld or submitted via email 
that that person states there is/is not a tracker for this - and if they don't 
know then state that (but I cannot see that happening much).

That way everyone at least knows where we 'stand' sometimes there is doubt and 
I have 'wasted' (although I am educating myself each time I have to go scan the 
tracker list - turning the frown upside down) seeing if this is an open issue 
or not, whereas if a dev says 'here's a patch for XYZ - no tracker item - 
please review' there is half a chance it will then get added by one of the Bug 
squadders or persons like me and we can worry about making sure we cross 
reference. We all know that 9 times out of 10 it is usually never needed, but 
on that one occasion where a patch is abandoned or left to rot, it really helps 
if we have a cross reference.

James

* I would have added a tracker myself but I just wasn't sure if there was one 
or know the midi code/problem well enough to 'guess' if one other differently 
titled tracker issue was to do with this.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-03 Thread Graham Percival
On Sun, Jul 03, 2011 at 10:20:41AM +, James Lowe wrote:
 
 From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
 [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Colin 
 Campbell [c...@shaw.ca]
  I don't think we need a tracker for this particular patch; I think
  Reinhold should push it whenever he thinks it's ready, since this isn't
  going to disrupt anything else.
 
 I'd suggest we *do* create a tracker item, even if Reinhold pushes
 immediately, so that we can work toward one source of record for all
 changes and enhancements.

By decree, we will seriously discuss this proposal at a later date
as part of GOP.  Until we have a full discussion of the proposal,
we will not adopt any change of existing policy.

 As it is, there are a an unknown number of
 things added or done to lilypond, leaving no trace except in git blame
 or its relatives.

I don't think this is a horrible thing -- the git changelog is a
perfectly reliable source of information.  It's searchable in the
webgit interface, or browsable within gitk, etc.  The open-source
community has a long history of looking at cvs/svn/mercurial/git
changelogs.

 Yes I agree*

James, do you really think that it would have been worth adding a
google tracker issue for
12503a0c383617cd11fa0bba2836af6c0518ecf7
?  I think that some sort of balance is called for; some patches
definitely need the extra administation of having an issue number,
most would benefit from it, but some patches can be pushed
immediately with no fuss.

Don't get me wrong; it's great that you and Colin are adding issue
numbers, and I certainly don't want to discourage you!  And of
course it's good if patch-writers let us know if this is fixing an
existing issue.

I just think that:
1. we shouldn't institute a blanket policy of always issue
numbers until we've discussed it properly.
2. when that discussion occurs, I will be arguing against such a
policy; instead, I will suggest that we have a always issue
numbers by default, unless it's not important enough to bother
with one policy.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-03 Thread Colin Campbell

On 11-07-03 05:30 AM, Graham Percival wrote:

On Sun, Jul 03, 2011 at 10:20:41AM +, James Lowe wrote:


From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Colin 
Campbell [c...@shaw.ca]

I don't think we need a tracker for this particular patch; I think
Reinhold should push it whenever he thinks it's ready, since this isn't
going to disrupt anything else.

I'd suggest we *do* create a tracker item, even if Reinhold pushes
immediately, so that we can work toward one source of record for all
changes and enhancements.

By decree, we will seriously discuss this proposal at a later date
as part of GOP.  Until we have a full discussion of the proposal,
we will not adopt any change of existing policy.


As it is, there are a an unknown number of
things added or done to lilypond, leaving no trace except in git blame
or its relatives.

I don't think this is a horrible thing -- the git changelog is a
perfectly reliable source of information.  It's searchable in the
webgit interface, or browsable within gitk, etc.  The open-source
community has a long history of looking at cvs/svn/mercurial/git
changelogs.


Yes I agree*

James, do you really think that it would have been worth adding a
google tracker issue for
12503a0c383617cd11fa0bba2836af6c0518ecf7
?  I think that some sort of balance is called for; some patches
definitely need the extra administation of having an issue number,
most would benefit from it, but some patches can be pushed
immediately with no fuss.

Don't get me wrong; it's great that you and Colin are adding issue
numbers, and I certainly don't want to discourage you!  And of
course it's good if patch-writers let us know if this is fixing an
existing issue.

I just think that:
1. we shouldn't institute a blanket policy of always issue
numbers until we've discussed it properly.
2. when that discussion occurs, I will be arguing against such a
policy; instead, I will suggest that we have a always issue
numbers by default, unless it's not important enough to bother
with one policy.

Cheers,
- Graham




Given the above, perhaps it would be wise to defer any formal Patch 
Meister role until we have decided how (and if) patches are to be 
recorded.  I can carry on with keeping an eye on the tracker, but 
anything else would require either manually logging postings on -devel 
or periodic manual scans of each (known) developer's patches on Reitveld.


Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-02 Thread pkx166h

Can't see a tracker for this, and not sure a reg test is appropriate :)
but did one all the same..no problems.

http://codereview.appspot.com/4628078/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-02 Thread percival . music . ca

On 2011/07/02 23:47:32, J_lowe wrote:

Can't see a tracker for this, and not sure a reg test is appropriate

:) but did

one all the same..no problems.


I don't think we need a tracker for this particular patch; I think
Reinhold should push it whenever he thinks it's ready, since this isn't
going to disrupt anything else.


http://codereview.appspot.com/4628078/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

2011-07-02 Thread Colin Campbell

On 11-07-02 05:52 PM, percival.music...@gmail.com wrote:

On 2011/07/02 23:47:32, J_lowe wrote:

Can't see a tracker for this, and not sure a reg test is appropriate

:) but did

one all the same..no problems.


I don't think we need a tracker for this particular patch; I think
Reinhold should push it whenever he thinks it's ready, since this isn't
going to disrupt anything else.


http://codereview.appspot.com/4628078/




I'd suggest we *do* create a tracker item, even if Reinhold pushes 
immediately, so that we can work toward one source of record for all 
changes and enhancements.  As it is, there are a an unknown number of 
things added or done to lilypond, leaving no trace except in git blame 
or its relatives.  Using the tracker, while it may seem overkill to the 
senior devs, at least gives us a searchable database which can be tied, 
if only manually, to Reitveld.  If the outstanding request on Reitveld, 
to allow searching by project, were to be implemented, life could be 
different.  If we had our own instance of Reitveld, we could de jure 
limit it to lilypond. If wishes were fishes . . .  Long one short, by 
linking every Reitveld patch to a tracker item, we have an easily 
searchable list of all our activities, with somewhat less likelihood of 
duplicated effort and much better review of agbe and status.


Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel