The new release process

[sjek]

pre set release date was tried once but it fell to new bugs popping up and new rc phase needed to made. so people got little frustrated that it had to be postponed and it went in the end kinda to way that it's done when it's done. RL kicking in and possibly always lazyness takes hold and there's kinda always that last minute crush xP

would suggest making separate threads for video, RC builds depending on maintainers and release thread or just pin the package posts to first page that they are easily found. the goal would be here to keep the overheat at minimal level

edit: haven't read that Cl builds, but i'm in the same line that clear naming helps a lot. and also to videos, atahualpa you can do as you like with developing those as you are the maker. one way if they are kept link-public for feedback reasons is to make it completely private while the release haven't been made and this time the time just went. open source and RL issues and it's part of the project so being little late isn't any bad for PR when done in organized way like in RL kinda

[raevol]

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

Absolutely! You may need to discuss with me privately which tasks you mean specifically, but I am all for it.

Regarding a set release date, I think that would be awesome, *unless* we missed it. We would basically have to finish the release process before we announced a release date, to make sure we hit it. And we'd really have to somehow keep people from assuming we were going to release 'sometime soon' when they read activity in public release threads, because if they read our release threads and then we set the release date weeks later, they're going to be confused.

I think the biggest thing we need to focus on, again, is a new CI build system as psi29a and I have been discussing. As I have stated, this would solve a ton of our problems.

[Zini]

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.

Makes sense. With keeping the video private you mean post the link in a forum section that is not visible to the public? I don't know of any other tool YouTube has to offer in this regard.

if there are no major problems with the RC builds, no last-minute changes, no video preparation issues

Lol! When did this ever happen? Optimist!

Regarding the fixed release that: If we finish up early, the release will just sit there and do nothing. That is a waste of time. If there are problems and we have to delay the release, this is going to make us look bad. My opinion is still the same: Fixed release dates don't work. They work poorly for propriety software and (with a few exceptions) they are a train wreck when it comes to open source.

The concerns you are listing are valid though and we should try to address them. It seems we are dealing mostly with communication issues. Communicating the state of the release exclusively through the forum is not the best approach. If we have the web development capacities, we could add the status on the website, big and in bright colours. Something like:

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: pre-release builds available for testing

or

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: Released, downloads available

If we absolutely want we could also add this:

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: In development

However then we would need multiple lines, because the development of the next version starts the moment the RC phase for the current version begins. That sounds a bit redundant to me.

[Zini]

Regarding a set release date, I think that would be awesome, *unless* we missed it. We would basically have to finish the release process before we announced a release date, to make sure we hit it. And we'd really have to somehow keep people from assuming we were going to release 'sometime soon' when they read activity in public release threads, because if they read our release threads and then we set the release date weeks later, they're going to be confused.

Exactly. The only way we could add a fixed release date would be to delay it to the point where all the work is finished and the release packages have already been build. Ideally at this point all the other work should be finished too and the release should be ready to go, which means we have a countdown of 0 days.

If the release team wishes to set a release date at this point, I won't oppose it. @Atahualpa: that may be partially what you meant?

That wouldn't be a fixed duration though. Basically you would have to ask everyone from the PR/release team how much time they need to finish up (assuming they did not finish up at this point already). This maximum value would then be used to set the release date.

@raevol If I haven't brought it up myself by then, could you poke me with a PM in two weeks or so?

[psi29a]

To be fair, we're not the only projects to have to deal with this.

Phoronix, for example, stole the thunder of TigerVNC's annoucment:
https://www.phoronix.com/forums/forum/l ... post896599

09-08-2016, 10:31 AM
Dammit Michael. You could at least let us finish the builds and do a proper announcement before you jump the gun.

These kinds of things happen all the time, someone sees the tag and bam, there is a new release!

This is why I had hoped that all the changelog/release announcement would be done during the RC phase so that when the release was finally tagged, we could publish an announcement.

[raevol]

@psi29a, I think we'll be able to do better with that in the future, in light of these discussions. This has been really helpful!

@raevol If I haven't brought it up myself by then, could you poke me with a PM in two weeks or so?

Will do! Also, this discussion has becoming a sprawling monster, could I bother you to chime in your thoughts on a CI infrastructure? I think psi29a and I... well, psi29a and me chipping in where I can, are thinking about going ahead with it.

[Atahualpa]

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.

Makes sense. With keeping the video private you mean post the link in a forum section that is not visible to the public? I don't know of any other tool YouTube has to offer in this regard.

Yep, I wanted to post them in the *not visible* forum section. Any YouTube functionality regarding video privacy is cumbersome (and sometimes unsafe from what I've heard).

if there are no major problems with the RC builds, no last-minute changes, no video preparation issues

Lol! When did this ever happen? Optimist!

You're the first one in a long time to call me optimist. I'd rather say that I work hard to meet closing dates -- which usually makes teamwork a breeze for my colleagues. But I agree that OpenMW isn't a standard project task force.

The concerns you are listing are valid though and we should try to address them. It seems we are dealing mostly with communication issues. Communicating the state of the release exclusively through the forum is not the best approach. If we have the web development capacities, we could add the status on the website, big and in bright colours. Something like:

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: pre-release builds available for testing

or

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: Released, downloads available

If we absolutely want we could also add this:

Status of OpenMW 0.41.0 and OpenMW-CS 0.41.0: In development

However then we would need multiple lines, because the development of the next version starts the moment the RC phase for the current version begins. That sounds a bit redundant to me.

Absolutely. I just got the feeling that you (plural) wanted a general overhaul.
The first two status messages sound good to me; we could use the last one if we omit the (correct) multiple-line approach and call everything between release announcement and pre-release builds "in development".

If the release team wishes to set a release date at this point, I won't oppose it. @Atahualpa: that may be partially what you meant?

That wouldn't be a fixed duration though. Basically you would have to ask everyone from the PR/release team how much time they need to finish up (assuming they did not finish up at this point already). This maximum value would then be used to set the release date.

That's basically what I meant. E.g., after I have released the first iteration of the release videos, I could estimate the time to finish the final version -- plus some extra time for reviewing and stuff -- depending on my current real life workload.

[Zini]

@psi29a, I think we'll be able to do better with that in the future, in light of these discussions. This has been really helpful!

@raevol If I haven't brought it up myself by then, could you poke me with a PM in two weeks or so?

Will do! Also, this discussion has becoming a sprawling monster, could I bother you to chime in your thoughts on a CI infrastructure? I think psi29a and I... well, psi29a and me chipping in where I can, are thinking about going ahead with it.

I haven't been following this discussion closely. Don't have anything else to contribute than a "Sounds good!".

[psi29a]

My 'task' here is to make sure that we have a testing PPA, a place to put RCs. If people want to test, they can use that which should give me feedback in time to fix broken packages, hopefully.

There might be (still unsure) a private PPA that will be used to store the final release until we are ready for press announcement.

Not to worry about Debian, we're still at 0.38... waiting for someone to upload our 0.40 release.

[raevol]

@psi29a what about the Travis-CI/Appveyor stuff? What steps do we need to take for that?