User:Mmaslano/Feature process

From FedoraProject

< User:Mmaslano(Difference between revisions)
Jump to: navigation, search
(self contained)
(wide feature)
Line 1: Line 1:
Features, features and features (2012-07-25)
+
=Features, features and features (2012-07-25)''=
 +
 
 
Attendees: mmaslano, mitr, t8m, jreznik
 
Attendees: mmaslano, mitr, t8m, jreznik
  
Line 19: Line 20:
  
  
=== SIG feature with wide impact ===
+
=== Real features with wide impact ===
This features are system-wide/defaults changing features. Announce Feature to fedora-devel one week before FESCo meeting review.
+
This features are system-wide/defaults changing features. 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.
 +
 
 +
It might be helpful to have for every feature one FESCo member (shepherd) who will offer his help to maintainer and will communicate status of the feature with rest of the FESCo. Problems like postponing the decision about feature should dissappear because someone will be in contact with maintainer.
 +
 
 +
'''Process'''
 +
* Announce the feature on fedora-devel.
 +
* After a week on mailing list FESCo will discuss the feature on their meeting.
 +
** Formal correctness of filled feature template will be checked by Feature Wrangler.
 +
** The feature will be assigned to one of FESCo members, who will help with process in Fedora (like where to ask for different koji buildroot, it can also point out that buildroot will be neccessary).
 +
** The feature can be accepted, but FESCo member 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. Also using green, yellow, red instead of % will be improvement.
 +
*** The accepted feature will be switched to new state and will be waiting for re-review in case of problem or Beta freeze when is status of features reviewed.
 +
 
 +
 
 +
'''What must be defined or added into current system:'''
  
* Who's actually is going to do the work?
+
Define Scope sections more clearly:
  
Define Scope section more clearly
 
 
* release engineering impact (mass rebuilds etc.)
 
* release engineering impact (mass rebuilds etc.)
 
* mass rebuild deadline
 
* mass rebuild deadline
 +
* backup solution (remember rewrite of anaconda!)
  
Feature Template
+
New Feature Template:
All sections of this template are required for review by FESCo. - only for Features to be approved by FESCo
+
  
Required: Summary, Owner, Current Status, ... TODO
+
All sections of this template are required for review by FESCo or only for Features to be approved by FESCo?
  
Feature on track?
+
Required fields: Summary, Owner, Current Status, Scope (list of dependencies), ...
  
When to close FESCo ticket?
+
* Who's actually responsible for work on broken things related to the new feature?
- Approved
+
* feature templates - must be all field filled even for self-contained features?
- Finished - so owner can track the development (Feature Sheppard)
+
* add into trac more statuses for tracking features

Revision as of 11:45, 9 November 2012

Contents

Features, features and features (2012-07-25)

Attendees: mmaslano, mitr, t8m, jreznik

Categories of features

  • "self contained" features
  • "real features" with wide impact

Self contained features

The self contained feature could be one very isolated package or feature with limited scope for example adding group of leave packages. Enhancement of one package without impact on other package is also self contained feature.

Public announcement of the new self contained feature will help to co-operate on the feature. Feature owners can find help or usefull comments. Those features don't have to be thoroughly reviewed by FESCo, which means more time for FESCo on the second category.

Process

  • Announce the feature on fedora-devel.
  • No docs process, only release notes advertisement.
  • Aggregated list of features will be added to FESCo agenda after a week (or more) on mailing list.
    • Formal correctness of filled feature template will be checked by Feature Wrangler.
    • If no-one was complaining about possible breakage on fedora-devel maililing list, then FESCo will ack those features without more investigation about scope etc. Every team on fedora-devel can share their view of possible problems of those features.


Real features with wide impact

This features are system-wide/defaults changing features. 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.

It might be helpful to have for every feature one FESCo member (shepherd) who will offer his help to maintainer and will communicate status of the feature with rest of the FESCo. Problems like postponing the decision about feature should dissappear because someone will be in contact with maintainer.

Process

  • Announce the feature on fedora-devel.
  • After a week on mailing list FESCo will discuss the feature on their meeting.
    • Formal correctness of filled feature template will be checked by Feature Wrangler.
    • The feature will be assigned to one of FESCo members, who will help with process in Fedora (like where to ask for different koji buildroot, it can also point out that buildroot will be neccessary).
    • The feature can be accepted, but FESCo member 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. Also using green, yellow, red instead of % will be improvement.
      • The accepted feature will be switched to new state and will be waiting for re-review in case of problem or Beta freeze when is status of features reviewed.


What must be defined or added into current system:

Define Scope sections more clearly:

  • release engineering impact (mass rebuilds etc.)
  • mass rebuild deadline
  • backup solution (remember rewrite of anaconda!)

New Feature Template:

All sections of this template are required for review by FESCo or only for Features 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 feature?
  • feature templates - must be all field filled even for self-contained features?
  • add into trac more statuses for tracking features