[wp-hackers] Recommendations for trac patches?
gaarai at gaarai.com
Wed Feb 3 22:53:45 UTC 2010
It would greatly help me and people like me (who submit patches to core)
if a definitive guide on how to submit patches is created. When I
submitted my first patch, I did it by following the guidelines in the
Codex. Those are mostly geared towards people reporting issues with a
little tacked on for people providing patches. It would seem to me that
people might provide more patches if they knew exactly what was expected
of them, their trac ticket, and their patches. I've submitted numerous
patches, and I still feel that I have a loose at best understanding of
what I should do.
Adding keywords is a mysterious thing with no clear rules or
expectations on how they should be used. I've always felt that at most
as the provider of the patch, I should provide has-patch. This is due to
the fact that I have no idea what a core dev considers worthy of
additional keywords. The description for commit specifies a "trusted
member". Who is a trusted member? Do I count as one yet? I have no idea.
To me, the has-patch keyword denotes that I, or the person who submitted
the patch, has tested the patch against the build cited inside the diff
and believes that the patch should be added to core. If the patch
submitter did not believe this, why would they submit the patch?
Apparently I'm wrong on this thinking, so being clearer in the docs
could easily produce tickets more in line with what the core devs desire.
A guide that details what the keywords are, when to use specific
keywords, how to select the proper component, etc would be greatly
useful. If a solid example of what the core team desires in a patch
ticket is provided, that would be even better. I volunteer to work on
adding such best pratices info to the Codex, but first I need to know
the details on the best practices as I obviously don't right now.
As a final note, I don't want to start CCing different devs just to get
attention. I want to find out what is missing from my submissions that
is causing them to be ignored. I'm sure that others have this issue and,
like I have in the past, believe that this is just the way trac is:
submit a patch and forget about it since it may never be noticed.
On 02/03/2010 04:03 PM, Peter Westwood wrote:
> FYI The things that get my attention quickest are:
> 1) Patches mentioned when I'm in IRC - This is a short cut but you
> still need to do (3)
> 2) Patches marked up with relevant keywords in priority order - commit
> > tested > has-patch
> 3) Patches which have clear information in the ticket about: The bug,
> The fix, The test cases
> 4) Patches on tickets to which I am CC'd - These end up in a separate
> mail folder from the mail wp-trac mail deluge!
> In general when I have the free time I start from here -
> I hope that helps
More information about the wp-hackers