Patch submissions (Was: Re: [Apache Bloodhound] #187: Remove row count and results pagination from Dashboard)

[Gary Martin <ga...@wandisco.com>]

On 19/09/12 19:38, Olemis Lang wrote:
> About patches . I have the habit of including them in one of two forms
>
> 1.
>
> {{{
> #!diff
>
> <patch contents>
>
> }}}
>
> 2. Attachment having a name of the form
> t<ticket_number>_r<changeset_id>_<descriptive_name>.diff
>
> both ticket number and changeset ID are useful to know whether the
> patch needs to be updated before applying it , and also to tag the
> exact version modifications were tested against . This is a practice
> inherited from Trac-dev itself so we might just include a link to
> their patch submission guidelines wiki page or start from there and
> customize it for our own usage .

I think that attachment naming is more about whatever makes it easy for 
the person who produces the patch. A description of the patch in a 
comment is almost always useful and specification of the revision that 
the patch was developed against is a very good idea. If these happen to 
be a part of the file name instead of a comment (or in addition to), 
that should be considered fine too.

All I would care about is that the information is available, correct and 
understandable rather than the precise form. Maybe I will care more 
about this later of course.

I can check out the Trac guidelines but we need our own page. PEP 8 
(http://www.python.org/dev/peps/pep-0008/) is obviously an appropriate 
Python style guide for instance. I understand that Trac frown upon 
deviations from this so anything that we want to contribute back to Trac 
should be vetted carefully. It remains to be seen how strict I will turn 
out to be on enforcing this style. I don't believe it always pays off to 
be overly strict and in the end, code readability wins.

Anyway, I should be putting all this and more into a wiki page as Brane 
suggested.

Cheers,
     Gary