RE: How to watch a mailing list & repo for patches which affect a certain area of code? [OT]

["Jason Pyeron" <jpyeron@pdinc.us>]

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

Yep. It is a big one. I have a personal project to add a footer to a format patch with the missing "binary" data. The thoughts were for the main cases using a RLE bitmap for the whitespace in the above patch and the remainder of the commit blob data. This would allow minimal duplicate information in the email but pure text changes would be binary perfect so the commit id will still be correct.

Sigh, never have enough free time.

> 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?

This is used when collaborating cross enterprise. In these situations enterprise A will not give access to enterprise B on their CI system, or git repo, etc...

We all have a mailing list in common (encrypted/signed emails when it contains sensitive info). The rules prevent us from using cloud solutions for almost all of our work.

I have also worked on git for cross domain (tin foil hat time) source code transfer.

As to a blog, never thought about it. Ask questions on the list and I will help.

> 
> 
> >
> >> 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>`.

Please make default in 2.10.2 .

> 
> >
> >>
> >> 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:

For the OP's case 

Test 1: does it cleanly apply to any head, if no for all raise flag.

> * the patch you sent did not even compile on your base, so why
>    are you sending bogus patches?

Test 2: is it in an area I care about, if not stop.

Test 3: does it compile for clean application, if no for all raise flag.

> * 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.

Yes, especially when you have no time, or management is in the way.

> * 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.