User:Mmaslano/Feature process

From FedoraProject

< User:Mmaslano(Difference between revisions)
Jump to: navigation, search
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
=Features, features and features=
+
=Changes, changes and changes=
  
 
* initial version: 2012-07-25 (mmaslano, mitr, t8m, jreznik)
 
* initial version: 2012-07-25 (mmaslano, mitr, t8m, jreznik)
Line 5: Line 5:
  
 
== Motivation ==
 
== Motivation ==
The aim of this proposal is to lower the barrier to propose Features, to avoid situation where unknown/not proposed changes appears later in the release cycle and leads to conflicts/slip and other issues. But also not to flood FESCo with overwhelming amount of Features and let them concentrate more on important complex Features with system wide impact. The community review is part of proposed process. The "Feature process" becomes internal planning tool and will be referred as "Planning process" (even it's difficult to split planning/marketing for truly open and community based project). Selected planning features will featured as marketing Features to create release announcements, talking points etc.  
+
The aim of this proposal is to lower the barrier to propose changes, to avoid situation where unknown/not proposed changes appears later in the release cycle and leads to conflicts/slip and other issues. But also not to flood FESCo with overwhelming amount of changes and let them concentrate more on important complex changes with system wide impact. The community review is part of proposed process. The "Change process" becomes internal planning tool and will be referred as "Planning process" (even it's difficult to split planning/marketing for truly open and community based project). Selected planning changes will changed as marketing features to create release announcements, talking points etc.  
  
== Categories of features ==
+
== Categories of changes ==
* "self contained" features
+
* "self contained" changes
* "complex features" with wide impact
+
* "complex changes" with wide impact
  
=== Self contained features ===
+
=== Self contained changes ===
The self contained feature could be one very isolated package or feature with limited scope, for example adding group of leaf packages or coordinated effort within SIG with limited impact outside SIG functional area. Enhancement of one package without impact on other package is also self contained feature.
+
The self contained change could be one very isolated package or change with limited scope, for example adding group of leaf packages or coordinated effort within SIG with limited impact outside SIG functional area. Enhancement of one package without impact on other package is also self contained change.
  
Public announcement of the new self contained feature will help to co-operate on the feature and extend proposed feature visibility. Feature owners can find help or useful comments. Those features don't have to be thoroughly reviewed by FESCo, which means more time for FESCo on the second category.
+
Public announcement of the new self contained change will help to co-operate on the change and extend proposed change visibility. Change owners can find help or useful comments. Those changes don't have to be thoroughly reviewed by FESCo, which means more time for FESCo on the second category.
  
 
'''Process'''
 
'''Process'''
* Formal correctness of filled feature template will be checked by Feature Wrangler and Feature will be announced on Fedora Devel Announce list.
+
* Formal correctness of filled change template will be checked by Change Wrangler and the change will be announced on Fedora Devel Announce list.
 
* No docs process (optional), only release notes advertisement.
 
* No docs process (optional), only release notes advertisement.
* Aggregated list of features will be added to FESCo agenda after a week (or more) on mailing list.
+
* Aggregated list of changes will be added to FESCo agenda after a week (or more) on mailing list.
** In case of no complaints (possible breakage/conflicts, coordination needed) on Fedora Devel mailing list/or from FESCo members, FESCo will approve those features without more investigation about the scope etc. Every team on Fedora devel can share their views and escalate feature to FESCo to go through the regular Feature process. Feature owner could be asked to provide more details/or move the feature to the "complex features" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.
+
** In case of no complaints (possible breakage/conflicts, coordination needed) on Fedora Devel mailing list/or from FESCo members, FESCo will approve those changes without more investigation about the scope etc. Every team on Fedora devel can share their views and escalate change to FESCo to go through the regular Change process. Change owner could be asked to provide more details/or move the change to the "complex changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.
  
 
'''Scheduling'''
 
'''Scheduling'''
* Self contained features follows the same schedule for the Feature Submission deadline as complex features (to reasonably bump them into the "complex" category).  
+
* Self contained changes follows the same schedule for the Change Submission deadline as complex changes (to reasonably bump them into the "complex" category).
  
=== Complex features with system-wide impact ===
+
=== Complex changes with system-wide impact ===
This features are system-wide/defaults changing features or critical path components. They can impact hundreds of packages (upgrade of gcc, glibc, change default from python2 -> python3, UsrMove, etc.). FESCo must have more time to review those features, help feature maintainer with defining the scope or help with contacting other impacted teams.  
+
This changes are system-wide/defaults changing changes or critical path components. They can impact hundreds of packages (upgrade of gcc, glibc, change default from python2 -> python3, UsrMove, etc.). FESCo must have more time to review those changes, help change maintainer with defining the scope or help with contacting other impacted teams.  
  
 
'''Process'''
 
'''Process'''
* Formal correctness of filled feature template will be checked by Feature Wrangler and Feature will be announced on Fedora Devel Announce list.
+
* Formal correctness of filled change template will be checked by Change Wrangler and the change will be announced on Fedora Devel Announce list.
* After a week on mailing list FESCo will discuss the feature on their meeting.
+
* After a week on mailing list FESCo will discuss the change on their meeting.
** Optionally, the feature could be assigned to one of FESCo members/or trusted community member within the functional area, who will follow detailed status of the feature with FESCo and help with process in Fedora (e.g. communicate about high-impact aspects, point out that a buildroot will be neccessary).  The shepherd will follow on status of the feature until release of Fedora. (We should be able to track the real status, better than with 80% which magically grow to 100% during Beta freeze.
+
** Optionally, the change could be assigned to one of FESCo members/or trusted community member within the functional area, who will follow detailed status of the change with FESCo and help with process in Fedora (e.g. communicate about high-impact aspects, point out that a buildroot will be neccessary).  The shepherd will follow on status of the change until release of Fedora. (We should be able to track the real status, better than with 80% which magically grow to 100% during Beta freeze.
** Fedora QA reviews announced Features on Devel Announce list to commit to testing of the Feature and/or adjust release criteria in case of need.
+
** Fedora QA reviews announced changes on Devel Announce list to commit to testing of the change and/or adjust release criteria in case of need.
* Status of complex features will be re-reviewed by FESCo one week before Beta Freeze.
+
* Status of complex changes will be re-reviewed by FESCo one week before Beta Freeze.  At this time FESCo will typically decide whether to activate the contingency plan.  Changes for which FESCo can't make this decision one week before beta need to note them on the respective Change wiki page.
  
 
'''Scheduling'''
 
'''Scheduling'''
* Feature Freeze as a hard deadline for complex features, to allow integration and possible mass rebuilds etc.
+
* Change Freeze as a hard deadline for complex changes, to allow integration and possible mass rebuilds etc.
  
 
=== What must be defined or added into current system: ===
 
=== What must be defined or added into current system: ===
Line 42: Line 42:
 
'''Define Scope sections more clearly:'''
 
'''Define Scope sections more clearly:'''
  
* release engineering impact - ticket to rel-engs, to understand impact of proposed feature
+
* release engineering impact - ticket to rel-engs, to understand impact of proposed change
* Needs a mass rebuild? (To be considered for scheduling, to schedule mass rebuilds for more features together etc.)
+
* Needs a mass rebuild? (To be considered for scheduling, to schedule mass rebuilds for more changes together etc.)
 
* List of specific actions for contingency plan (remember rewrite of anaconda!)
 
* List of specific actions for contingency plan (remember rewrite of anaconda!)
* Whether the feature is release blocking or not could be decided during review of the feature. Blocker could be anaconda, but not features which can use contingency plan.
+
* Whether the change is release blocking or not could be decided during review of the change. Blocker could be anaconda, but not changes which can use contingency plan.
  
'''New Feature Template:'''
+
'''New Change Template:'''
  
''All sections of this template are required for review by FESCo or only for Features to be approved by FESCo?''
+
''All sections of this template are required for review by FESCo or only for Changes to be approved by FESCo?''
  
 
Required fields: Summary, Owner, Current Status, Scope (list of dependencies), ...
 
Required fields: Summary, Owner, Current Status, Scope (list of dependencies), ...
  
* Who's actually responsible for work on broken things related to the new feature?
+
* Who's actually responsible for work on broken things related to the new change?
* Feature templates - must be all field filled even for self-contained features?
+
* Change templates - must be all field filled even for self-contained changes?
 
* Talk page should be used only for discussion about the proposed page before announcement - direct technical dicusssion to mailing lists
 
* Talk page should be used only for discussion about the proposed page before announcement - direct technical dicusssion to mailing lists
  
Line 63: Line 63:
  
 
=== Planning process ===
 
=== Planning process ===
The idea is to split internal planning and tracking process for feature and marketing process.
+
The idea is to split internal planning and tracking process for change and marketing process.
  
* "Feature process" is being renamed to "Planning process"
+
* "Change process" is being renamed to "Planning process"
* Marketing/docs teams to prepare list of "Features" communicated to users/press
+
* Marketing/docs teams to prepare list of "Changes" communicated to users/press
  
 
=== To do ===
 
=== To do ===
* We would like rawhide "merge windows": prepare your large feature in branches / side tags, and have a complete integration into rawhide finished in <= 1 week.  (Need to prepare howtos/guides.)
+
* We would like rawhide "merge windows": prepare your large change in branches / side tags, and have a complete integration into rawhide finished in <= 1 week.  (Need to prepare howtos/guides.)

Latest revision as of 18:46, 13 February 2013

Contents

[edit] Changes, changes and changes

  • initial version: 2012-07-25 (mmaslano, mitr, t8m, jreznik)
  • latest revision based on feedback from FUDCon Lawrence

[edit] Motivation

The aim of this proposal is to lower the barrier to propose changes, to avoid situation where unknown/not proposed changes appears later in the release cycle and leads to conflicts/slip and other issues. But also not to flood FESCo with overwhelming amount of changes and let them concentrate more on important complex changes with system wide impact. The community review is part of proposed process. The "Change process" becomes internal planning tool and will be referred as "Planning process" (even it's difficult to split planning/marketing for truly open and community based project). Selected planning changes will changed as marketing features to create release announcements, talking points etc.

[edit] Categories of changes

  • "self contained" changes
  • "complex changes" with wide impact

[edit] Self contained changes

The self contained change could be one very isolated package or change with limited scope, for example adding group of leaf packages or coordinated effort within SIG with limited impact outside SIG functional area. Enhancement of one package without impact on other package is also self contained change.

Public announcement of the new self contained change will help to co-operate on the change and extend proposed change visibility. Change owners can find help or useful comments. Those changes don't have to be thoroughly reviewed by FESCo, which means more time for FESCo on the second category.

Process

  • Formal correctness of filled change template will be checked by Change Wrangler and the change will be announced on Fedora Devel Announce list.
  • No docs process (optional), only release notes advertisement.
  • Aggregated list of changes will be added to FESCo agenda after a week (or more) on mailing list.
    • In case of no complaints (possible breakage/conflicts, coordination needed) on Fedora Devel mailing list/or from FESCo members, FESCo will approve those changes without more investigation about the scope etc. Every team on Fedora devel can share their views and escalate change to FESCo to go through the regular Change process. Change owner could be asked to provide more details/or move the change to the "complex changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.

Scheduling

  • Self contained changes follows the same schedule for the Change Submission deadline as complex changes (to reasonably bump them into the "complex" category).

[edit] Complex changes with system-wide impact

This changes are system-wide/defaults changing changes or critical path components. They can impact hundreds of packages (upgrade of gcc, glibc, change default from python2 -> python3, UsrMove, etc.). FESCo must have more time to review those changes, help change maintainer with defining the scope or help with contacting other impacted teams.

Process

  • Formal correctness of filled change template will be checked by Change Wrangler and the change will be announced on Fedora Devel Announce list.
  • After a week on mailing list FESCo will discuss the change on their meeting.
    • Optionally, the change could be assigned to one of FESCo members/or trusted community member within the functional area, who will follow detailed status of the change with FESCo and help with process in Fedora (e.g. communicate about high-impact aspects, point out that a buildroot will be neccessary). The shepherd will follow on status of the change until release of Fedora. (We should be able to track the real status, better than with 80% which magically grow to 100% during Beta freeze.
    • Fedora QA reviews announced changes on Devel Announce list to commit to testing of the change and/or adjust release criteria in case of need.
  • Status of complex changes will be re-reviewed by FESCo one week before Beta Freeze. At this time FESCo will typically decide whether to activate the contingency plan. Changes for which FESCo can't make this decision one week before beta need to note them on the respective Change wiki page.

Scheduling

  • Change Freeze as a hard deadline for complex changes, to allow integration and possible mass rebuilds etc.

[edit] What must be defined or added into current system:

Define Scope sections more clearly:

  • release engineering impact - ticket to rel-engs, to understand impact of proposed change
  • Needs a mass rebuild? (To be considered for scheduling, to schedule mass rebuilds for more changes together etc.)
  • List of specific actions for contingency plan (remember rewrite of anaconda!)
  • Whether the change is release blocking or not could be decided during review of the change. Blocker could be anaconda, but not changes which can use contingency plan.

New Change Template:

All sections of this template are required for review by FESCo or only for Changes to be approved by FESCo?

Required fields: Summary, Owner, Current Status, Scope (list of dependencies), ...

  • Who's actually responsible for work on broken things related to the new change?
  • Change templates - must be all field filled even for self-contained changes?
  • Talk page should be used only for discussion about the proposed page before announcement - direct technical dicusssion to mailing lists

F(n+1) planning process:

  • By the time Fn branches, open planning process for F(n+1)
    • to allow planning of large-scale changes earlier
    • has to be communicated on the branch day

[edit] Planning process

The idea is to split internal planning and tracking process for change and marketing process.

  • "Change process" is being renamed to "Planning process"
  • Marketing/docs teams to prepare list of "Changes" communicated to users/press

[edit] To do

  • We would like rawhide "merge windows": prepare your large change in branches / side tags, and have a complete integration into rawhide finished in <= 1 week. (Need to prepare howtos/guides.)