[VOTE][RESULT] retire oak-mk into attic

[Angela Schreiber <an...@adobe.com>]

The vote results are as follows:

+1 Marcel Reutegger
    +1 Michael Dürig
+1 Thomas Mueller    ("for moving oak-mk and oak-mk-api to attic and
removing all other MicroKernel implementations")
+1 Stefan Guggisberg ("for removing oak-mk, oak-mk-api and all MicroKernel
implementations")

-1 Stefan Guggisberg ("for removing oak-mk but keeping oak-mk-api")

+1 Angela Schreiber

Not sure, what the correct procedure is now. Shall I cancel
this vote and start a new one for

   "moving oak-mk and oak-mk-api to attic and removing all other
MicroKernel implementations"

? Or should I rather extend this very vote to make sure everyone
would be comfortable with the extended scope as proposed by Stefan?

Please advise
Regards

Angela



On 26/03/15 15:26, "Angela Schreiber" <an...@adobe.com> wrote:

>Dear Oak Team
>
>During initial phase of building a new JCR content repository (OAK),
>we introduced a new persistence layer API (called MicroKernel API)
>originally implemented by the oak-mk module, which since then has
>been part of the Oak project.
>
>In the mean time the overall architecture and design has evolved and
>matured and we ended up replacing the original MicroKernel persistence
>API by the NodeStore API. Nowadays we only use the MicroKernel API as
>wrapper around the NodeStore API but abandoned the original default
>implementation.
>
>Our recommended and maintained Oak setup currently includes the following
>options for the persistence layer:
>
>- Segment Nodestore (aka Tar-MK)
>- Document Nodestore (Mongo, Memory, RDB)
>
>Given these developments in our code base, I came to believe that we no
>longer need the original MK implementation.
>
>Since the duplicate persistence API and the mismatch between
>documentation,
>project structure and recommendation used to cause quite some confusion
>for people getting started with Oak, and to minimise the maintenance for
>the Oak code base on the other hand, I would therefore like to suggest
>that
>we retire the oak-mk module (e.g. moving it to attic) and removing it of
>the main oak pom.xml.
>
>The corresponding JIRA component description should only be adjusted to
>reflect this but will continue to exist.
>
>So, please case your vote for this proposal.
>
>In case of objection I kindly ask you for some technical description on
>why we need to keep oak-mk in the productive oak project and perform
>regular releases.
>
>Thanks and kind regards
>Angela
>
>
>
>

Re: [VOTE][RESULT] retire oak-mk into attic

[Angela Schreiber <an...@adobe.com>]

for the record:
michael, marcel and myself had a short discussion in the office.
based on the indication that we can reach consensus for stefans
proposal, we went ahead deprecating the mk api for 1.2 as initial
step for the cleanup. all subsequent cleanup work will be done
once the stable 1.2 release is out giving us enough time to
get rid of the few remaining usages of the mk-api in oak-core
and oak-it. see subtasks for OAK-2697 for the proposed sequence
of steps.

kind regards
angela 

On 30/03/15 14:16, "Angela Schreiber" <an...@adobe.com> wrote:

>see https://issues.apache.org/jira/browse/OAK-2697
>
>On 30/03/15 12:49, "Michael Dürig" <md...@apache.org> wrote:
>
>>
>>
>>On 30.3.15 10:01 , Angela Schreiber wrote:
>>> Not sure, what the correct procedure is now. Shall I cancel
>>> this vote and start a new one for
>>>
>>>     "moving oak-mk and oak-mk-api to attic and removing all other
>>> MicroKernel implementations"
>>>
>>> ? Or should I rather extend this very vote to make sure everyone
>>> would be comfortable with the extended scope as proposed by Stefan?
>>>
>>> Please advise
>>
>>This vote didn't pass.
>>
>>But there is strong indication that we have a consensus for Stefan's
>>proposal. The most controversial part is probably the timing of such a
>>change, which it turn depends on its complexity and impact. I think it
>>is best to start with an JIRA issue for this and prepare a bunch of
>>patches for people to review and take it from there then.
>>
>>
>>Michael
>>
>>
>

Re: [VOTE][RESULT] retire oak-mk into attic

[Angela Schreiber <an...@adobe.com>]

see https://issues.apache.org/jira/browse/OAK-2697

On 30/03/15 12:49, "Michael Dürig" <md...@apache.org> wrote:

>
>
>On 30.3.15 10:01 , Angela Schreiber wrote:
>> Not sure, what the correct procedure is now. Shall I cancel
>> this vote and start a new one for
>>
>>     "moving oak-mk and oak-mk-api to attic and removing all other
>> MicroKernel implementations"
>>
>> ? Or should I rather extend this very vote to make sure everyone
>> would be comfortable with the extended scope as proposed by Stefan?
>>
>> Please advise
>
>This vote didn't pass.
>
>But there is strong indication that we have a consensus for Stefan's
>proposal. The most controversial part is probably the timing of such a
>change, which it turn depends on its complexity and impact. I think it
>is best to start with an JIRA issue for this and prepare a bunch of
>patches for people to review and take it from there then.
>
>
>Michael
>
>

Re: [VOTE][RESULT] retire oak-mk into attic

[Michael Dürig <md...@apache.org>]

On 30.3.15 10:01 , Angela Schreiber wrote:
> Not sure, what the correct procedure is now. Shall I cancel
> this vote and start a new one for
>
>     "moving oak-mk and oak-mk-api to attic and removing all other
> MicroKernel implementations"
>
> ? Or should I rather extend this very vote to make sure everyone
> would be comfortable with the extended scope as proposed by Stefan?
>
> Please advise

This vote didn't pass.

But there is strong indication that we have a consensus for Stefan's 
proposal. The most controversial part is probably the timing of such a 
change, which it turn depends on its complexity and impact. I think it 
is best to start with an JIRA issue for this and prepare a bunch of 
patches for people to review and take it from there then.


Michael