Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
1. Do other engineers feel this way?
2. From people's experience, has the one-month-after-ubuntu schedule provided concrete advantages? Could we get away with less (e.g. one week)?
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.
Thoughts?
Thanks, Alexandros
To add to Alexandros' thoughts, we typically have our public plan reviews a couple of weeks after LDS, which means that for the most part, all engineering blueprints for the coming cycle must be done by then (before then for the benefit of those compiling the slides, etc. for the plan reviews ;-). So, the idea that work on the closing cycle can still be ongoing even by the week before LDS is almost an illusion.
Some of this might point to the idea that if we've done our jobs planning and scoping appropriately, no remaining work items will be deep or complex so that the LDS pre-preplanning and the output processing that goes on afterward (yet before the official end of cycle) will interrupt us. Of course, it's not a perfect world, so we may not get the smoothest of transitions, but we should at least be able to improve the transition with each passing cycle.
cheers, Jesse
On Tue, May 17, 2011 at 9:54 AM, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
Do other engineers feel this way?
From people's experience, has the one-month-after-ubuntu schedule provided
concrete advantages? Could we get away with less (e.g. one week)?
- 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.
Thoughts?
Thanks, Alexandros
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
In the PMWG, that is what we ended up doing. 1 week before LDS, everything that was still pending was postponed to the next cycle so that work could begin in earnest on planning and *thinking* about the goals for the next cycle.
With the proposed monthly releases, I guess the cadence with Ubuntu becomes moot except where things are delivered into Ubuntu or explicitly required from Ubuntu. My view is that for the most part, Platform team has closer coupling to the Ubuntu release than the working groups.
Regards, Amit
On Tue, May 17, 2011 at 12:22 PM, Jesse Barker jesse.barker@linaro.org wrote:
To add to Alexandros' thoughts, we typically have our public plan reviews a couple of weeks after LDS, which means that for the most part, all engineering blueprints for the coming cycle must be done by then (before then for the benefit of those compiling the slides, etc. for the plan reviews ;-). So, the idea that work on the closing cycle can still be ongoing even by the week before LDS is almost an illusion.
Some of this might point to the idea that if we've done our jobs planning and scoping appropriately, no remaining work items will be deep or complex so that the LDS pre-preplanning and the output processing that goes on afterward (yet before the official end of cycle) will interrupt us. Of course, it's not a perfect world, so we may not get the smoothest of transitions, but we should at least be able to improve the transition with each passing cycle.
cheers, Jesse
On Tue, May 17, 2011 at 9:54 AM, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
Do other engineers feel this way?
From people's experience, has the one-month-after-ubuntu schedule provided
concrete advantages? Could we get away with less (e.g. one week)?
- 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.
Thoughts?
Thanks, Alexandros
W dniu 17.05.2011 10:54, Alexandros Frantzis pisze:
Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
- Do other engineers feel this way?
Yes. I think that linaro has 5-month cycle with one month squandered on LDS, blueprints and catch-up with the previous release where we are still (supposedly) going to make improvements.
I would rather have the very same cycle or even one cycle _before_ Ubuntu ships so that by the time we're at UDS we can have a UDS/sprint hybrid where we already discussed some things earlier, already have some blueprints and code rolling.
- From people's experience, has the one-month-after-ubuntu schedule provided concrete advantages? Could we get away with less (e.g. one week)?
From my point of view it's hard to judge as Validation is strictly outside the main archive, kernel and toolchain where we mostly interact with our Ubuntu brethren. It is however interesting to consider how our cycle would impact Ubuntu if _all_ of Linaro were really releasing once a month.
Thoughts?
Thanks for bringing this up Alf :-)
Best regards ZK
On Tue, May 17, 2011 at 3:54 AM, Alexandros Frantzis < alexandros.frantzis@linaro.org> wrote:
Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
Do other engineers feel this way?
From people's experience, has the one-month-after-ubuntu schedule
provided concrete advantages? Could we get away with less (e.g. one week)?
- 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.
Alexandros, you are absolutely right, this should be taken under consideration. I have mentioned this situation to few tech leads and my idea was to simply plan for 5 months actual development cycle. One thing you have not mentioned and we have to allow for, specially in Summer time, is vacations. We have to allow time for when people are out on vacations. So 5 months make sense to me. Thanks for bringing this issue to light, Mounir
Thoughts?
Thanks, Alexandros
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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.
-- PMM
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
On Tue, May 17, 2011 at 11:12 AM, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
On Tue, May 17, 2011 at 8:40 AM, Peter Maydell peter.maydell@linaro.org wrote:
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.
This would make more sense to me, as we would be normally worried with one sprint, and would also be able to change the planning over the cycle.
Doing a 6 month cycle is quite hard from the engineering perspective, as the last month usually ends up with a huge pile of work to be done.
For the developer platform having the Linaro release one week after Ubuntu seems to be enough already, but then would need to sync with the other WG so we could integrate all important deliverables at the platform.
Cheers,
On 17 May 2011 15:12, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
On Tue, May 17, 2011 at 8:40 AM, Peter Maydell peter.maydell@linaro.org wrote:
[moving planning away from six-month cycles]
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.
Sure. As I understand the idea of an agile product backlog, though, you don't necessarily do full investigation and planning on every item in it (in the way that at the moment we do full down-to-the-work-item blueprints for everything at the start of the six months); instead you can just do broad back-of-envelope estimates and prioritisations and only need to do more detailed planning as things bubble up to the top of the backlog.
-- PMM
On 19/05/11 14:19, Peter Maydell wrote:
Sure. As I understand the idea of an agile product backlog, though, you don't necessarily do full investigation and planning on every item in it (in the way that at the moment we do full down-to-the-work-item blueprints for everything at the start of the six months); instead you can just do broad back-of-envelope estimates and prioritisations and only need to do more detailed planning as things bubble up to the top of the backlog.
-- PMM
The way I see this: It means the backlog items targeted for the next sprint/month get their work items defined in detail, whereas the remaining backlog items not yet in the radar, can get only a rough breakdown to work items. For the not detailed planned blueprints one should consider flagging any risks which may impede the work early on.
Ideally higher priority items are taken earlier in the cycle, since the cost of their delay is higher.
What comes to estimating, it ought to happen regularly - for example before the beginning of a sprint/month. Use ideal/uninterrupted hours/days for your estimates.
Cheers,
On Thu, May 19, 2011 at 7:29 AM, Ilias Biris ilias.biris@linaro.org wrote:
On 19/05/11 14:19, Peter Maydell wrote:
Sure. As I understand the idea of an agile product backlog, though, you don't necessarily do full investigation and planning on every item in it (in the way that at the moment we do full down-to-the-work-item blueprints for everything at the start of the six months); instead you can just do broad back-of-envelope estimates and prioritisations and only need to do more detailed planning as things bubble up to the top of the backlog.
The product backlog defines the release, which should stay at 6m in my opinion. With agile, just because you have a demoable, releasable chunk of work done at the end of a sprint, doesn't mean that you actually have to release it. It is just a demo for stakeholders to make sure everything is on track. More interaction with the stakeholders is key to this working. Then you don't work heads-down for 6m on something just to find that out that the target has moved.
-- PMM
The way I see this: It means the backlog items targeted for the next sprint/month get their work items defined in detail, whereas the remaining backlog items not yet in the radar, can get only a rough breakdown to work items. For the not detailed planned blueprints one should consider flagging any risks which may impede the work early on.
Ideally higher priority items are taken earlier in the cycle, since the cost of their delay is higher.
What comes to estimating, it ought to happen regularly - for example before the beginning of a sprint/month. Use ideal/uninterrupted hours/days for your estimates.
Yes, plan often - it is less of a disruption and takes less time if it happens often. Every sprint starts by re-prioritizing the backlog.
Cheers,
-- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, May 17, 2011 at 02:40:22PM +0100, Peter Maydell wrote:
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...
You are right that it doesn't matter if the planning is at what is conceptually the beginning or end, because no matter how you see it, the previous cycle is already finished. On the other hand, it does matter if the planning happens during the cycle (one month before the end in our case), because it disrupts it.
Right now the planning periods are fixed in time and we are not aligned to them. We all know how costly unaligned accesses can be ;)
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.
I agree with Mounir's thoughts: it is essential to have a medium-term (6 month) vision that can be used as a guide when trying to make decisions. One month is great for tactics, but it is too short for forming a coherent and solid strategy.
Thanks, Alexandros
On Tue, May 17, 2011 at 3:54 AM, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
Hi all,
I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
- Do other engineers feel this way?
At the moment I think the 1 month delay after the Ubuntu releases is less an optimal. I think a shorter time period between the ubuntu release and the linaro release would work much better. A week would be my suggestion.
- From people's experience, has the one-month-after-ubuntu schedule provided
concrete advantages? Could we get away with less (e.g. one week)?
- 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.
With the direction to go to monthly releases, I am a bit concerned how that will fit into the larger upstream ubuntu 6 month release cycle. The first few months of the cycle where software tends to be under more rapid development therefore lower quality seems unwise to use as the only base for a release.
Compilers, kernels, tools, work group output I can very easily see it released on a month basis as appropriate for the code in question. Just like last cycle, it seems easy to define the work item and the release schedule / mechanism in the blueprint.
For the linaro reference images, I'm not sure that going to a monthly release makes much sense unless we had both a stable (which would currently be natty) and development (now oneiric) based release. Then WGs could decide where their output should go.
Thanks for starting this discussion Alexandros.
Regards, Tom
On Tue, 17 May 2011 11:54:18 +0300, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
- Do other engineers feel this way?
I can certainly say that trying to have a release in the same week as the deadline for drafting specs/workitems and creating slides for the public plan reviews has been a strain.
At the very least we should ensure that they don't line up in exactly that way again.
Thanks,
James
Agreed.
On 26 May 2011 11:12, James Westby james.westby@linaro.org wrote:
On Tue, 17 May 2011 11:54:18 +0300, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
- Do other engineers feel this way?
I can certainly say that trying to have a release in the same week as the deadline for drafting specs/workitems and creating slides for the public plan reviews has been a strain.
At the very least we should ensure that they don't line up in exactly that way again.
Thanks,
James
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Picking up this subject again, here is a wiki page with the ideas mentioned in the thread and (currently) my comments on those ideas:
https://wiki.linaro.org/ProjectManagement/ParkingLot/DevelopmentCycleProposa...
You can check out the proposals, correct if there is anything wrong/missing, and add more. I am thinking to get some basic voting going on there so that you can show your preference, although some ideas are really interconnected.
I would like to keep this topic moving, in order to attempt solving it early and adjust as we go on.
Best,
Ilias
On 17/05/11 11:54, Alexandros Frantzis wrote:
Hi all,
So my questions/suggestions are:
Do other engineers feel this way?
From people's experience, has the one-month-after-ubuntu schedule provided concrete advantages? Could we get away with less (e.g. one week)?
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.
Thoughts?
On Tue, May 31, 2011 at 5:27 AM, Ilias Biris ilias.biris@linaro.org wrote:
Picking up this subject again, here is a wiki page with the ideas mentioned in the thread and (currently) my comments on those ideas:
https://wiki.linaro.org/ProjectManagement/ParkingLot/DevelopmentCycleProposa...
You can check out the proposals, correct if there is anything wrong/missing, and add more. I am thinking to get some basic voting going on there so that you can show your preference, although some ideas are really interconnected.
I would like to keep this topic moving, in order to attempt solving it early and adjust as we go on.
I have added my comments to the page. I like the second idea: use an internal deadline. "End the cycle for your working group prior to the LDS - go to the LDS having closed all items, and postponed anything that was still opened. " The team is supposed to start drafting the the next cycle blueprints in preparation of LDS. Effectively, this is what we have been attempting to do.
Regards, Mounir
Best,
Ilias
On 17/05/11 11:54, Alexandros Frantzis wrote:
Hi all,
So my questions/suggestions are:
Do other engineers feel this way?
From people's experience, has the one-month-after-ubuntu schedule
provided
concrete advantages? Could we get away with less (e.g. one week)?
- 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.
Thoughts?
-- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-
Alexandros Frantzis -
Amit Kucheria -
Ilias Biris -
James Westby -
Jesse Barker -
Kurt Taylor -
Mounir Bsaibes -
Peter Maydell -
Ricardo Salveti -
Tom Gall -
Zach Pfeffer -
Zygmunt Krynicki