#7226 NORM Never A: trac improvement: schedule, found, fixed, tested with branches and builds

[Zarro Boogs per Child]

#7226: trac improvement: schedule, found, fixed, tested with branches and builds
-------------------------+--------------------------------------------------
 Reporter:  ggoebel      |       Owner:  coderanger    
     Type:  enhancement  |      Status:  new           
 Priority:  normal       |   Milestone:  Never Assigned
Component:  trac         |     Version:                
 Keywords:               |    Verified:  0             
 Blocking:               |   Blockedby:                
-------------------------+--------------------------------------------------
 A recommendation on how to improve the various ways trac needs to track
 branch+build and scheduling information.

 Currently, 'Milestone' and 'Version' don't appear to have clearly
 differentiated meanings. Both appear to be a combination of branch +
 build. But they don't disambiguate between:
 {{{
 o  schedule
 o  defect found
 o  defect or enhancement implemented
 o  defect or enhancement tested
 }}}

 Note: In the context of 'schedule'... with the move from milestones as
 features to milestones as dates, it is unclear whether Version continues
 to be useful.

 With regards to scheduling
 {{{
 o 'Milestone' should be clearly defined as indicating the oldest
   branch that an issue should be addressed in. With the underlying
   implication that it will be addressed in that and all subsequent
   releases. Ex: '08.Autumn', '09.Spring', 'joyride', ...
 o 'Version' should be replaced with 'Schedule'. Where 'Schedule'
   will indicate when the release manager realistically expects the
   ticket to be completed. Note: YMMV depending on how realistic
   the target date is. When dates slip, the release managers will
   have to re triage 'Schedule' values. Ex: '08-06', '08-07', ...
 }}}

 Note: 'Schedule' is different from and complementary to 'Priority'. The
 implication is that a low priority ticket scheduled for the current month
 would have an effectively higher priority than a high priority ticket in a
 subsequently scheduled month. Schedule combined with facilitating time
 required estimates would enable the release manager to realistically
 juggle expectations of what can be accomplished over the upcoming months.

 To handle 'found in', 'implemented in', and 'tested in', additional
 relationships should be created between the ticket and branch+build.
 Multi-value columns should be avoided for the reasons detailed in #7221.
 Ex: Found In = '08.Autumn.799', 'Update-1.706'

 Likewise, 'found in', implemented in', and 'fixed in' should be presented
 via the UI in the same manner detailed for 'blocking' and 'blocked by' in
 #7221. I.e., an edit text box for adding branch+build info, followed by a
 list of the branch+build's already associated with that ticket.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7226>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system