[Cosmo-dev] Next steps for Cosmo

[Ted Leung]

Hi folks,

I thought I would try to tie together Jared's note on "quick  
releases" and Brian's note on "Cosmo 0.8", and try to give a sketch  
at how we things might change in the Cosmo world.  My intent in doing  
this is not to set down a definitive notion of what we will do, but  
to try and give a flavor of what I think a desirable outcome looks  
like, and then get people's reactions.  In particular, are there  
things that are missing, are the obstacles preventing us from getting  
to a scenario  like this, and so forth.   If you have questions,   
concerns, or ideas *please* speak up.

With that said, here goes:

1. We are currently testing Cosmo 0.7 RC4.   Unless we find some  
catastrophic bugs, this is going to become Cosmo 0.7.0.    Between  
now and the Cosmo 0.7 launch, most people should be working on  
beefing up our test coverage for Cosmo.   This is particularly  
important for the web UI.    Also, there will be a series of IRC QA  
sessions between now and than.   If you are a Cosmo developer you  
should be participating in these sessions.

2. After we launch Cosmo 0.7, we plan to do (at least) 4 Cosmo 0.7.x  
bug fix releases, once a week.   When I originally proposed this, my  
expectation was that the release happens every week and whatever  
stuff is actually done within a particular release frame is what will  
go into that release.   If it isn't done, it doesn't go into the  
release.    We have not yet worked out all the details for how this  
process is going to work, but here is a proposal:

- PPD comes up with an overall priority for all bugs currently  
targeted for Cosmo 0.7.1 (How they do this is up to them).   We  
preserve these priorities, and then put all bugs marked 0.7.1 into a  
new milestone 0.7.Future.

- Prior to the start of each release "frame", we (TBD - but likely a  
version of the bug council) figure out which bugs from 0.7.Future, as  
well as critical bugs reported by end users.  In order to do this  
effectively, we will need to work with individual developers to make  
sure that bugs can be fixed in the time allotted to a release.   It's  
possible that a bug that gets prioritized will take more than a week  
to fix.  If this happens, the developer will start working on the  
bug, but the fix will have to wait for the next release for  
inclusion.  An example of a something like this is the Safari support  
that we punted.  It's unlikely that we can fix all the Safari bugs in  
a single week, but we can start fixing them until they all get  
done.   Whatever release the last bug is in will be the release that  
supports Safari

- developers make the necessary fixes

- at a well known date (we don't know what this needs to be yet), QA  
begins qualifying the release - bugs which are not fixed by this date  
are dropped into the next release - partially committed fixes will  
need to be backed out.

- while QA is validating, the "bug council" picks the next set of  
bugs and the process repeats.   Once validation is complete, we issue  
the release and update the hub.   There is going to be an element of  
re-planning at each release, because we'll need to adjust to what  
happened (or didn't) in the previous release frame.

This proposal is a large change from our existing practice, and I  
think it's safe to say that we will have some hiccups and learning as  
we go in order to make this happen.

3. We have a branch for Cosmo 0.8 that Brian is working in.  Right  
now, the only goal for Cosmo 0.8 is to be compatible with Leopard  
(this mostly means iCal 3).   We've been kind of loose about exactly  
what this means.   Mikeal observed that Leopard iCal does scheduling  
and we dont' support scheduling and currently our plan is not to do  
scheduling, although I think we might be revisiting that discussion.   
Let's assume for the sake of simplicity that 0.8 does not include  
scheduling (if we do scheduling it ends up in a later release due to  
size).

If you assume that Cosmo 0.7.0 launches next week, and then add four  
weeks for the bug fix releases, then that puts us just about at the  
end of September.   Leopard is supposed to launch in October, but we  
don't know exactly when.  This probably means that we should plan to  
be done with Cosmo 0.8 in time for an early October launch of  
Leopard.   You'll notice that this leaves very little time for anyone  
except Brian to work on features for Cosmo 0.8, so at this point I  
think it is very unlikely that we will do any other features for  
Cosmo 0.8.   We haven't had a real discussion of this with PPD yet,  
but the laws of physics seem pretty clear to me here.

4. After Cosmo 0.8, I would like to see us get on a regular release  
cycle that lasts somewhere between 2-4 weeks.   The 4 1 week releases  
for 0.7.x as a special event due to the need to stabilize Cosmo  
during its debut to a large audience, but I also think that a 1 week  
pace is probably a little too frenetic. It is very important that we  
be able to turn releases of Cosmo quickly in order to address user  
feedback, and to continuously improve the Chandler Hub service.    
There are several areas which need to change in order to be able to  
do this:

- We need to plan in smaller, less interdependent units, and plan for  
regular releases to happen.   We will be revamping our planning  
process to make sure that this happens -- this is a Chandler project  
wide goal, not just a Cosmo goal.   The days of 3-6-9 month release  
cycles needs to be over.

- We need to improve our automated test coverage.   The  
responsibility for that lies both with developers and with QA.

I know that this is a long message and there are a lot of changes  
being proposed.  At the same time, we've been saying for months that  
we'd like to shorten our release cycles after preview, and that time  
is just about upon us.   Please speak up with your questions,  
concerns, and ideas.

Thanks,

Ted