Jackrabbit 1.4 status update

[Jukka Zitting <ju...@gmail.com>]

Hi,

In the last few days we've nailed quite a few of the remaining open
issues for Jackrabbit 1.4 (special thanks go to Marcel for the
synchronization fixes!), and I've just dropped another handful of less
essential issues from the critical path to the release. As a result we
currently have the following nine issues (sorted by subjective
priority) open for the 1.4 release:

[JCR-995]  Release the OCM component
- Blocker for the release. I'll look into promoting the OCM component
from sandbox and preparing it for release in a few days, but would
appreciate feedback on the current state of the component before that.

[JCR-924]  Use the Jackrabbit RMI extensions by default in jackrabbit-webapp
[JCR-1193] war missing jcr jar
- I think we should have these, and probably some extra facelifting to
jackrabbit-webapp. I'll still put some effort on these before
branching 1.4.

[JCR-1180] DatabaseFileSystem and DatabasePersistenceManager don't allow ...
[JCR-1197] Node.restore() may throw InvalidItemStateException
[JCR-1277] ConnectionRecoveryManager is created twice in DBDataStore init ...
- Nice to have. It would be great to have these fixes in 1.4, but
postponing to 1.4.1 isn't that bad.

[JCR-1242] Improve serialization of NodeReferences for BundleDB PMs
[JCR-1249] Improve updating of references to version storage
- A bit risky, but probably worth it if we can have good patches in
time for some testing.

[JCR-1253] Allow to configure autoCommit mode for BundleDB PM to avoid ...
- Quite controversial. I'm inclined to dropping this from 1.4, but
wouldn't mind if there's some positive outcome soon enough.

Taken together and mixed with the long Christmas holidays, it seems
like we'll be able to branch 1.4 earliest around the end of next week.
This unfortunately  means that the final release date will slide over
to January.

I'm also getting some backchannel feedback that we should still
consider including the proposed database connection pools and some
other new features in the 1.4 release. That would further postpone the
release date and widen the scope of this release that's already by far
the biggest change since our initial 0.9/1.0 releases. I guess it
would be better to go with a 1.5 release soon after 1.4, but I'll
summarize these thoughts better tomorrow.

BR,

Jukka Zitting

Re: Jackrabbit 1.4 status update

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Dec 21, 2007 11:19 AM, Thomas Mueller <th...@gmail.com> wrote:
> [JCR-1180] DatabaseFileSystem and DatabasePersistenceManager don't allow
> > choice of db schema
>
> That a nice feature, but I don't think it should be a blocker for 1.4

Agreed. I'll have it if someone sends a good patch before Christmas.

> [JCR-1277] ConnectionRecoveryManager is created twice in DBDataStore init
>
> I'm working in this now.

ACK, thanks.

> > [JCR-1253] Allow to configure autoCommit mode for BundleDB PM to avoid ...
> > - Quite controversial. I'm inclined to dropping this from 1.4, but
> > wouldn't mind if there's some positive outcome soon enough.
>
> I would add it if it really improves performance a lot, but in my view we
> first need to have test results.

Agreed. I'd be OK with including an experimental non-autocommitting
BundleDbPM subclass that wouldn't interfere with any of the existing
code.

> > I'm also getting some backchannel feedback that we should still
> > consider including the proposed database connection pools
>
> I think it shouldn't be a blocker issue for 1.4.

Agreed.

> > it would be better to go with a 1.5 release soon after 1.4
>
> I fully agree.

Thanks for the feedback!

BR,

Jukka Zitting

Re: Jackrabbit 1.4 status update

[Thomas Mueller <th...@gmail.com>]

Hi,

[JCR-1193] war missing jcr jar
> - I think we should have these, and probably some extra facelifting to
> jackrabbit-webapp. I'll still put some effort on these before
> branching 1.4.


A simple browser-based repository tool would be great! (not necessarily for
1.4)

[JCR-1180] DatabaseFileSystem and DatabasePersistenceManager don't allow
> choice of db schema


That a nice feature, but I don't think it should be a blocker for 1.4

[JCR-1277] ConnectionRecoveryManager is created twice in DBDataStore init
> ...
> - Nice to have. It would be great to have these fixes in 1.4, but
> postponing to 1.4.1 isn't that bad.


I'm working in this now.


> [JCR-1253] Allow to configure autoCommit mode for BundleDB PM to avoid ...
> - Quite controversial. I'm inclined to dropping this from 1.4, but
> wouldn't mind if there's some positive outcome soon enough.


I would add it if it really improves performance a lot, but in my view we
first need to have test results.

I'm also getting some backchannel feedback that we should still
> consider including the proposed database connection pools


I think it shouldn't be a blocker issue for 1.4.


> it would be better to go with a 1.5 release soon after 1.4


I fully agree.

Regards,
Thomas

Re: Jackrabbit 1.4 status update

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Dec 31, 2007 3:13 PM, Tobias Bocanegra <to...@day.com> wrote:
> i think that issue JCR-1197 is not fixed yet and i would like to get
> it done for 1.4.
> i will work on it today and try to fix it. however i think that a
> possible patch will not be large, so i can recommit it to the branch
> later if you decide to branch today.

OK, good.

If it takes longer, we can still merge the fix to the branch before
starting the release vote. I'll be doing at least one candidate just
for review before starting the vote. I guess the earliest time for the
the vote to start is the end of this week.

BR,

Jukka Zitting

Re: Jackrabbit 1.4 status update

[Tobias Bocanegra <to...@day.com>]

