On Mon, Oct 10, 2016 at 11:56 AM, Jason Pyeron <jpyeron@xxxxxxxx> wrote:
>> -----Original Message-----
>> From: Stefan Beller
>> Sent: Monday, October 10, 2016 14:43
>>
>> +cc Xiaolong Ye <xiaolong.ye@xxxxxxxxx>
>>
>> On Sun, Oct 9, 2016 at 2:26 PM, Jason Pyeron <jpyeron@xxxxxxxx> wrote:
>> >> -----Original Message-----
>> >> From: Ian Kelling
>> >> Sent: Sunday, October 09, 2016 15:03
>> >>
>> >> I've got patches in various projects, and I don't have
>> time to keep up
>> >> with the mailing list, but I'd like to help out with
>> >> maintenance of that
>> >> code, or the functions/files it touches. People don't cc me.
>> >> I figure I
>> >> could filter the list, test patches submitted, commits made,
>> >> mentions of
>> >> files/functions, build filters based on the code I have in
>> >> the repo even
>> >> if it's been moved or changed subsequently. I'm wondering
>> what other
>> >> people have implemented already for automation around
>> this, or general
>> >> thoughts. Web search is not showing me much.
>> >>
>> >
>> > One thought would be to apply every patch automatically (to
>> the branches of interest?). Then trigger on the [successful] changed
>> > code. This would simplify the logic to working on the
>> source only and not parsing the emails.
>> >
>> > -Jason
>> >
>>
>> I think this is currently attempted by some kernel people.
>> However it is very hard to tell where to apply a patch, as it
>
> This is one of the reasons why I use bundles instead of format patch.
Oh! That sounds interesting for solving the problem where to apply
a change, but the big disadvantage of bundles to patches is the inability
to just comment on it with an inline response. So I assume you follow
a different workflow than git or the kernel do. Which project do you use it
for and do you have some documentation/blog that explains that workflow?
>
>> is not formalized.
>> See the series that was merged at 72ce3ff7b51c
>> ('xy/format-patch-base'),
>> which adds a footer to the patch, that tells you where
>> exactly a patch ought
>> to be applied.
>
> Cant wait for that.
Well it is found in 2.9 and later. Currently the base footer is
opt-in, e.g. you'd
need to convince people to run `git config format.useAutoBase true` or to
manually add the base to the patch via `format-patch --base=<commit>`.
>
>>
>> The intention behind that series was to have some CI system hooked up
>> and report failures to the mailing list as well IIUC. Maybe
>> that helps with
>> your use case, too?
>
> I envisioned that it would try for each head he was interested in.
>
Well the test system can be smart enough to differentiate between:
* the patch you sent did not even compile on your base, so why
are you sending bogus patches?
* the patch you sent was fine as you sent it, but in the mean time
the target head progressed, and it doesn't compile/test any more.
collaboration is hard.
* or an extension to the prior point: this patch is fine but is broken
by the series xyz that is also in flight, please coordinate with
name@email.