Re: [orbit-dev] EBR way of patching class from upstream JAR?

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

> So we need a separate CQ for a modified Lucene Core 5.2.1. Fine.
> 
> I just wonder on behalf of which project I should file this CQ, assuming
> that we would still need a *separate* Add-to-Orbit CQ. Should I file a
> CQ on behalf of tools.orbit [1] and then, once that is approved, on
> behalf of tools.orbit another ATO CQ? Seems like a lot of hoops to jump
> through...

I think any project could file the CQ (ideally not Orbit as we
generally don't file the first CQ itself) and the subsequent ATO CQ
shouldn't take long to complete.

Perhaps it's worth evaluating this process and seeing if the amount of
waiting/clicking links on the portal page could be reduced in the
future.

I do see one case in the past where Orbit filed the CQ itself, but even
then we filed the ATO CQ also (debatable whether it would have been
needed as well).

> > Am I right in assuming that this is just targeting Oxygen.1, or
> > basically from Orbit's point of view, all that is needed is some
> > repository that consumers can reference to correct the issue ?
> 
> Yes, as I explained in Bug 517935 [2] Oxygen won't break out-of-the-box,
> as it will contain only a single unpatched version of Lucene Core
> (org.apache.lucene.core_6.1.0). The bug will only manifest if a
> third-party project also installs the unpatched
> org.apache.lucene.core_5.2.1. As long as Orbit has at least an I-build
> with the patched org.apache.lucene.core bundles available, third-party
> projects have an easy way out; the can simply redistribute our patch
> org.apache.lucene.core bundles. Then, with Oxygen.1 we can further
> improve the situation by switching to the patched
> org.apache.lucene.core_6.1.0 bundle in the simultaneous release.

This sounds fine to me.

Cheers,
-- 
Roland Grunberg