hi jukka,
i think that issue JCR-1197 is not fixed yet and i would like to get
it done for 1.4.
i will work on it today and try to fix it. however i think that a
possible patch will not be large, so i can recommit it to the branch
later if you decide to branch today.

regards, toby

On 12/31/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> All the open issues for 1.4 have now been resolved or postponed (see
> the individual issues for details), and I'm preparing to branch 1.4
> from trunk sometime today or tomorrow once I've checked that
> everything is OK. I'll produce the first 1.4 release candidate right
> after branching 1.4.
>
> Please speak up (or ping me) now if you still have something that
> should go into Jackrabbit 1.4.
>
> BR,
>
> Jukka Zitting
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: Jackrabbit 1.4 status update

[Jukka Zitting <ju...@gmail.com>]

Hi,

All the open issues for 1.4 have now been resolved or postponed (see
the individual issues for details), and I'm preparing to branch 1.4
from trunk sometime today or tomorrow once I've checked that
everything is OK. I'll produce the first 1.4 release candidate right
after branching 1.4.

Please speak up (or ping me) now if you still have something that
should go into Jackrabbit 1.4.

BR,

Jukka Zitting

Re: Jackrabbit 1.4 status update

[Michael Wechner <mi...@wyona.com>]

Jukka Zitting wrote:

>Hi,
>
>On Dec 21, 2007 9:32 AM, Michael Wechner <mi...@wyona.com> wrote:
>  
>
>>Jukka Zitting wrote:
>>    
>>
>>>I'm also getting some backchannel feedback that we should still
>>>consider including the proposed database connection pools and some
>>>other new features in the 1.4 release.
>>>      
>>>
>>what are these features?
>>    
>>
>
>Mostly about streamlining the installation and configuration process,
>and making it easier to produce well qualified bug reports if things
>go wrong. I'll file these as feature requests in Jira.
>
>The background on this is that with our recent Jackrabbit services
>offering, Day wants to focus more effort into making Jackrabbit an
>easily supportable product for our customers. This also means that
>we'll be assigning more QA resources on release testing, etc. :-)
>  
>

sounds good :-) but still I would suggest to release without these 
(because they don't seem to be critical resp. a real blocker) and I 
think sticking to the guideline "release often" is more important.

Cheers

Michael

>Unfortunately these extra features our product management had in mind
>didn't make it to Jira in time for me to take them into account for
>1.4 planning, leading to this desire to push the release back enough
>to get these features in.
>
>  
>
>>>That would further postpone the
>>>release date and widen the scope of this release that's already by far
>>>the biggest change since our initial 0.9/1.0 releases. I guess it
>>>would be better to go with a 1.5 release soon after 1.4,
>>>      
>>>
>>+1 for releasing 1.4 soon (I guess without connection pools, etc) and do
>>another release soon again
>>    
>>
>
>Agreed, thanks for the feedback!
>
>BR,
>
>Jukka Zitting
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
michael.wechner@wyona.com, michi@apache.org
+41 44 272 91 61

Re: Jackrabbit 1.4 status update

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Dec 21, 2007 9:32 AM, Michael Wechner <mi...@wyona.com> wrote:
> Jukka Zitting wrote:
> >I'm also getting some backchannel feedback that we should still
> >consider including the proposed database connection pools and some
> >other new features in the 1.4 release.
>
> what are these features?

Mostly about streamlining the installation and configuration process,
and making it easier to produce well qualified bug reports if things
go wrong. I'll file these as feature requests in Jira.

The background on this is that with our recent Jackrabbit services
offering, Day wants to focus more effort into making Jackrabbit an
easily supportable product for our customers. This also means that
we'll be assigning more QA resources on release testing, etc. :-)

Unfortunately these extra features our product management had in mind
didn't make it to Jira in time for me to take them into account for
1.4 planning, leading to this desire to push the release back enough
to get these features in.

> > That would further postpone the
> >release date and widen the scope of this release that's already by far
> >the biggest change since our initial 0.9/1.0 releases. I guess it
> >would be better to go with a 1.5 release soon after 1.4,
>
> +1 for releasing 1.4 soon (I guess without connection pools, etc) and do
> another release soon again

Agreed, thanks for the feedback!

BR,

Jukka Zitting

Re: Jackrabbit 1.4 status update

[Michael Wechner <mi...@wyona.com>]

Jukka Zitting wrote:

>
>I'm also getting some backchannel feedback that we should still
>consider including the proposed database connection pools and some
>other new features in the 1.4 release.
>

what are these features?

> That would further postpone the
>release date and widen the scope of this release that's already by far
>the biggest change since our initial 0.9/1.0 releases. I guess it
>would be better to go with a 1.5 release soon after 1.4,
>

+1 for releasing 1.4 soon (I guess without connection pools, etc) and do 
another release soon again

Cheers

Michael

> but I'll
>summarize these thoughts better tomorrow.
>
>BR,
>
>Jukka Zitting
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
michael.wechner@wyona.com, michi@apache.org
+41 44 272 91 61

Re: Jackrabbit 1.4 status update

[Felix Meschberger <fm...@gmail.com>]

Hi Jukka,

Am Freitag, den 21.12.2007, 01:26 +0200 schrieb Jukka Zitting:
> [JCR-995]  Release the OCM component
> - Blocker for the release. I'll look into promoting the OCM component
> from sandbox and preparing it for release in a few days, but would
> appreciate feedback on the current state of the component before that.

I think it is definitely mature for release in 1.4.

A big +1.

All in all, I would think rather release early (and somewhat incomplete
with respect to nice-to-have issues).

Regards
Felix