Difference between revisions of "StoryBoard/Task Branch"

Latest revision as of 16:34, 24 March 2014

User stories

Bug coordinators and developers want to open backporting tasks (to milestone-proposed, to stable branches) as part of a bug story
Release management needs to track what made it to a given milestone and/or final release and point release

Design

Tasks should have two additional properties:

branch: the branch the task is supposed to land in (for projects with a code repository attached to them). Defaults to master.
milestone: the first milestone or version where the fix landed.

Branch is selected by the user as part of the task creation (defaults to master). For autocreated tasks, it's set based on the change's target branch.

Release is set as part of the release process: when a milestone-proposed branch is cut, we collect all master-landed fixes without a release set and mark them as released in the corresponding milestone. Then when the milestone is tagged, we collect all the milestone-proposed-landed fixes (if any) and mark them as released in the corresponding milestone as well.

Implementation

New tables:

branches: list of branches available (master, stable/havana...). Maps n:n to projects through a mapping table
cycles: group of milestones (icehouse). Maps n:n to projects through a mapping table
milestones: list of milestones available (icehouse-1, icehouse-2, icehouse-rc1...). Each belongs to a cycle

New fields:

tasks should have two new columns:
- branch_id referencing a row from branches (defaults to master)
- milestone_id referencing a milestone (or null if milestone not released yet)

Potential additional development

If we special-case feature stories, those shall only have "master" tasks since we don't backport features.
To view the list of stories/tasks shipped in a given release, we can have view targeting the cycle rather than each separate milestone.
Release tools to create and delete the temporary milestone-proposed branch (a few days before milestone cuts)
Release tools to pick up master-landed fixes (and milestone-proposed fixes) and set milestone for them on milestone cut weeks

@@ Line 2: / Line 2: @@
 * Bug coordinators and developers want to open backporting tasks (to milestone-proposed, to stable branches) as part of a bug story
 * Release management needs to track what made it to a given milestone and/or final release and point release
+== Design ==
+Tasks should have two additional properties:
+* '''branch''':  the branch the task is supposed to land in (for projects with a code repository attached to them). Defaults to ''master''.
+* '''milestone''': the first milestone or version where the fix landed.
+Branch is selected by the user as part of the task creation (defaults to ''master''). For autocreated tasks, it's set based on the change's target branch.
+Release is set as part of the release process: when a milestone-proposed branch is cut, we collect all master-landed fixes without a release set and mark them as released in the corresponding milestone. Then when the milestone is tagged, we collect all the milestone-proposed-landed fixes (if any) and mark them as released in the corresponding milestone as well.
 == Implementation ==
-Two fields shall be added to tasks:
+New tables:
-* '''Branch''' (defaults to ''master'', can select supported stable branches, can select ''milestone-proposed'' in the short periods that is opened): this tracks the branch where the fix shall be proposed and land
+* '''branches''': list of branches available (master, stable/havana...). Maps n:n to projects through a mapping table
-* '''Release''' ("icehouse-3'', ''2013.1''...): this tracks the first milestone or version where the fix landed.
+* '''cycles''': group of milestones (icehouse). Maps n:n to projects through a mapping table
+* '''milestones''': list of milestones available (icehouse-1, icehouse-2, icehouse-rc1...). Each belongs to a cycle
-Branch can be selected by the user as part of the task creation. For autocreated tasks, it's set based on the change's target branch.
+New fields:
+* '''tasks''' should have two new columns:
+** '''branch_id''' referencing a row from branches (defaults to ''master'')
+** '''milestone_id''' referencing a milestone (or null if milestone not released yet)
-Release could be set in two ways:
-* After the fact, as part of the release process: for example when the icehouse-3 milestone-proposed branch is cut, we collect all master-landed fixes without a release set and mark them icehouse-3. When icehouse-3 is published, we collect all the milestone-proposed-landed fixes (if any) and mark them icehouse-3 as well.
-* At change landing time, by determining the "next" milestone for a given branch (release management would then just adjust what the "next" milestone is for every branch).
-== Notes ==
+== Potential additional development ==
-* Feature stories shall only have "master" tasks since we don't backport features.
+* If we special-case feature stories, those shall only have "master" tasks since we don't backport features.
-* We'll need a milestone table for each project, and potentially the ability to group development milestones to form the final release (have a view that shows all dev milestones and RCs will result in showing what ended up in the final release).
+* To view the list of stories/tasks shipped in a given release, we can have view targeting the ''cycle'' rather than each separate milestone.
+* Release tools to create and delete the temporary ''milestone-proposed'' branch (a few days before milestone cuts)
+* Release tools to pick up master-landed fixes (and milestone-proposed fixes) and set ''milestone'' for them on milestone cut weeks