[cgl_discussion] PoC 8/27/03 Minutes

Steven Dake sdake at mvista.com
Thu Aug 28 14:40:59 PDT 2003


posted to wrong list earlier

Thanks
-----Forwarded Message-----
> From: Steven Dake <sdake at mvista.com>
> To: John Cherry <cherry at osdl.org>
> Cc: cgl_tech_board at osdl.org
> Subject: [cgl_tech_board] PoC 8/27/03 Minutes
> Date: Thu, 28 Aug 2003 11:18:19 -0700
> 
> John
> 
> Thanks for beating me to the punch :)
> 
> I was working from home yesterday and unable to send out the updated
> information.  Here are the minutes.  The updated spreadsheet will be
> sent out later today.
> 
> POC 8/27/03 Minutes
> 
> Attendees
> ---------
> Rusty @ Intel
> Mika @ OSDL
> Mark @ OSDL
> John @ OSDL
> Johannes @ Nokia
> Julie @ Intel
> 
> * 2.7 List
> ----------
> AR Julie to change poc tracking for work requird and maturity columns
> AR Steve to change spreadsheet to start maximum work requird at 1
> instead of 0
> AR Steve to send message to discussion when item is to be deleted from
> 2.7 list.
> AR Steve to contact Peter to determine if application restart has been
> renamed.
> AR Rusty to ask Inaky about robust mutexes work requuired in calendar
> months and maturity.
> AR Rusty to provide steve with IpV6 SNMP get calendar months.
> AR Rusty to provide steve info on priority inheritance
> AR Steve to talk to Ville about page flushing priority level and flag to
> be deleted.
> 
> Mika suggested priority two items use an inverse root calculation
> (1/priority^2) when calculating values in the spreadsheet so that
> priority 1 will have higher weight then priority 2s.  Steve to make the
> changes.
> 
> Lots of discussion on maturity levels.
> 
> We decided on:
> 0 - Discussion
> 1 -
> Started                                                                          2 2 - Experimental
> 3 - Production
> 4 - One distro mainlined
> 5 - stable kernel mainline
> 
> We also decided to have a maximum 18 months of calendar work for
> specifying timing.  It was decided this time should include the actual
> work of working with the community to mainline the changes.
> 
> Percentage weights not altered, decided we could take a look at that
> after the updated values are available.
> 
> Lots of individual discussion on each priority level which is captured
> as values in a spreadsheet.
> 
> * Top ten
> ---------
> No time left, pushed to next week
> 
> * Opens
> -------
> Reiser 4 relationship to specs came up, Mika decided to bring up with
> specs
> subgroup.
> 
> 
> On Thu, 2003-08-28 at 10:23, John Cherry wrote:
> > For those that could not attend the PoC this week, we took the
> > spreadsheet that Steve attached and attempted to assign "work required"
> > and "maturity" values to the PoC 2.7 kernel features.  We attempted to
> > be consistent with the maturity definitions used in the spec group, but
> > there were some minor variations.  Here are the definitions that were
> > used by the PoC:
> > 
> > 0 - Discussion (lots of talk, no code)
> > 1 - Started (open development site established, development underway)
> > 2 - Experimental (working code exists, but not ready for mainline and
> >     may not meet the requirements yet)
> > 3 - Production (code is being used in production environments, may be
> >     included in test kernel(s))
> > 4 - Distro mainline (code included in at least 1 commercial distro - 
> >     differs slightly from specs definition)
> > 5 - Mainline (code is in the stable kernel, still could be enhanced
> >     and maintained so "work required" may still have a value)
> > 
> > The "Work Required" value for each 2.7 item was based on an 18 month
> > maximum timeframe, so values in this column are 0-18.  Estimates for
> > work required have some tricky definitions that we should be aware of.
> > 
> >    - Estimates are calendar time, not staff months.
> >    - Projects which have not started yet use estimates based on
> >      one person working on the feature.
> >    - Estimates include "time to gain mainline acceptance".  This
> >      can be up to 6 months after code is complete.
> >    - Estimates will need to be revisited regularly to keep them
> >      in the realm of reality.
> > 
> > The objective of this exercise is to determine priorities, both from an
> > lkml perspective and from a CGL steering perspective.  Several ARs were
> > given to contact the projects involved to get reasonable estimates for
> > both maturity and work remaining.
> > 
> > Thanks to Steve for putting this spreadsheet together.  This tool is
> > very valuable in determining development priorities and in communicating
> > with developers.
> > 
> > John
> > 
> > On Tue, 2003-08-26 at 13:33, Steven Dake wrote:
> > > Folks,
> > > 
> > > Attached is a spreadsheet that makes another attempt at providing a
> > > mechanism for describing 2.7 feature lists for steering and LKML.
> > > 
> > > for LKML Priorities
> > > 	less work required = higher priority value
> > > 	higher maturity = higher priority value
> > > 	higher specs priority = higher priority value
> > > 
> > > The policy behind this list is to deliver a list that is more likely to
> > > be accepted by LKML.
> > > 
> > > For steering Priorities:
> > > 	more work required = higher priority value
> > > 	less maturity = higher priority value
> > > 	higher specs priority = higher priority value
> > > 
> > > The mechanism behind this list is to deliver a list to steering of which
> > > kernel features are in jeopardy 
> > > 
> > > We will discuss this list in full detail in the PoC meeting on 8/27/03. 
> > > Please be prepared to discuss the algorithm of the list and the values
> > > of the list.
> > > 
> > > Thanks
> > > -steve
> > 
> > 
> 
> _______________________________________________
> cgl_tech_board mailing list
> cgl_tech_board at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_tech_board
> 
> 




More information about the cgl_discussion mailing list