Page MenuHomePhabricator

Create release plan
Open, Showstopper IssuesPublic

Description

We need to create a sustainable process for development cycles and release shipping. @stefan_schmidt has done a tremendous job over the years, but it's too big a task for one person and we should not be forcing any single individual to manage all the responsibility.

Anyone interested in helping out with releases should join the efl: release team project so they can receive notifications for release-related tasks.

This ticket is for discussing proposals for release cycles going forward.

zmike created this task.Jul 19 2018, 2:25 PM
zmike triaged this task as Showstopper Issues priority.

Adjusted version of the proposal that I sent to the mailing list:

  1. starting in the last 3 weeks of the previous development cycle, for 2 weeks tickets with TODO priority are created (or re-tagged) with the 1.22 milestone tag and the "major changes" tag for "major" features [weeks 10-11 of previous cycle]
    • continue to fix bugs for release
  2. after this period, a 1 week multi-vote is created on phabricator, and core developers vote to defer any TODO ticket for a release past 1.22 [week 12 of previous cycle]
    • this will promote discussion about work items, and allow review of anything which might be too radical to accomplish within 3 months
  3. any TODO item which receives 5 or more votes from committers is deferred*
    • this means the work may not be merged into master during this release cycle
  4. development progresses for 4 weeks [weeks 1-4]
  5. 2x 1 week multi-votes are created: [week 5]
    • feature development halts for 1 week, bug tickets on the "urgent" workboard are handled as time allows
  6. a vote to review existing "accepted" TODO items
    • it may be the case that unforeseen difficulties arise in development, so this creates a process by which a work item can be officially deferred
  7. a vote to review other TODO items which are not yet accepted
    • if some items are deferred then there may be extra time available, or perhaps a proposal for implementing a feature has been reworked to make it fit into the release better
  8. development progresses for 4 weeks [weeks 6-9]
  9. feature freeze begins [week 10]
    • any "major" feature patches submitted before the freeze begins can still be reviewed and landed
    • any "major" feature patches submitted after the freeze are unconditionally deferred until the next release
    • any "small" feature patches can be landed (with 3+ reviews and no rejects after being on phab for 48+ hours)
    • alpha release at end of week 10
  10. bug fixing [week 11]
    • no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug
    • beta release at end of week 11
  11. bug fixing [week 12]
    • no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug
  12. release evaluation [end of week 12]
    • if release can be executed, release ships
    • otherwise, perform pre-release and repeat steps 9-10 until release ships
zmike added a comment.Aug 21 2018, 2:39 PM

After some discussion on IRC, it seems some people have issues related to the voting process. An idea to improve this could be something like:

  • Every 2 weeks on Friday, starting the week that a development cycle begins, all work proposal which have not been rejected (based on comments in the proposal tickets) are moved by efl: release team to Active Work Proposal
  • This continues until week 9; week 9 is also an "approval" week since it's the last week before the freeze begins

The benefit of this would be that there is more opportunity to add items into the release as people determine what is needed, and it reduces overt conflict since people don't have to vote. It also reduces the need for people to have to read/follow directions.

I also don't think the vote are necessary unless we get to a point where we can't come to a clear consensus while discussing an issue, at that point we can just open a yes/no vote on that one item, I think that would also be less confusing.

I also put a bit of a different proposal on the mailing list.

I agree with @simotek. If someone has a problem with a proposel, he can just commicate via the ticket and sort things out, sounds also a bit more structured than the vote.

indefini added a comment.EditedAug 22 2018, 12:44 AM

I may I have missed something since then but there had been irc meetings that decided some things and left some other for discussion.
https://phab.enlightenment.org/T6740
I think it was said that voting was only when there was no consensus.
Now I think it is okay to change things but the most efficient way to do it would be to do another irc meeting.
First take the report of the last irc meeting and rise points that you want to be discussed in the meeting.