Re: Issue 1535 in lilypond: [PATCH] Adding the Tweak_engraver tothe Dynamics context

[Colin Campbell]

On 11-03-03 04:04 AM, Graham Percival wrote:
> On Thu, Mar 03, 2011 at 10:13:20AM -0000, Phil Holmes wrote:
> > "Graham Percival"<address@hidden>  wrote in message
> > news:address@hidden
> > > Perhaps we should just say that the Bug Squad should ignore any
> > > "issue to verify" that is tagged with "Patch" ?  we can find
> > > somebody else that can check if a patch was actually pushed.
> > TBH I think that's ducking the issue.  Taking 1535 as an example, it
> > was called "Adding the Tweak_engraver to the Dynamics context".  If
> > it had been called "Making tweaks work in a Dynamics context" it
> > would have been easier to guess what it was intended to do.  If it
> > had included the code you added, it would have taken a moment to
> > test and verify.  I think we should work to a standard of easily
> > comprehensible patches with sample code - if we do, any bug squad
> > member would be able to test and verify quickly and we'll have a
> > nice clean list of issues to verify.
> In most part, I disagree.  Patches are something that developers
> look at.  The subject "adding the tweak_engraver to the dynamics
> context" makes perfect sense to developers.  In fact, if we
> changed the subject, I could well imagine a developer complaining
> that it made less sense!
>
> Now, sample code may be useful for developer to communicate with
> each other -- I'm not going to say that sample code is a bad
> thing!  But I don't think we should try to force developers to
> always write sample code.  Ditto for "easily comprehensible
> patches" -- of course it's good to have easy-to-understand
> patches.  But such patches should be judged by the standards of
> developers, not users.  And if a patch isn't easy to understand by
> developers, it should be discussed on the -devel list.
>
>
> In short, I don't see any benefit from trying to make bug squad
> members deal with patches, or trying to make patches deal with bug
> squad members.  I think the result would greatly slow down and
> frustrate the jobs of both developers and bug squad members.
>
> Cheers,
> - Graham

From another point of view, it seems that we are trying to manage 
problem resolution with the same mechanism as problem reporting: patches 
get proposed and discussed on bug-lilypond as well as on -devel. Patches 
in particular can get proposed on either list. Given that a well-formed 
reporting mechanism contains a way of closing issues, perhaps we simply 
need to agree on, and *strictly* adhere to, a protocol for message 
subject lines. Messages discussing an issue should probably start with 
"ISSUE #9999 de-bloviate grapple-grommets", and bug-squad folk as well 
as developers would be encouraged to read them. Fixes would be of the 
form "PATCH ISSUE #9999" and ordinarily only developers would read them, 
although Frogs and bug squaddies would be encouraged to read for 
learning purposes.  For purposes of closure, when a patch gets pushed, 
it should be confirmed by a message to both lists, in the form "ISSUE 
#9999 PATCH PUSHED de-bloviate grapple-grommets", to complete the 
initial issue report.

The case of documentation patches is perhaps a bit different, in that 
building the docs in order to test doc patches is a bit specialised, but 
the level of expertise needed to judge the results is well within the 
reach of bug squad folk.  As in a previous thread, having devels review 
doc patches is sub-optimal.  Perhaps we can flag them as "DOC PATCH 
ISSUE #9999 explain filbert flanges connecting to grapple-grommets".

FWIW,
Colin

--
The test of our progress is not whether we add more to the abundance
of those who have much, it is whether we provide enough for those who
have too little.
-Franklin D. Roosevelt, 32nd US President (1882-1945)