[OpenPower-Firmware] Dropping Power8 in op-build

[Dean Sanner]

> >> On Jun 17, 2020, at 4:54 AM, Klaus Heinrich Kiwi
> <klaus at linux.vnet.ibm.com> wrote:
> >>
> >>> On 6/17/2020 4:58 AM, Joel Stanley wrote:
> >>>> On Wed, 17 Jun 2020 at 05:38, Paul Menzel
> >>>> <pmenzel+openpower-firmware at molgen.mpg.de> wrote:
> >>>> It looks like they are held up due to failing in IBM internal build
> >>>> environment. Can that internal environment be integrated into the
public
> >>>> CI infrastructure?
> >>> If the reason we can't merge is internal CI fails to build, won't
that
> >>> same internal CI fail to build if we remove Power8 from the tree and
> >>> update to the newer compilers?
> >>
> >> I think Dean and Dan can better comment on this, but my take is
> that the Hostboot team
> >> (as well as SBE, OCC etc) have a Power8 branch, on which we based
> several of our products,
> >> and they're maintaining that branch as those products still
> require them. Since those are
> >> long-term products in "fixes" mode only, they'd prefer not to
> change the toolchain
> >> from underneath it, adding risk to existing products using them
> and essentially having
> >> to re-validate all of them end-to-end.
> >
> > That should have nothing to do with upstream master though.
>
> Fact is that our op-build master still depends on that -p8 branch
>
> >
> > I’d also note that the try-cflag patch that Joel proposed (a
> cherry pick of my four year old patch) would solve this problem anyway.
>
> I guess even Cherry-picking those are considered to be requiring
> extensive testing in the -p8 branch.
> Existing products in maintenance mode are not wanting to mess with
> their toolchains, specially due to a demand outside
> those product's scope.

For the areas that IBM isn't willing to actively maintain (ie updating
the compiler for P8) I'd rather let the community take over maintenance
and not eliminate the branch.  The benefits of the internal CI would be
lost -- but the branch would still be usable/maintainable by the
community. Klaus, lets work with the internal IBM teams to figure
out a solution that is acceptable to both the community and IBM.

>
>
> >>> I can't see the downside to merging these patches in. There's no
> >>> guarantee of support or testing, but it allows folks like Paul to
> >>> still build from master, and take advantage of updates to skiboot,
> >>> buildroot and Linux.
> >>
> >>
> >> I believe it would require the HB, OCC, SBE teams etc to perform
> "a branch of a branch",
> >> i.e., continue to maintain the branch in which we have products
> still in service,
> >> while creating a new branch, that sits somewhere in between
> "hostboot-p8" and
> >> "hostboot-master", that is able to drive the Power8 chip while
> still tolerating newer
> >> compilers and toolchains (and new features?).
> >
> > Hostboot master is wildly different from Hostboot master-p8.
> >
> > We’re talking a dozen patches here.
>
> I guess one or a hundred patches, it's the concept that is being
> discussed here. I believe our group within
> IBM is in practice not equipped to maintain another -p8-derivate
> branch, in addition to -p8 itself and master.
>
> I played around with that "Alternate Toolchain" PRs exactly for that
> reason, but even if we could use that mechanism,
> I don't think we'd have anyone from IBM maintaining the
-p8-derivatebranches.
>
> > I’d almost encourage the community just to maintain branches
> ourselves, it’d be less work. IBM can pull if it wants, but perhaps
> it’s time to just have open power branches.
> >
> > I also wonder if this pattern is about to be repeated with P9, as
> it has a much larger installed base out in a broader community what
> with the availability of the Raptor boxes.
> >
>
> This pattern is very likely to repeat for P9, yes.

Agree as well -- and we should figure out a way to transition to the
community as well (when the time comes).  P8 will be a good way to
work out the kinks.

Dean Sanner
dsanner at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20200618/4b47ad54/attachment.htm>