Procedure for Patches Merging FreeBSD Code

Procedure for Patches Merging FreeBSD Code

[Joel Sherrill]

Hi

Gedare, Aditya, and I were discussing that it is useful
during development to have a git branch with a patch
series that adds the unmodified FreeBSD files followed
by a patch series that adds them to the build system
and makes them work. Then you can easily review the
differences against the original source.

Would it be desirable for patches submitted to newlib
to follow this pattern? Or should Aditya submit a
single patch series including the addition and
any modifications?

For sure, the addition change can only add the source
files and not touch the build system. Otherwise
git bisect will break. That can't be allowed if
avoidable.

Thanks.

--joel

Re: Procedure for Patches Merging FreeBSD Code

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Jul 26 09:59, Joel Sherrill wrote:
> Hi
> 
> Gedare, Aditya, and I were discussing that it is useful
> during development to have a git branch with a patch
> series that adds the unmodified FreeBSD files followed
> by a patch series that adds them to the build system
> and makes them work. Then you can easily review the
> differences against the original source.
> 
> Would it be desirable for patches submitted to newlib
> to follow this pattern? Or should Aditya submit a
> single patch series including the addition and
> any modifications?
> 
> For sure, the addition change can only add the source
> files and not touch the build system. Otherwise
> git bisect will break. That can't be allowed if
> avoidable.

We don't support merges in the newlib-cygwin repo, just the same as in
the binutils-gdb repo.  All changes must be part of a linear history.
The post-receive hook will refuse merges.

You can create branches, but they have a disjunct history and you'd
have to cherry-pick from there for master, so it's not much of an
advantage for the person applying the patches.

Nothing speaks against providing a two step patchset, first including
the original file into newlib, then a second patch adding the newlib
required changes on top.  We can do this as part of the normal review
process.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Procedure for Patches Merging FreeBSD Code

[Joel Sherrill]

On 7/26/2017 2:43 PM, Corinna Vinschen wrote:
> On Jul 26 09:59, Joel Sherrill wrote:
>> Hi
>>
>> Gedare, Aditya, and I were discussing that it is useful
>> during development to have a git branch with a patch
>> series that adds the unmodified FreeBSD files followed
>> by a patch series that adds them to the build system
>> and makes them work. Then you can easily review the
>> differences against the original source.
>>
>> Would it be desirable for patches submitted to newlib
>> to follow this pattern? Or should Aditya submit a
>> single patch series including the addition and
>> any modifications?
>>
>> For sure, the addition change can only add the source
>> files and not touch the build system. Otherwise
>> git bisect will break. That can't be allowed if
>> avoidable.
> 
> We don't support merges in the newlib-cygwin repo, just the same as in
> the binutils-gdb repo.  All changes must be part of a linear history.
> The post-receive hook will refuse merges.
> 
> You can create branches, but they have a disjunct history and you'd
> have to cherry-pick from there for master, so it's not much of an
> advantage for the person applying the patches.

I wasn't concerned about this. Managing the work is a local
user issue. It has to be patches sent to the mailing list. :)
> 
> Nothing speaks against providing a two step patchset, first including
> the original file into newlib, then a second patch adding the newlib
> required changes on top.  We can do this as part of the normal review
> process.

If you are OK with it, I personally like doing this because it
encourages and aids in tracking differences from the upstream.

Awesome!

--joel

> Corinna
>