The new release process

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

The new release process

Post by Atahualpa »

Edit: Consider the following suggestions insignificant for the time being. I leave them as a reference in case of future discussions regarding the release process.

Hello everyone,

our discussion about the new release process has become somewhat... confusing. That's why I decided to start a new thread to clear things up a bit. The opening post will contain the results of our discussion.

In my opinion this should include...
  • our current team members and their tasks.
  • a breakdown of our release process into stages incl. appropriate time frames.
  • the actual release process with all its actions and dependencies.
Current status (see second post):
--------------------------------------------------
--------------------------------------------------
------------- My first diagramm --------------
--------------------------------------------------
--------------------------------------------------


Best regards,

Atahualpa



Update: I hope this makes things a bit more clear.
Atahualpa wrote:Let me elaborate on this. There are five phases per release cycle:

1. Development Phase
The longest and (development-wise) most productive phase; lots of bugs get fixed, some features get implemented. Our release builders do their nightly builds and everyone is free to test them. They have to find them on their own though.

2. Pre-Release Phase
This is just an intermediate stage of the release process to make everyone aware of the upcoming release, inform the release manager, our packagers and testers, and let the video producer know that he can start to sketch out the release videos. Its main purpose is to allow everyone to adjust their time schedules, so nobody gets caught off guard. Ideally, we are feature-complete for the release by then.

3. Release Phase I
After that, the release tag is created which marks the beginning of the actual release process. The packagers build their RCs and link them to the release thread, testers start to look for problems with the installers -- but also for game-breaking bugs and stuff. The roadmap gets cleared of unsolved issues, the video production starts.

4. Release Phase II
This is the last signal for the release process. The release date is set to exactly 14 days after the appropriate announcement of this phase. This way, people know when the release is to be expected, and the release team knows when their work has to be done. We could as well create a timer/countdown at our homepage.
This is not meant to put any pressure on certain members -- and, in case of emergency, we can delay the release -- but it should greatly improve our communication. Of course, we only enter this phase if their are no major problems with the builds.
The packagers switch their terminology to "Release Build" (or something like that), the changelog is set up, the video review process starts, and final adjustments are made, if necessary.

5. Post-Release Phase
After the release, we need some time to clear everything up: The Outreach needs to be updated, many questions as well as feedback from the community are to be expected, the Wiki needs to be updated -- and, above all, we have to agree on the new roadmap, i.e. we have to (internally?) discuss the goals for the next version and set up the new (internal) release thread and schedule.
Once we have finished this "cool-down" phase, the (public) release thread for the next version is created.


Essentially, the division into several release phases is mostly a matter of communication and scheduling.
Last edited by Atahualpa on 12 Sep 2016, 21:52, edited 3 times in total.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

Re: The new release process

Post by Atahualpa »

So, here's my first, most likely incomplete, attempt on a release process:

To begin with, I created an overview which includes all general tasks I could think of. Then, I added people dealing with these tasks and gave them a status (leader, vice/important, common). I combined the resulting structure with a first (maybe too superficial) iteration of a possible release process, introduced 5 different release phases, added necessary prerequisites and actions, and structured the whole thing.

See https://drive.google.com/open?id=0B_Hlr ... XpGelJDRTg for the result.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: The new release process

Post by raevol »

I documented my participation in the release process here a while ago: https://wiki.openmw.org/index.php?title=Release_Process

I made this to make sure I didn't leave any steps out when I am doing a release. I'm not sure if/how it fits with your diagram, but figured I would post it.

At this point in our planning, I think the biggest question is if we can get this CI infrastructure set up that AnyOldName3/psi29a/myself are discussing. If we can, it's going to wildly change how we handle RCs and testing.
User avatar
Ravenwing
Posts: 335
Joined: 02 Jan 2016, 02:51

Re: The new release process

Post by Ravenwing »

Thanks for this, it was actually very clarifying as to how the process works for those of us who don't know the inner workings very well. I'm excited to see how the new process plays out. It's also probably worth it to spend the extra effort now to get things up and running so by the time we get to 1.0 and our visibility increases you all don't have to deal with such a headache.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

Re: The new release process

Post by Atahualpa »

raevol wrote:I documented my participation in the release process here a while ago: https://wiki.openmw.org/index.php?title=Release_Process
Damn, I completely forgot about this page! :D
In the end, I planned to create something similar (but more extensive), maybe a graphic representation in order to increase intelligibility.
raevol wrote:I made this to make sure I didn't leave any steps out when I am doing a release. I'm not sure if/how it fits with your diagram, but figured I would post it.
We'll see. I will go through the Wiki page and check for inconsistencies.
raevol wrote:At this point in our planning, I think the biggest question is if we can get this CI infrastructure set up that AnyOldName3/psi29a/myself are discussing. If we can, it's going to wildly change how we handle RCs and testing.
Well, time to thoroughly read through the release process thread again.
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: The new release process

Post by psi29a »

This the CI thing will take some time to get into motion, even for testing. ;)
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: The new release process

Post by Zini »

It seems that you have split up the RC phase in 3 sub-phases. I do not see what the benefit of that would be.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

Re: The new release process

Post by Atahualpa »

Let me elaborate on this. There are five phases per release cycle:

