Framework status, week of Monday, May 29th

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Framework status, week of Monday, May 29th

Jayson Minard (ZF)
Framework status, week of Monday, May 29th Hello everyone,

I’m back in the office after being on the road last week to get a few framework initiatives underway, meet a few of the external contributors in person, and work out a rough road map proposal with the internal team.  The basic ideas that we decided to put forward are:

  1. Finish 0.1.4 by early next week (around the 6th).  
  2. Spend around 2 weeks on proposal catch-up, review, and infrastructure improvements, possibly drop a 0.1.5 with fixes only to the newer additions present from 0.1.4 and anything else needing them
  3. Then start working on 3 week milestones so that we drop a release at a regular interval and get a rhythm going
  4. As we get the milestones moving, we start looking at scope for 1.0 with a target (goal) of around September

The first of the 3 week drops would be 0.2.0 which would include the results of the proposal review.  Accepted proposals would move to incubator, pending and other proposals would go into the laboratory.  

With a regular rhythm, it provides a solid sense of when things will happen, what state we are in, and also pushes us back to fully tested, as-close-to-produciton-as-we-can-be code more regularly.  We never go too far off the deep end.  We pay the integration tax incrementally rather than letting it pile up on us until the end.   Plus, since its “agile” we stay buzzword compliant.

The schedule for a 3-week milestone would be to start on the trunk on a Monday morning and wrap up just under 3 weeks later on a Friday, let it bake until Monday at which point we branch the release expecting no changes to the release branch.  Tuesday afternoon we publish the release.  Meanwhile work on the next milestone has already begun on the trunk the day before.  This 3-week block includes all coding, full unit testing, and documentation.  This means biting off smaller chunks at a time, but making them more complete each round.

We will start to use our toolset a bit more with pointing issues and tasks at a milestone and try to know what we are doing at the start of a milestone before it begins.  That means contributors will provide an idea of their expected changes ahead of the milestone so that we can give them as much help as possible to completing them during.  It is up to you to set expectations that you can meet, or be sure to communicate early when something doesn’t go your way.  Changes and issues will happen, lets just communicate them as quickly as possible.  And if you can’t set expectations ahead of time, then do the work offline and bring it in when ready.

To make this work, we’ll be updating our toolset during the 2-week proposal catch-up period to make sure we have everything we need to move quickly and with everyone having a way to see where we are at, who is volunteering where, etc.  I will be making a list of proposed changes this week so that we can discuss them and put them into place next week.

Lastly, since 0.1.4 needs to start wrapping up, be careful not to open any gaping wounds in the meantime <g>.  And for those waiting on the new router work, I’m finishing my review of it shortly to get it going to close for 0.1.4 (which is the item most likely to change the 0.1.4 date).

Any thoughts are appreciated...
--j