Hi Marcel Thanks for the summary. From my understanding the proposal additionally included the wish that we move forward with the modularisation and aims for independent releases for the oak-blob-azure module in trunk.
See OAK-6069 [0] and subtask OAK-6073 [1] for the corresponding JIRA issue including references to an initial PoC. Kind regards Angela [1] https://issues.apache.org/jira/browse/OAK-6069 [1] https://issues.apache.org/jira/browse/OAK-6073 On 12/04/17 09:17, "Marcel Reutegger" <[email protected]> wrote: >Hi, > >On 28/03/17 09:09, Michael Dürig wrote: >> As Marcel mentions on the issue a better approach would be to release >> this independently. If this is blocked by dependencies we should make an >> effort to sort this out, as now is the time in the release cycle for >> doing so. >> >> So for now -1 from my side to back porting this until >> >> a) we have a clear picture of the alternatives > >A group of Oak committers discussed alternatives offline last week. I'd >like to summarize this discussion here on the dev list again. Feel free >to correct me or add to below if you think I missed important conclusions. > >In general we recognized the need for this module to work with 1.6. >After all the whole modularization effort is about enabling independent >releases and make it possible to release new features outside of our so >far yearly minor version Oak release cycle. Having to wait for nearly a >year in order to use a rather independent new module with a stable Oak >release seems disproportionate. > >An alternative was presented in OAK-4933. Release the new module >independently and then use it in 1.6. The broad agreement in the >discussion last week was, this is not desirable either. We'd end up in a >situation where the 1.6 branch is a mix of multi-module and independent >release modules. The modularization in progress for trunk, with the goal >to have cleaner dependencies also for the new azure module, will make it >more difficult to use the new module in >the 1.6 branch. We definitively don't want to restructure the 1.6 branch >as well. > >The proposal therefore is to backport OAK-4933 despite the concerns >mentioned earlier. > >> b) in the case of backporting, understand how we would ensure quality. >> This is new code that was so far never exposed to the level of testing >> people would expect from 1.6 code. > >I don't have a good answer to this other than thorough code review and >good test coverage. Anything else we can do? > >Regards > Marcel
