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
Posts: 689
Joined: 22 Feb 2016, 20:32

Re: The new release process

Post by Capostrophic » 10 Sep 2016, 11:34

Please, give us feedback.

Posts: 99
Joined: 18 Apr 2016, 15:45

Re: The new release process

Post by darkbasic » 10 Sep 2016, 12:09

Zini wrote:* We don't tag for RCs. That would require to replace the tag later
Atahualpa wrote: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.
Packages creation and testing has been one of the phases who took more time and leaded to the greater miscommunications.
- Creating final packages before the final tag makes no sense, because it will mislead people.
- Creating RC packages when the final tag has already been issued makes even less sense, because the tag will deceipt everyone.
- Creating RC packages without any kind of tag (nor final nor rc) makes also no sense IMHO.

So, why shouldn't we tag RCs? It will make things easier to understand, avoiding any kind of miscommunications.
There is no need to replace the tag later, just issue a new tag which points to the very same commit if no more changes are required. There are plenty of projects who release finals which point to the very same tag of latest RC if they encountered no problems. On the contrary I already filed a bug in the past which prevented OpenMW to compile in my distro's build environment, so packaging bugs which require a new commit to be issued are possible.

User avatar
Posts: 1152
Joined: 29 Jun 2015, 09:08

Re: The new release process

Post by DestinedToDie » 10 Sep 2016, 12:29

The proposal of a time limit (14 days) is a really bad idea because nobody wants to feel like they are obligated to hurry up and finish.

Posts: 401
Joined: 21 Dec 2013, 22:18

Re: The new release process

Post by SquireNed » 10 Sep 2016, 17:18

DestinedToDie wrote:The proposal of a time limit (14 days) is a really bad idea because nobody wants to feel like they are obligated to hurry up and finish.
But everyone decides when that 14 day process finishes. It's more of a "I'm done, guys, are you done?" process followed by a two-week final period of kicking the tires and making sure everything's working.

User avatar
Posts: 334
Joined: 02 Jan 2016, 02:51

Re: The new release process

Post by Ravenwing » 10 Sep 2016, 17:45

Atahualpa wrote: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.
I can't comment on most of the process since I'm not a developer or part of the release team, but I think having an overall status bar instead of a release timer/countdown might help clarify things for most casual users. It would still convey at a glance what the status of the release is, but without the pressure on the release team as an actual timer. I'm imagining something like a UPS tracking bar where it kind of graphically shows whether the package has been shipped, it's current location, when it's out for delivery, and then delivered. It should be pretty easy to set up even if all you wanted to do was some simple HTML and CSS.

Posts: 54
Joined: 29 Jan 2016, 09:44

Re: The new release process

Post by weedfreak » 11 Sep 2016, 08:51

The current method has worked OK for 40 releases with an occasional glitch. Why change something that is not broken?

The only thing wrong with the last release was apparently someone reposted the videos and the 'official' release got a bit delayed, I was using 40 from arch repository a week before the "official' release, I expect many others were also. As Barnum said "All publicity id good publicity, unless it is an obituary"

In any case most linux repositories will update to a new version as soon as the release is tagged, they are not interested in release announcements or video's, and incidentally neither am I.

User avatar
Posts: 3041
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: The new release process

Post by raevol » 11 Sep 2016, 09:05


Posts: 23
Joined: 27 May 2013, 17:03

Re: The new release process

Post by Rumina » 11 Sep 2016, 10:30

weedfreak wrote:In any case most linux repositories will update to a new version as soon as the release is tagged, they are not interested in release announcements or video's, and incidentally neither am I.
Perhaps not. But there are many users that are. A proper release generates buzz in the community and attention. That attention in turn attracts more testers and potential contributors to the project. The importance of these releases catching the gaming community's attention as much as possible cannot be overstated.

That said, my thoughts on the topic are this. There's no reason to do a complete overhaul to the workflow between 2 releases. But I do think it's important that the release videos don't go public until the "official launch" of said version. Perhaps the best way to handle this would be a private sub-forum for related personnel. As a non-developer I'll be disappointed to miss out on the sneak peek of the video release each version, but I believe it's what is best for the community.

From the sound of things you'll never get everyone to agree with some major changes. Excessive discussion with no agreed upon course of action may do more harm than good. So why not just start small with keeping the release video process private. If there's more room for release flow improvements by 0.42 then maybe make more fine adjustments until things feel right.

If any minor patch notes are missing before video production is done that should have been in the video, perhaps they could appear in the video description or in annotations at the end.

User avatar
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: The new release process

Post by Zini » 11 Sep 2016, 12:19

I don't think the release process needs to have more structure. Please note that this is not criticism of raevol's work. I am generally very happy with how things are going. However things could be improved by making the handover from developer to release team and release manager strong than in the current procedure.
Right now raevol and I are still splitting the tasks up between us, e.g. requesting new RC builds, checking on how much testing is done, keeping track of reported bugs, tagging the release and finally starting the release process.
I think having as much as possible of this in one hand (that of the release manager) would make the process a lot smoother (with advice from me and other developers of course). But that would mean a bit more work and responsibility for the release manager.

@raevol: Would you be interested in taking over some or all of these tasks?

User avatar
Posts: 1045
Joined: 09 Feb 2016, 20:03

Re: The new release process

Post by Atahualpa » 11 Sep 2016, 14:49

Okay, from what I get, we have to main changes that we agree on:
  • The Project Lead (Zini) and the Release Manager (reavol) have to rearrange their responsibilities.
  • The release videos have to be kept private until the release has been announced?
Agreed? If so, I won't make a stand against your opinion to leave everything else as is.

I have to insist on one thing though: some sort of release date.

My proposal was -- if there are no major problems with the RC builds, no last-minute changes, no video preparation issues -- to set a release date and make it visibile to everybody, e.g., a timer at the top of our homepage. It could be set when the whole release process starts ("The release of v0.41.0 is being prepared. Please stay tuned.") and, then, be set to "The release of v0.41.0 is scheduled to December 24th 2016". Something like this.
Before you reject this, let me summarise the benefits:
  • Everyone knows that we are not released yet. -> No overhasty release rumors.
  • Everyone knows when the exact release will be. -> The release will have more impact instead of abate in the course of tine.
  • The team members know when everything needs to be ready for the release, while having most things working before (except for the changelog and the release videos). -> No internal confusion about the actual release; better timing for video production.
We can adjust my proposal to meet your taste -- it's just my POV.

Post Reply