Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)
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)
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)
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)
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)
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)
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)
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
Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)
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)
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