possible release time line change proposed

Colin Clark colin.clark at utoronto.ca
Fri Mar 20 21:10:07 UTC 2009


Justin,

I think this makes a lot of sense. Bug squashing is moving along a  
feverish pace, but we've been lagging behind a bit in terms of  
reviewing patches as they are posted. An extra day would help ensure  
that our code quality stays high.

With this in mind, there are a few other interesting topics that are  
emerging during the parade. I've been working on the new build scripts  
for Infusion 1.0 based on Simon Wang's patch. There are some  
interesting layers of complexity to this work, touching on a previous  
discussion we had on list about whether to modify our directory  
structure so that assets for a component are more self-contained.

One of our core goals for the 1.0 release is ensuring consistency  
across the board. For example, our decision to normalize class names  
across all components and the FSS. There's probably a bit more "i  
crossing" and "t dotting" left to be done. These sorts of changes  
cross-cutting changes are easier to do when we aren't fixing bugs and  
managing patches.

I'd like to propose that we extend our release by a week to give us  
time to tweak and test our build scripts and ensure that we're  
consistent across the board in terms of class names, directory layout,  
and so on. That little bit of extra polish that comes with a 1.0  
release.

Here's my proposed timeline:

Bug parade: last day is March 24
i-dotting/t-crossing parade: March 25-30
Completely code freeze: March 31
Release: April 7

Thoughts?

Colin

On 20-Mar-09, at 4:47 PM, Justin wrote:

> Hello,
>
> Bug-parade is moving along well, but could use another day to get  
> fixes in and have time to complete code reviews and testing.
>
> This would require the shifting of code freeze and the release date.
>
> Current Timeline
>
> Bug Parade: last day is March 23
> Code Freeze: March 24
> Release: March 31
>
> I would like to add a day to the bug parade, but would still need  
> the four days for testing. I'm not sure it is a good idea to release  
> on April 1st and there may be some issues that will take longer to  
> properly fix.
>
> Anyone have any dates that they think would make sense and be  
> acceptable.
>
> Thanks
> Justin
> Justin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org




More information about the fluid-work mailing list