This is just a draft version put together to capture the feedback provided during the meeting and present my point of view based on my experience in other open source projects
Current state
- Patches are submitted via gerrit
- Architecture is described on a wiki and (sometimes) later migrated to read the docs
- We have a waterfall-ish development model with clearly distinguish planning, designing, implementation and testing phases
- There is a lot of paper work to be done at every milestone
- Features for every release are described globally (per release) and approved by TSC in the beginning of each release
- We have 2-3 releases per year
Proposal
Development
- Keep 3 releases in a year:
- W8
- W24
- W43
- Divide the release in 3 sections:
- R - 16 Release kickoff
- Start estimating which global requirements can be met in this release (security metrics, python upgrade, infra etc)
- Start socializing global requirements with PTLs so that every one knows what should be done
- Ideas for global requirements should be provided before the kickoff, this time slot is only for choosing ideas for this release
- R - 14 Global requirements defined
- TSC approves a list of global requirements that has to be address by the teams in this release
- R - 10 Spec freeze
- All features that are going to be implemented in this release should be approved
- R - 5 Feature freeze
- End of accepting patches containing new features for this release
- Start of bugfixing period
- Release branch is being created for all participating projects
- R - 3 Beginning of RC-phase
- RC every end of week
- Bug fixes submitted for both master and release branch
- Feature development may continue for approved specs in the master branch
- R - 0 - final testing, release notes and Sign-off
- R - 16 Release kickoff
- Assumptions:
- Architecture (spec) work is being done continuously
- Every spec has below stages in its life cycle:
- Proposed
- The spec has been proposed by the author for a review by affected parties
- Approved
- The spec has been reviewed by interested parties and approved
- In this point we agree that the design is good and if we find the resources it can be implemented
- Scoped for the release
- There is a volunteer to work on this particular spec within this release
- The work may be continued in next release with PTL and TSC consent.
- Implemented
- The spec has been fully implemented and should be mentioned in the release notes
- Dropped
- The spec has been dropped because no one is willing to work on it or it became out of the date
- Proposed
Calendar
- EDIT THE CALENDAR
Customise the different types of events you'd like to manage in this calendar.
#legIndex/#totalLegs - RESTRICT THE CALENDAR
Optionally, restrict who can view or add events to the team calendar.
#legIndex/#totalLegs - SHARE WITH YOUR TEAM
Grab the calendar's URL and email it to your team, or paste it on a page to embed the calendar.
#legIndex/#totalLegs - ADD AN EVENT
The calendar is ready to go! Click any day on the calendar to add an event or use the Add event button.
#legIndex/#totalLegs - SUBSCRIBE
Subscribe to calendars using your favourite calendar client.
#legIndex/#totalLegs