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

[Martin Jansa]

If you and/or Juro want, I can do the rebase and send the cherry-picks for
all 3 release branches.

On Sat, Mar 10, 2018 at 10:04 PM, Martin Jansa <martin.jansa at gmail.com>
wrote:

> 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@
> 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/a96a307c/attachment-0002.html>