[MeeGo-pm] Release 1.2 MM3 - to be or not to be ...

Wed Feb 2 11:42:37 PST 2011

I'll give a hypothetical example of different target platform schedule.
	Target platform power-on is Feb 22, 2011 with MX2573 chipset.
		Power on drivers for the MX2573 chipset are available from vendor on Feb 1,2011, these drivers only run on the MX2573 and no other chipset. 
	Other IVI specific critical components that interact with these drivers and provide IVI services not used on other MeeGo platforms. 
	Target platform Alpha deployment to key customers is April 22, 2011-02-02
	I have 20 developers, RE and QA dedicated to integrating, testing, debugging and fixing these new drivers and critical IVI specific components during the power-on to Alpha phase of this platform from Feb 22, to April 22. 

Under the current process definition, I can't use the meego build server to support this platform for approximately 3 months of the 6 months release cycle from the time of "feature Freeze" through the RC build when the Trunk is forked and probably for another several weeks until the Trunk team finishes the final release and gets around to completing the Trunk merge window updates and produces a new stable Trunk. For example for 1.2 the only time I could integrate new IVI features was 2 months from late November to late January. Hardware schedules do not always line up with the MeeGo open feature window when it is only 2 months out of every 6. 

I'll give you a hypothetical example of different objectives. 
	For MeeGo IVI 1.2 we might:
		have no vendor planning to ship product based on MeeGo 1.2 
		Application quality is set to "Sample Demo" quality, not "Reference" or "Product" quality
		Request from customers with deployment plans in late 2012 for demonstration of capability and  flexibility to integrate their proof of concept demos in March in order to meet customer milestones for continued commit to product in 2012.

regards
Joel

-----Original Message-----
From: carsten.munk at gmail.com [mailto:carsten.munk at gmail.com] On Behalf Of Carsten Munk
Sent: Wednesday, February 02, 2011 10:44 AM
To: Clark, Joel
Cc: jari.tahvanainen at nokia.com; meego-pm at lists.meego.com
Subject: Re: [MeeGo-pm] Release 1.2 MM3 - to be or not to be ...

2011/2/2 Clark, Joel <joel.clark at intel.com>:
> I agree that the code bits that run on all platforms should have common milestones and exit criteria.  But the original poster went on to specify milestone exit criteria for bits that are not common, that are specific to verticals.  These are the elements that I believe should be subject to milestone and exit criteria set by the vertical PM, development, Release Engineering and QA.  Verticals have different requirements for level of maturity and quality, depending on their release objectives, target platform schedules and key customers.

I guess the interesting question is if whole project moves to MM3 or
only some parts of it. Since MM3 still allows work to be done through
CCB (see further down), why shouldn't this be enforced across the
verticals?

When I speak about milestone criteria, this is
http://wiki.meego.com/Release_Engineering/Milestones#MM0 - which is
very generic for fitting the MeeGo requirements process, the QA
process and release process.

> For example if IVI has an application that sends a message via the automotive network services stack over MOST bus to set the configuration of the heating and air conditioning unit in the car, the IVI team may well decide it is OK for this application to first appear in a build on Feb 22,  roughly one month after the "Feature Freeze" defined for the core.  Since these bits will never run on any non-IVI device, this decision should be made by the IVI team and not blocked by other devices or the core team.

This problem usually happens in Core and Handset too, though :) Core
CCB [change control board?] or Handset CCB (usually the vertical's
release management , architect, product manager, program manager, QA,
etc) gets together, judges what risks there are to letting things in
past freeze into their vertical or to Core. The goal is to make a
release in the end without too many bugs. So I would expect a IVI CCB
to exist too that enables this kind of thing.

(additional quote from Joel)
> There for the IVI feature freeze for IVI specific bits may not be at
> the same time as the feature freeze for core or handset because we
> have different objectives for quality, enabling, and target platform
> schedule. The current process has a tendency to force us to miss our
> target schedules by 1-2 months, because the freeze for IVI specific
> bits happens too soon.

This one I'm a little worried about, is it possible for you to
elaborate on what different objectives for quality, enabling, target
platform schedule exist for IVI? And what problems do you see with
current process/plans?

I mean, we should release every 6 months exact. Test cases are worked
out together by vertical's PM and QA anyway for the requirements
specified on the roadmap and usually bugs end up being marked as
release blockers or not, effort put towards them.. and a release of
MeeGo (Core + verticals + etc) comes out, hopefully not too broken?

Reaching for "# No major and critical bugs present, # Moderate amount
of normal and minor bugs present, # No major performance or
reliability issues open " isn't unreasonable for shipping code, at
least.

