Re: [VOTE] Release Apache Jackrabbit Oak 1.32.0
[X] +1 Release this package as Apache Jackrabbit Oak 1.32.0 ...where... [INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00) [INFO] OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac" [INFO] Java version: 1.8.0_144, vendor: Oracle Corporation [INFO] MAVEN_OPTS: Regards, Woonsan On Fri, Jul 10, 2020 at 5:20 AM Marcel Reutegger wrote: > > A candidate for the Jackrabbit Oak 1.32.0 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.32.0/ > > The release candidate is a zip archive of the sources in: > > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.32.0/ > > The SHA1 checksum of the archive is badb08abcbba2aba22501f239220e8c21d0cbd73. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > # run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit > $ sh check-release.sh oak 1.32.0 badb08abcbba2aba22501f239220e8c21d0cbd73 > > Please vote on releasing this package as Apache Jackrabbit Oak 1.32.0. > The vote is open for the next 120 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit Oak 1.32.0 > [ ] -1 Do not release this package because... > > Regards > Marcel
[Release Plan] Apache Jackrabbit Oak 1.22.4
Hi, I plan on cutting 1.22.4 for oak on Monday. Here is the list of issues included - https://issues.apache.org/jira/projects/OAK/versions/12348066 Please let me know in case there are any concerns. Regards, Nitin
Re: [VOTE] Release Apache Jackrabbit Oak 1.32.0
On 10.07.20, 11:20, "Marcel Reutegger" wrote: > Please vote on releasing this package as Apache Jackrabbit Oak 1.32.0. > The vote is open for the next 120 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. All checks OK. +1 Release this package as Apache Jackrabbit Oak 1.32.0 Regards Marcel
[VOTE] Release Apache Jackrabbit Oak 1.32.0
A candidate for the Jackrabbit Oak 1.32.0 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.32.0/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.32.0/ The SHA1 checksum of the archive is badb08abcbba2aba22501f239220e8c21d0cbd73. A staged Maven repository is available for review at: https://repository.apache.org/ The command for running automated checks against this release candidate is: # run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit $ sh check-release.sh oak 1.32.0 badb08abcbba2aba22501f239220e8c21d0cbd73 Please vote on releasing this package as Apache Jackrabbit Oak 1.32.0. The vote is open for the next 120 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 1.32.0 [ ] -1 Do not release this package because... Regards Marcel
Re: [RT] Limited write support for non-default CompositeNodeStore mounts
On Thu, 2020-07-09 at 15:35 +, Marcel Reutegger wrote: > Hi, > > On 09.07.20, 15:39, "Robert Munteanu" wrote: > > The details are rough and my memory of the implementation is not > > that > > good > > Same here. > > Besides the problem with a potential two phase commit, I think the > biggest concern was impact of a change in a mounted subtree on > repository wide data structures. E.g. what happens when an access > control entry is added to such a subree? How are indexes updated for > nodes changed in the subtree? Well, it depends. The current check when merging changes is simple - only allow them to the default (read-write) mount. What I propose is allow writes to all mounts under given circumstances. For instance (all examples inside a non-default mount): - if there is an observation listener that should be triggered, fail the commit - if an index should be updated and we know we can't do that, fail the commit The downside is that it is less predictable that a 'plain' read-only situation and can be confusing for users of the repository. Or that, due to the way the repository is configured, effectively no changes can be persisted ( e.g. observation listener for all of /apps ). > > I'm also wondering whether and where the current implementation > assumes > mounted subtrees are read-only and takes short cuts. These would need > to > be changed as well. Yes, those implementations need to be revisited as well. I am a bit optimistic here since for instance indexing can write to a separate location; this is one of the steps of preparing a composite node store. Thanks, Robert
