On Tue, May 17, 2011 at 8:40 AM, Peter Maydell peter.maydell@linaro.orgwrote:
On 17 May 2011 09:54, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
So my questions/suggestions are:
- Do other engineers feel this way?
From a working group perspective, the Ubuntu cycle isn't very significant -- everything we do is on one month cycles except for the planning-and-UDS bit.
- If we don't change anything we should at least make this situation very clear to engineers/managers, so that they can plan accordingly:
~5 months of normal work, starting two weeks after LDS and ending one week before the next LDS. Keep the rest for planning/LDS and spec-ing, plus some light work.
If we're going to do up-front planning for the whole six months then yes, I think we definitely need to leave time for the planning stage. I don't think it matters whether we do it at what's conceptually the "end" of the cycle or the "beginning", as long as we don't try to schedule "six months work and one month's planning" into six months of realtime...
The other idea is that perhaps we could bring the planning more into line with the 'monthly cadence' instead, so that we spread planning/TSC direction/feedback throughout the cycle rather than doing it only twice a year. I don't know whether that's feasible.
Not sure how this can be accomplished without also spreading the 6 months disruption to monthly disruptions. It is better to have a longer term plan so the engineers would know what to focus on for a good period of time. In Agile lingo: The long term plan or goals is called Product backlog. The month to month plan (which a sub-set of the Product Backlog) is called Sprint backlog. As Linaro is adopting the month to month release, we may have to think of Product backlog what we are delivering in the cycle Vs the Sprint Backlog what we will be delivering month to month.
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev