Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Tue, Feb 09, 2016 at 01:08:13AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 02:48, <mcgrof@suse.com> wrote:
> > On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> > <mcgrof@do-not-panic.com> wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> Here's a slew of build fixes as well as build warning fixes
> >> required when using the latest build tools, at least gcc 5 and
> >> binutils 2.25.0.
> > 
> > One good reason for some folks to get discouraged to work with Xen:
> > 
> > Patches for fixes on builds last ages to get merged
> > 
> > In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
> > offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
> > it was probably not the right fix. Last year in November I provided
> > what I think is a proper replacement set which I think addressed Jan's
> > concerns.
> 
> A link to your submission instead of Mark's, which has been given
> feedback on, would have been more helpful.
> 
> > ***Four*** months later and Xen still does not compile with the latest
> > and greatest. I have to go digging out in my git basement somewhere
> > some fixes I last used to build Xen to try to test some new
> > features...
> > 
> > What's up folks? How can this process be made smoother, did I do
> > something wrong, what can I do to help better? What can you do to help
> > ensure these types of things don't fall through the cracks.
> 
> Patch 1 should have gone through SeaBIOS and then a backport
> should have been requested.

On the cover letter I explained I did the work to check upstream
and see if indeed what I'm doing is a backport and if not see
if I send it first upstream and then explain its a backport.
In cases where I found the change upstream I provide the
"Upstream sha1sum" at the top of the commit, which follows
the Linux stable backport practice given I saw no equivalent
practice on Xen backporting and figured this was important.

> Patch 2 should equally have gone
> through upstream qemu, and then a backport be requested. I
> won't continue for the other ones.

This one did not have a respective backport commit, instead
the new API was explicitly used via commit d321e1e5268:

commit d321e1e5268103af616ec4c623c6326c3f7c7bc7
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon Mar 2 17:23:31 2015 +0000

    crypto: introduce new module for handling TLS sessions

And then later qemu was changed to use the new interface
via commit 3e305e4a4752f:

commit 3e305e4a4752f70c0b5c3cf5b43ec957881714f7
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Thu Aug 6 14:39:32 2015 +0100

    ui: convert VNC server to use QCryptoTLSSession

So unless we embrace the new TLS module we can't directly
backport the upstream solution.

I have similar explanations on the patches / cover letter.
At times when I saw the upstream commit lacked a proper
commit log I actually went to lengths to explain actual
real impact of not applying the changes. This should
help people looking to cherry pick important things to
stable branches.

> 
> Neither (apart from 4 and 5, which do so indirectly, referencing
> something that isn't even a repo) indicates (in the title) what
> component it's against.

I did explain this on the cover letter but I could have done a better job by
splitting things. I could have CC'd more maintainers aas well.

> And nothing in the entire series seems to fall into my areas of
> responsibility, so I can't see why both the original series and
> this mail was addressed to me. 

OK.

> Please - don't complain about things not getting accepted if
> you don't even follow basic submission rules.

The realization that compilation is not working for some modern
tools, in particular for OpenSUSE factory for a long time without
it being addressed is a bit concerning.

  Luis