Re: Backport of OAK-4933 to 1.6

[Michael Dürig]

On 12.04.17 09:17, Marcel Reutegger 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.


Makes sense, thanks for the in-depth analysis! Given there is good 
progress with the modularisation [1] and that I'm confident that we'll 
keep up with this I'm taking back my -1 from earlier. Consider me +1.




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?


Can we in addition put some sort of a disclaimer into the 1.6 branch for 
this module stating its origin? This would help setting user's 
expectations right.


Michael

[1] 
https://lists.apache.org/thread.html/73f6916cc920e36c116ba0311bdf602021598c31f1cf0e5e840e379c@%3Coak-dev.jackrabbit.apache.org%3E

Re: Backport of OAK-4933 to 1.6

[Angela Schreiber]

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"  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

Re: Backport of OAK-4933 to 1.6

[Marcel Reutegger]

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

Re: Backport of OAK-4933 to 1.6

[Michael Dürig]

On 28.03.17 15:02, Raul-Nicolae Hudea wrote:

Hi,

I wasn’t aware that “releasing independently” is an option, and maybe even 
desired for future modules. This is currently proposed on 
https://issues.apache.org/jira/browse/OAK-4933.

If you have input on how to make it successful, please add your input there 
(I’d be interested in the lessons learned from the previous attempt, which I 
understand it was related to segment-tar).


We decoupled oak-segment-tar for some time from the Oak release cycle 
last year. This gave us a lot of additional flexibility and enhanced 
modularity. We were effectively able to just re-deploy oak-segment-tar 
in AEM. Something that was and is much harder otherwise.


The show stopper latter was that with this way of releasing it is 
difficult to align the version of oak-run (tooling) with the module. To 
fix this we would have had to also decouple the tooling. Something we 
didn't have the resources for at that point in time.


Michael



Thanks,
Raul

On 28/03/2017, 11:54, "Angela Schreiber" <anch...@adobe.com> wrote:

i was about to write pretty much the same thing :-)

regards
angela

On 28/03/17 09:09, "Michael Dürig" <mdue...@apache.org> wrote:

>
>As this is a new feature I would be interested in the motivation for
>having to backport this. Generally we should only backport fixes for
>defects.
>
>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 and
>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.
>
>Michael
>
    >On 27.03.17 11:21, Raul-Nicolae Hudea wrote:
>> Hi,
>>
>> I would like to backport OAK-4933 to 1.6. The impact should be minimal
>>since the changes are about bringing the AzureBlobStore connector to 1.6.
>>
>> Changes are:
>> - new module
>> - changes in oak-run to support the azure data store
>>
>> Thanks,
>> Raul
>>
>>

Re: Backport of OAK-4933 to 1.6

[Raul-Nicolae Hudea]

Hi,

I wasn’t aware that “releasing independently” is an option, and maybe even 
desired for future modules. This is currently proposed on 
https://issues.apache.org/jira/browse/OAK-4933.

If you have input on how to make it successful, please add your input there 
(I’d be interested in the lessons learned from the previous attempt, which I 
understand it was related to segment-tar).

Thanks,
Raul

On 28/03/2017, 11:54, "Angela Schreiber" <anch...@adobe.com> wrote:

i was about to write pretty much the same thing :-)

regards
angela

On 28/03/17 09:09, "Michael Dürig" <mdue...@apache.org> wrote:

>
>As this is a new feature I would be interested in the motivation for
>having to backport this. Generally we should only backport fixes for
>defects.
>
>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 and
>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.
>
>Michael
>
    >On 27.03.17 11:21, Raul-Nicolae Hudea wrote:
>> Hi,
>>
>> I would like to backport OAK-4933 to 1.6. The impact should be minimal
>>since the changes are about bringing the AzureBlobStore connector to 1.6.
>>
>> Changes are:
>> - new module
>> - changes in oak-run to support the azure data store
>>
>> Thanks,
>> Raul
>>
>>

Re: Backport of OAK-4933 to 1.6

[Angela Schreiber]

i was about to write pretty much the same thing :-)

regards
angela

On 28/03/17 09:09, "Michael Dürig" <mdue...@apache.org> wrote:

>
>As this is a new feature I would be interested in the motivation for
>having to backport this. Generally we should only backport fixes for
>defects.
>
>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 and
>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.
>
>Michael
>
>On 27.03.17 11:21, Raul-Nicolae Hudea wrote:
>> Hi,
>>
>> I would like to backport OAK-4933 to 1.6. The impact should be minimal
>>since the changes are about bringing the AzureBlobStore connector to 1.6.
>>
>> Changes are:
>> - new module
>> - changes in oak-run to support the azure data store
>>
>> Thanks,
>> Raul
>>
>>

Re: Backport of OAK-4933 to 1.6

[Michael Dürig]

As this is a new feature I would be interested in the motivation for 
having to backport this. Generally we should only backport fixes for 
defects.


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 and
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.


Michael

On 27.03.17 11:21, Raul-Nicolae Hudea wrote:

Hi,

I would like to backport OAK-4933 to 1.6. The impact should be minimal since 
the changes are about bringing the AzureBlobStore connector to 1.6.

Changes are:
- new module
- changes in oak-run to support the azure data store

Thanks,
Raul

Backport of OAK-4933 to 1.6

[Raul-Nicolae Hudea]

Hi,

I would like to backport OAK-4933 to 1.6. The impact should be minimal since 
the changes are about bringing the AzureBlobStore connector to 1.6.

Changes are:
- new module
- changes in oak-run to support the azure data store

Thanks,
Raul