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"<[email protected]> wrote in message
news:20110303100109.GA13658@futoi...
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)
_______________________________________________
bug-lilypond mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
