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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work