[Cosmo-dev] Summary of Cosmo meeting August 24, 2006

[Ted Leung]

On Aug 28, 2006, at 5:08 PM, Priscilla Chung wrote:

> So I just want to confirm that I prefer splitting out 0.5 into  
> milestones. I want to make sure after each significant milestones,  
> the release candidate is given to QA for testing. Please note a  
> when I say significant milestone, it does not mean a significant  
> release candidate.
>
> I just want some clarification about the hibernate work. Perhaps  
> this has been discussed on the list? If so, could someone please  
> point me to the e-mail thread that explains what it is. That would  
> be great.

Brian supplied a fairly technical description here: <http:// 
lists.osafoundation.org/pipermail/cosmo-dev/2006-July/001041.html>

>
> In layman's terms what is hibernate specifically and how does it  
> improve performance or scalability? Why is this important to do for  
> beta?

Hibernate is tool for helping developers work with a relational  
database.   The precise name is "object/relational mapper".     It is  
important to do this for beta because we know that we are going to  
have scalability problems that we cannot solve using Jackrabbit/JCR,  
which is our current storage solution.   We also have no good way to  
do backups at the moment, and going to a Hibernate based solution  
will allow us to use the standard relational database tools to backup  
a Cosmo instance.   Jared has indicated that he would like to see a  
hibernate based version hit the trunk by the end of October in order  
to have enough time to work on the hosted service plan for Beta.

It should also be the case that switching to a Hibernate based  
solution will allow us to address some of our performance problems  
much more easily that we are currently able to.   I'll leave it to  
Brian and Randy to talk about the actual performance increases that  
they are observing.

Switching to a new storage layer is risky and potentially  
destabilizing.   Given that we need solutions for scalability and  
backup for the hosted service, it is better to make the switch  
earlier so that we have a long enough period to find problems.

>
> I think I am having trouble gauging the importance of technical  
> features. I'm not arguing if this specific feature needs to be  
> done, but I need to prioritize how technical features and product  
> features fit into planning releases and timelines. The whole group  
> (not just the technical team) needs to understand what these  
> features bring in a way that lets us prioritize technical features  
> users never "see" with respect to product features more visible to  
> end users.
>
> For example:
> + If hibernate speeds up Chandler by 800% today, then yes, its a  
> very good thing to do.
> + If the benefits of hibernate only kick in when we have 2000  
> concurrent requests, it may be putting the cart before the horse.  
> 2000 concurrent requests might happen for 5 minutes a day when we  
> have 50,000 registered users.
>
> One last thing relates to the naming of the release candidates.  
> Does anyone use 'M' for their releases? Do we want to start  
> following the desktop naming conventions and start calling it  
> Alphas/Betas or do we want to continue using 0.5.1, 0.5.2, etc. In  
> either case I want to make sure we follow conventions of what the  
> developer community is already accustomed to.
.
The Eclipse Foundation, among other's designates it's milestone  
releases using 'M'.   I'm not particularly wedded to the 'M'  
designation.   The important thing in my mind is that whatever these  
release artifacts are named, they are in the middle of where we are  
now.   We either have builds which are not tested by QA or we have  
full releases which involve QA, Marketing, landing pages, etc.    I  
just want us to have some intermediate steps which can be QA'ed  
without invoking all of the release machinery.

Ted