[poky] [PATCH 0/3] git-pull: new pull request generation and sending scripts
Darren Hart
dvhart at linux.intel.com
Mon Nov 8 07:59:13 PST 2010
On 11/07/2010 08:55 PM, Bruce Ashfield wrote:
> On 10-11-07 10:18 AM, Darren Hart wrote:
>> On 11/06/2010 11:28 AM, Darren Hart wrote:
>>> The following patches replace the existing create-pull-request script
>>> and create
>>> a new send-pull-request. See 2/3 for details on the motivation and
>>> functionality
>>> of the new create-pull-request script.
>>
>> Thinking about this, I realized that the script would be usefull for
>> just sending patches as well (for developers without a contrib branch).
>> Perhaps the scripts should not contain "pull" in their name and the
>> remote git branch as well as the hosting site should be both optional
>> and configurable. These are relatively trivial changes which we could
>> address in a subsequent series if people agree that this initial set is
>> the right approach for our project.
>
> I saw these in action at the LPC, and I like the two
> phase approach here. Since it gives a chance to edit/update
> review before sending, and like 'git mailinfo' it creates
> the parts you need and doesn't actually do anything
> without a second command :)
>
> Having the patches via email is key for me, so I'm glad
> to see that in place. Do we assume that discretion will
> be used and we don't need a throttle/limit on the patches ?
> But then again, thinking about it, 200+ patch dumps
> to go lkml without the world ending (and it shouldn't
> really be common here) so this probably isn't an issue.
I thought a bit about ensuring proper ordering (I've made scripts wait 5
seconds between patches before). As for abuse... well, I think it is
unlikely - if someone wants to abuse the list, there are innumerable
ways to go about it, this being one of the least efficient ;-)
>
> So definitely acked-by me.
>
Excellent - and this brings up a point I wanted to discuss. One of the
stated reasons for doing this was to facilitate peer review. Now that I
have Bruce's Acked-by:, I could reword the commit messages to include
them, or Richard could add them when he does the pull, but I do think
they should be present in the final commits to poky proper.
Richard - how would you like to see that done? My suggestion would be
that if you accept these as they are, that you append Bruce's Acked-by
and your Signed-off-by. If I end up having to take another pass and send
a V2 pull request, I could confirm Bruce still agrees (in a side
channel) and add his Acked-by.
Thanks,
--
Darren Hart
Embedded Linux Kernel
More information about the poky
mailing list