On Mon, Oct 10, 2016 at 11:56 AM, Jason Pyeron <jpye...@pdinc.us> wrote: >> -----Original Message----- >> From: Stefan Beller >> Sent: Monday, October 10, 2016 14:43 >> >> +cc Xiaolong Ye <xiaolong...@intel.com> >> >> On Sun, Oct 9, 2016 at 2:26 PM, Jason Pyeron <jpye...@pdinc.us> 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.