On Tue, May 17, 2011 at 8:40 AM, Peter Maydell
<peter.maydell@linaro.org> wrote:
On 17 May 2011 09:54, Alexandros Frantzis
> So my questions/suggestions are:
>
> 1. 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.
> 3. 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