svn commit: r307612 - in head/misc/astrolog: . files
Bryan Drewery
bdrewery at freebsd.org
Wed Nov 21 15:52:55 UTC 2012
On 11/21/2012 8:53 AM, Eygene Ryabinkin wrote:
> Wed, Nov 21, 2012 at 01:01:29PM +0100, Erwin Lansing wrote:
>> On Wed, Nov 21, 2012 at 03:43:57PM +0400, Andrey Chernov wrote:
>>> On 21.11.2012 15:10, Chris Rees wrote:
>>>
>>> Yes, but the new naming convention is something which should be decided
>>> by portmgr@ to keep all things in line. F.e. will it be '-' or '_' or
>>> '=' or some combination of them etc? It is unknown to me at this moment,
>>> so I prefer to stay the old one I see.
>>
>> "Please only use characters [-+._a-zA-Z0-9] for naming your patches. Do
>> not use any other characters besides them. Do not name your patches like
>> patch-aa or patch-ab etc, always mention the path and file name in patch
>> names."
>>
>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html
>>
>> Imporovements to the handbook are of course always welcome.
>
> The per-file patches are always make me sad: you're loosing the
> metadata about the grouping of diff hunks into changes and makes the
> non-trivial fixes harder to understand, so when I first took
> maintainership of OpenOSPFD, I was struggling with the patch files,
> because it was very non-trivial to find which patches should be
> dropped for the new releases and which should be kept/modified and how
> all hunks in all diffs are related to each other. And this makes life
> for the new maintainers especially hard: they have no background on
> what previous ones were patching and it is sometimes not really easy
> to get the idea from the port commit logs, so some time should be
> spent on resurrecting this metadata.
>
> As I understand, the problem with the grouped patches is the order of
> their application while the per-file patches has no such problem and
> it is the only technical answer to the question "why handbook teaches
> us about per-file patches rather than the real commit diffs", but if
> we will implement the proper patch ordering (just by doing sort before
> patch application), won't it go away?
>
I agree. Splitting logically-grouped changes out into multiple patches
is confusing, especially to future maintainers.
IMHO this should not be a hard rule, but a suggestion if ordering is
problematic.
--
Regards,
Bryan Drewery
bdrewery at freenode/EFNet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20121121/66b45973/attachment.sig>
More information about the svn-ports-all
mailing list