The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#1230)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1230/ to view
the results.
Changes:
[tomekr] OAK-4674: Log a message when asynchronous persistent
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#1229)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1229/ to view
the results.
Changes:
[frm] [maven-release-plugin] prepare release oak-segment-tar-
I fully agree with what Thomas is saying.
Being on the inside of the segment-tar release cycles I don't really see
the need or the advantages of a decoupled release, it seems it only managed
to separate us even more (we even have a different release email template,
if that was ever needed) without
[X] +1 Release this package as Apache Jackrabbit Oak 1.4.9
On Fri, Oct 21, 2016 at 4:03 PM, Davide Giannella wrote:
>
> A candidate for the Jackrabbit Oak 1.4.9 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.9/
>
> The release candidate is a zip archi
Hi,
On 21/10/16 16:03, Davide Giannella wrote:
Please vote on releasing this package as Apache Jackrabbit Oak 1.4.9.
The vote is open for the next 72 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
On 2016-10-21 16:03, Davide Giannella wrote:
...
[X] +1 Release this package as Apache Jackrabbit Oak 1.4.9
Best regards, Julian
>
>and using a different release
>cycle for oak-segment-tar is not a problem.
Sorry, I wanted to write "and using a different release cycle for
oak-segment-tar *created new problems*"
On 2016-10-21 16:15, Thomas Mueller wrote:
Hi,
You are sure using many emotional, judgmental words and sentences like
"joke", "embarrassing", "nonsense", "We shouldn't go backward, but
forward", "pet project", "admit", "level of complexity", "doesn't allow",
"dumping grounds". Your whole mail is
Hi,
You are sure using many emotional, judgmental words and sentences like
"joke", "embarrassing", "nonsense", "We shouldn't go backward, but
forward", "pet project", "admit", "level of complexity", "doesn't allow",
"dumping grounds". Your whole mail is very judgmental.
OK, I see you would like t
Hi,
>The release process in Oak is a joke.
I don't think it's a joke.
> Releasing every two weeks by
>using version numbers as counters just for the sake of it is
>embarrassing.
Why? It's simple.
> I don't even know how many releases of our parent POM we
>have, every one of them equal to the o
A candidate for the Jackrabbit Oak 1.4.9 release is available at:
https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.9/
The release candidate is a zip archive of the sources in:
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.9/
The SHA1 checksum of the a
Luckily for us this is not a computer science problem but an easier
software engineering concern.
The release process in Oak is a joke. Releasing every two weeks by
using version numbers as counters just for the sake of it is
embarrassing. I don't even know how many releases of our parent POM we
h
Thanks Chetan!
On Fri, Oct 21, 2016 at 2:59 PM, Chetan Mehrotra
wrote:
> On Thu, Oct 20, 2016 at 6:08 PM, Julian Sedding wrote:
>> I think we could get away with increasing this to 4.1.0 if we can
>> annotate QueryEngineSettingsMBean with @ProviderType.
>
> Makes sense. Opened OAK-4977 for that
> All of this is my understanding and I may be wrong, so please correct me
> if I'm wrong. I'm right, could adding an oak-core-api with independent
> lifecycle solve the situation?
While this may be possible, an arguably simpler solution would be to
give oak-run and oak-upgrade a separate lifecycl
On Thu, Oct 20, 2016 at 6:08 PM, Julian Sedding wrote:
> I think we could get away with increasing this to 4.1.0 if we can
> annotate QueryEngineSettingsMBean with @ProviderType.
Makes sense. Opened OAK-4977 for that
Chetan Mehrotra
+1 for initializing the default config unconditionally
Regards
Julian
On Fri, Oct 21, 2016 at 12:14 PM, Chetan Mehrotra
wrote:
> Opened OAK-4975 for query around default config handling.
> Chetan Mehrotra
>
>
> On Fri, Oct 21, 2016 at 2:14 PM, Davide Giannella wrote:
>> On 21/10/2016 08:23, Mic
Hi,
> could adding an oak-core-api with independent lifecycle solve the
>situation?
"All problems in computer science can be solved by another level of
indirection"
I would prefer if we get oak-segment-tar in line with the rest of oak
(release it at the same time and so on). I understand, there
Hello team,
while integrating Oak with segment-tar in other products, I'm facing
quite a struggle with a sort-of circular dependencies. We have
segment-tar that depends on oak-core and then we have tools like oak-run
or oak-upgrade which depends on both oak-core and segment-tar.
this may not be a
Opened OAK-4975 for query around default config handling.
Chetan Mehrotra
On Fri, Oct 21, 2016 at 2:14 PM, Davide Giannella wrote:
> On 21/10/2016 08:23, Michael Marth wrote:
>> Hi Chetan,
>>
>> Re “Should we ship with a default config”:
>>
>> I vote for a small default config:
>> - default beca
On 21/10/2016 08:23, Michael Marth wrote:
> Hi Chetan,
>
> Re “Should we ship with a default config”:
>
> I vote for a small default config:
> - default because: if the feature is always-on in trunk we will get better
> insights in day-to-day work (as opposed to switching it on only occasionally)
Hi Chetan,
Re “Should we ship with a default config”:
I vote for a small default config:
- default because: if the feature is always-on in trunk we will get better
insights in day-to-day work (as opposed to switching it on only occasionally)
- small because: the optimal bundling is probably very
21 matches
Mail list logo
