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

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Tue, Feb 09, 2016 at 04:26:36PM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 16:56 +0100, Luis R. Rodriguez wrote:
> > 
> > No you're right, this just fell through the cracks. The surprising case of
> > things still being broken on modern tools however should raise a bit of
> > concern either by opensuse factory folks or by Xen build folks in general.
> 
> AFAIK both Xen 4.6 and Xen unstable build fine with gcc5 now, and unstable
> does so even with gcc6.

It would seem the possible remaining issues are the library requirements.

> > The issues with required target platfroms to build and if developers are
> > required to backport features for tools carried / forked is also a pretty
> > important and IMHO a heavy requirement.
> 
> I'm not sure what this means, but Xen surely doesn't require anyone to
> backport toolchains.

So if a new gnutls library deprecated a set of routines which are only
available using a new set of APIs, one does not have to provide the stub to
backport this for the old gnutls library? In this case the upstream project
required a  new module which uses the new API, so another option is to upgrade
the qemu release embraced by xen.

> > > FWIW I would also suggest sending fixes to different components (qemu-xen,
> > > qemu-xentraditional, xen.git, mini-os.git) as different series, lest
> > > someone read patch #1 and assume the whole series is against that 
> > > component
> > > rather than something they maintain.
> > 
> > OK thanks. Right Jan didn't read that cover letter so he was not ware of
> > the work I put into vetting if things were upstream or not.
> 
> This seems like a non-sequitor compared to the paragraph quoted above it
> (i.e. I'm not sure what upstream vs not has to do with sending unrelated
> patches against different components in different series).

It was an example of how the series failed to be properly split and because I
didn't send things separately it was not clear to different maintainers the
status of each patch with respect to the upstream project.

> > > And BTW when we say to copy the maintainers we mean the person/people
> > > responsible for the component in Xen, not the upstream maintainers,
> > > e.g.
> > > Stefano for qemu-xen not Peter Maydell. The xen.git MAINTAINERS file
> > > lists
> > > the right people.
> > 
> > Sure, I do both though, first real upstream and then prod the Xen 
> > maintainers.
> > I take it scripts/get_maintainer.pl should work though? I tried it in a few
> > patches and it seemed to have worked
> 
> I wouldn't bet on it always doing the right thing with 3rd party components
> like qemu-xen.

Hrm, so how can I get the proper maintainer ? For my case I need to split this
series up into 5 or 6 series for 5 separate trees:

1. tools/firmware/seabios-dir-remote/
2. tools/qemu-xen-traditional-dir-remote/
3. tools/qemu-xen-dir-remote/
4. extras/mini-os-remote/
5. top level xen:
        5a. stubdom
        5a. vtpm

Since I can't seem to rely on scripts/get_maintainer.pl I want to make sure I 
get
this right this time around.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel