User:Mmaslano/Feature process

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

Attendees: mmaslano, mitr, t8m, jreznik

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.

Categories of features

• "self contained" features
• "complex 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 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.

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.

Process

• Formal correctness of filled feature template will be checked by Feature Wrangler and Feature will be announced on Fedora devel list.
• 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.
  • In case of no complaints (possible breakage/conflicts, coordination needed) on Fedora devel mailing list, 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.

Scheduling

• Self contained features can be submitted and announced even after Feature Freeze deadline but no later than one week before Feature 100% Complete deadline. In case of objections during the week after announcement the (late-submitted) feature will be postponed to the next release, and will be treated as any other feature proposed for the next release.

Complex features 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.

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 disappear because someone will be in contact with maintainer.

Process

• Formal correctness of filled feature template will be checked by Feature Wrangler and Feature will be announced on Fedora devel list.
• After a week on mailing list FESCo will discuss the feature on their meeting.
  • The feature will be assigned to one of FESCo members, who will help with process in Fedora (technical help 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.
  • Fedora QA is noticed (or explicit approval should be required?) to commit to testing of the Feature and/or adjust release criteria.

Scheduling

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

What must be defined or added into current system:

Define Scope sections more clearly:

• release engineering impact (mass rebuilds etc.) - ticket to rel-engs, to understand impact of proposed feature, to schedule mass rebuilds for more features together etc.
• mass rebuild deadline
• backup solution 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.

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 or track the whole process in Fedora Program Management trac not to pollute FESCo trac and allow different teams to access it (for rel-eng, QA acks etc).