[OE-core] [morty][PATCH v2] gcc6.4 upgrade

[Martin Jansa]

Feel free to ignore my feedback.

I didn't mean it as strong objection to get this merged as-is.

It was rather an advice for next time or in case another version is sent
(e.g. with that missing patch from Khem) and Juro decides to rework it in
order to save himself some time later when preparing the changes for pyro
and rocko (as he said in the e-mail that he plans to prepare). It shouldn't
be too difficult to rework anyway, because Andre already has the
cherry-picks for morty and Juro can do just rebase of his change on top of
that to get those new patches in separate commit.

Regards,

On Sat, Mar 10, 2018 at 7:27 PM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sat, 2018-03-10 at 08:46 +0100, Martin Jansa wrote:
> > On Fri, Mar 09, 2018 at 11:56:58PM +0000, Bystricky, Juro wrote:
> > >
> > > I forgot to mention that if there are no objections against this
> > > patchset, I intend to do the same/equivalent upgrades for other
> > > releases with gcc 6x (rocko, pyro, ...)  and also upgrade gcc5.x
> > > and 4.9x where present.
> > Thanks for this work.
> >
> > It might be a bit easier to do and review this by starting with rocko
> > (with just small change on top with newly backported changes) and
> > just
> > cherry-picking the necessary changes down to pyro and then few more
> > down
> > to morty (similar to Andre's backports in his branch).
> >
> > With single big patch it's difficult to make sure that all the
> > branches
> > got all the changes and to review what's "new" compared to 6.4.0
> > which
> > used to be in master.
>
> I do agree with you that in an ideal world, this is how it should be
> done.
>
> I also realise part of the problem here is a few different companies
> have patched gcc 6.x in older releases and not submitted the changes
> with upstream stable. I appreciate there could be a ton of different
> reasons for that. It would be nice to try and share this work earlier
> and more often to avoid having patchsets quite this large.
>
> It is tough to have someone step up and try and make changes to gcc in
> OE-Core since the test matrix is quite large and fixing all the issues
> that can come up is non-trivial.
>
> I'm therefore very grateful for Juro taking this on and I don't
> particularly want to have him go back and redo the patches again,
> particularly for feedback at v2.
>
> I've been doing my best to guide Juro, equally I'm trying to do a
> number of things at the moment (M3 still isn't ready and the
> autobuilder is a wreak) and I clearly haven't given Juro enough
> guidance to get this 'right'. For that I do feel bad.
>
> So now I have a horrible choice. Do I push this back to Juro and have
> him do this again as you comment. I know I'll have to provide mode
> guidance, I'm travelling and its hard on everyone. Do I feel guilty for
> my part in this and sort the splitting up myself to avoid impacting
> Juro (with the impact on my time/sanity that entails)? Or do I take the
> patch and risk upsetting some of our key contributors for ignoring
> review?
>
> I'm spelling out the issues here because as a community/team, we need
> to get better at guiding people through things like this. It does have
> an impact on whether people step up in the first place and may be part
> of the reason nobody wants to touch gcc in the first place...
>
> Cheers,
>
> Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180310/15a9f2d0/attachment-0002.html>