The problem with if you're out of sync is that it gets difficult for
you (IVI) to get things admitted to Core, for instance, if there's
such a need when Core is in deep freeze and you're only in MM3,
updated developer documentation and so on and making the deadline of a
release..

BR
Carsten Munk

>
> regards
> Joel
>
>
> -----Original Message-----
> From: carsten.munk at gmail.com [mailto:carsten.munk at gmail.com] On Behalf Of Carsten Munk
> Sent: Wednesday, February 02, 2011 12:14 AM
> To: Clark, Joel
> Cc: jari.tahvanainen at nokia.com; meego-pm at lists.meego.com
> Subject: Re: [MeeGo-pm] Release 1.2 MM3 - to be or not to be ...
>
> 2011/2/1 Clark, Joel <joel.clark at intel.com>:
>> I will say once again that the milestone exit criteria for each vertical
>> device segment should be set by the vertical device segment team based on
>> their segment requirements, not by the core team.
>
> I've been parsing this since last night and I'm wondering what is
> dictated by Core in this particular case.
>
> We have four parties (at least) in Core and each vertical: Program
> Management, Development, Release Engineering and QA, working together
> to:
>
> * Actually have a MeeGo release (RE)
> * Contribute to the MeeGo release (Dev)
> * Plan MeeGo release contents (PM)
> * Assure the quality of a MeeGo release (QA)
>
> There is general consensus, at least from what I know, that entire
> project follows a 6 month release schedule
> (http://wiki.meego.com/Release_Engineering/Release_Timeline ). The
> reason for this is to bring out all items of a MeeGo release
> (including SDK and verticals) at same time and that is actually a
> quality release.
>
> In order to synchronise work within the project, we have the
> milestones - we can't have new things being pushed into Core day
> before release, we can't postpone adding features to verticals until
> the last minute (risking quality), etc.
>
> The process goes along lines of:
>
> * PM plans requirements to be included in a certain release. QA
> proposes test cases for these requirements, builds things like
> http://wiki.meego.com/Quality/Plans/Handset_UX_test_plan#Test_Sets.2C_Definitions_and_Priorization
> - commitment to be implementing features is done and requirements are
> accepted
>
> * Development starts based on requirements, QA does daily testing
> based on test cases. RE allows contributions to enter based on
> requirements and QA results along. RE marks features as RELEASED when
> they're entered into the repositories. QA marks features as VERIFIED,
> etc.. A lot of material around on wiki for this.
>
> * Feature freeze hits, and the four parties step together to discuss
> what should contributions should be let in and what shouldn't, based
> on risk to be actually able to make a quality release.
>
> etc.
>
>> Definition: MM3 - Feature development phase completed
>>
>> ·         All planned features integrated
>>
>> o    Medium and low risk items
>>
>> o    Lower priority items
>>
>> ·         All Data flows verified from UX
>>
>> ·         Reliability gaps identified
>>
>> ·         Development focus switched from introducing new features to fixing
>> bugs
>>
>> ·         Translations done
>>
>
> I'm of the opinion that these exit criteria actually matters and is
> valid for -all- verticals, -including- Core, due to the way the MeeGo
> requirements process and release process works.
>
> We can't build a SDK if we're on a constantly moving target of
> requirements and APIs. We can't write translations if code and UI is
> constantly changing. We can't release MeeGo contents that are crap.
> Vendors are supposed to build upon this platform, not spend ages
> fixing bugs in what we deliver.
>
> If Core and/or verticals are not meeting these goals, something has
> gone wrong in the collaboration and work between and done by PM, RE,
> Developers and QA of that area and we now have to deal with the
> fallout of not meeting these goals (as it really doesn't look too good
> for any of us), delay some features, prioritize them, let some in
> despite feature freeze while maintaining quality. And most
> importantly, make notes of what we did wrong this time around to not
> do it next time.
>
> My final point is that this process happens or should happen between
> IVI PM, IVI RE, IVI Developers and IVI QA. As well as it happens
> between these people/groups on all other verticals - but it isn't Core
> dictating this process.
>
> It's a global project release process to make sure we reach the goal
> of actually making a quality release, even of the verticals.
>
> Jari has delivered an objective view of how we're doing in terms of
> quality and delivered features.
> http://wiki.meego.com/Release_Engineering/Plans/1.2#MeeGo%201.2%20Features%20Status
> has had a similar view since forever in terms of delivered features.
>
> And it's time for all of us to step up to our roles (actually, it was
> already back at 1.2 start) and do some planning, some postponing, some
> development, get some features implemented that are vital to 1.2 and
> most importantly, getting bugs found and fixed. And get 1.2 out the
> door in a proper form - and learn from our experiences to make things
> better in 1.3.
>
> BR
> Carsten Munk
> Nokia N900 Hardware adaptation maintainer
>