1. Development Phase
The longest and (development-wise) most productive phase; lots of bugs get fixed, some features get implemented. Our release builders do their nightly builds and everyone is free to test them. They have to find them on their own though.

2. Pre-Release Phase
This is just an intermediate stage of the release process to make everyone aware of the upcoming release, inform the release manager, our packagers and testers, and let the video producer know that he can start to sketch out the release videos. Its main purpose is to allow everyone to adjust their time schedules, so nobody gets caught off guard. Ideally, we are feature-complete for the release by then.

3. Release Phase I
After that, the release tag is created which marks the beginning of the actual release process. The packagers build their RCs and link them to the release thread, testers start to look for problems with the installers -- but also for game-breaking bugs and stuff. The roadmap gets cleared of unsolved issues, the video production starts.

4. Release Phase II
This is the last signal for the release process. The release date is set to exactly 14 days after the appropriate announcement of this phase. This way, people know when the release is to be expected, and the release team knows when their work has to be done. We could as well create a timer/countdown at our homepage.
This is not meant to put any pressure on certain members -- and, in case of emergency, we can delay the release -- but it should greatly improve our communication. Of course, we only enter this phase if their are no major problems with the builds.
The packagers switch their terminology to "Release Build" (or something like that), the changelog is set up, the video review process starts, and final adjustments are made, if necessary.

5. Post-Release Phase
After the release, we need some time to clear everything up: The Outreach needs to be updated, many questions as well as feedback from the community are to be expected, the Wiki needs to be updated -- and, above all, we have to agree on the new roadmap, i.e. we have to (internally?) discuss the goals for the next version and set up the new (internal) release thread and schedule.
Once we have finished this "cool-down" phase, the (public) release thread for the next version is created.


Essentially, the division into several release phases is mostly a matter of communication and scheduling.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: The new release process

Post by Zini »

Sorry, not liking it. These are the problems I see:

* We don't tag for RCs. That would require to replace the tag later
* Fixed time-scales are problematic; in itself and especially for a volunteer project. It's done when it's done is really the only realistic approach in my opinion.
* Too much formal procedure. IMO we should keep that stuff to a workable minimum. This is an open source project, not a cooperate clown show. Also, too much sequential steps where in reality more things happen in parallel.

We really only need 2 steps for the release procedure:
1. The RC phase:
* I call for the start of the RC phase (which I announce about a week ahead, which gives everyone a chance to get smaller unfinished bits and pieces in before the release) and I create the release branch. The code is not necessarily feature complete at the time of the announcement, but it must be feature complete at the start of the RC phase.
* Ideally at this point the release manager should take over managing the release (with input from me and other developers), i.e. keeping track of progress and poking people into action as needed
* I try to get the changelog ready at this point (this includes cleaning out the roadmap), but delays of a couple of days are always a possibility.
* RC packages get build and tested and we release new RC packages as needed.
* During the RC phase PR stuff is prepared and reviewed (primarily the videos, but also the release announcement and others as needed)
2. The release:
* Once there are no more critical bugs, I place the tag, the release packages are build (or renamed) and the release begins.
* I flag the release milestone on the tracker as closed.
* At the same time the PR stuff happens (publishing the videos, posting release announcements).

Sorry, again for shooting down your proposal but I do not see any benefit from any structure beyond this.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

Re: The new release process

Post by Atahualpa »

Zini wrote: * We don't tag for RCs. That would require to replace the tag later
I got that wrong then. Call it want you want, I just meant that you call out the begin of the actual release process.
Zini wrote: * Fixed time-scales are problematic; in itself and especially for a volunteer project. It's done when it's done is really the only realistic approach in my opinion.
The 14 days are the only fixed time-scale in my approach. In my opinion they are necessary to prevent such severe miscommunication as we had with the last release. We only set this date if we are sure to be able to hold it.
Zini wrote: * Too much formal procedure. IMO we should keep that stuff to a workable minimum. This is an open source project, not a cooperate clown show. Also, too much sequential steps where in reality more things happen in parallel.
It is not much more work than what you have suggested in your post. It requires only four forum posts from your side (initial post, pre-release post, release process start post, release date post) and some awareness of every member (knowing which phase we are in). These transitions are the only sequential steps I can see, the rest is, of course, happening in parallel.
Zini wrote: We really only need 2 steps for the release procedure:
[...]
Your following release procedure is very similar to what I proposed -- your structure is different though. Maybe, some other team members would like to comment on this? (I must admit that my knowledge of the inner release mechanics is quite limited.)
Zini wrote: Sorry, again for shooting down your proposal but I do not see any benefit from any structure beyond this.
Well, I recently got the impression that our release process needed a bit more structure. E.g., the release videos for v0.40.0 had been finished four weeks before the actual release took place. Meanwhile, more issues were added "last-minute", the RC builds for certain builds lacked proper testing (or feedback about testing), and -- above all -- people started to think that we had been released. If you personally refuse to put in more work in order to clear things up, then let others take care of it (I, for example, am willing to keep our schedule up to date). But you have to look at it from others' points of view: The uninvolved players, the packagers, the release manager, the PR people...
@all: Please, give us feedback.
Post Reply