Release process changes

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
raevol
Posts: 2362
Joined: 07 Aug 2011, 01:12
Location: Caldera

Release process changes

Post by raevol » 04 Sep 2016, 02:08

I'd like to propose some changes to our release process. I'd like to propose that we take one of two approaches to our releases, to modify how we are doing our releases.

Option 1: more like a open source project than a game project

In this option, we would function more like a traditional open source project. Under this model, I propose that the "main project" itself does not distribute any release packages. We would make a tag and release on github, but not distribute any binaries. All release package distribution would be the responsibility of release maintainers.

Now, we could still host binaries in downloads.openmw.org for people, but compiling them, testing them, and distributing them would be the responsibility of the packager. This way, if there's something wrong with the release package that does *not* stem from our code, we don't have to roll back or hold up our release. We just direct users to the packager, and keep working.

The advantage of this is is our releases are less work and go smoother. The disadvantage of this is users will be confused.

Option 2: more like a game project than an open source project

In this option, we function more like a proprietary game company. We'll still be an open source project of course, our code will all stay completely open, but our releases will not be public until they are made public. Release videos, release packages, the release announcement, etc, will stay on a private board on these forums accessible only by core team members and release packagers. Packages will be vetted by a private team of testers before release, and no packages will be released without testing.

This approach will require involvement and investment by team members. This will require more work and coordination. The advantage though, is we don't have these fumbling awkward miscommunication releases like we do now. Someone, either the project lead or release manager, will need to have final say on everything in this process, and they will need to stick to their guns to ensure stuff doesn't get released before it is deemed ready.

---

I prefer option 1, but I understand that it would be awkward for people coming from the traditional game community. I'd love to hear input on this. We can, of course, keep things how they are, but I am pretty dissatisfied with how the past few releases have been handled. There's absolutely no finger pointing here, if this is anyone's fault it's mine. But I think we can do better and I would like to do better.

Thanks for reading!

User avatar
Atahualpa
Posts: 732
Joined: 09 Feb 2016, 20:03

Re: Release process changes

Post by Atahualpa » 04 Sep 2016, 08:37

I'd prefer option 2 because it seems to give us more control about the release process (including the release packages). E.g., it would be really bad PR, if there were severe problems with a certain package and we might not even know about this. In the end, people would come to our forums to complain. -- And when do we tell them about the new release on our homepage?

Moreover, I like the concept of a (more or less) synchronous release for all OS. -- Imagine a situation in which linux and MAC packages have been released but Windows packages need to be redone because of an error. Meanwhile, the release videos are published and, suddenly, every Windows user not actively reading our forums will go nuts.

I understand that the second option is more time-consuming. Do you need help with this, raevol? I could, e.g., write the changelog because I need to go through each and every issue when creating the videos anyway. I don't know what other tasks can be distributed among members, so maybe you could give us (me) an overview?

User avatar
psi29a
Posts: 3371
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Release process changes

Post by psi29a » 04 Sep 2016, 08:52

You haven't actually stated what you dislike about our current release cycle. I'm generally OK with how things are done now. There can be some improvements:

During RC phase, is also when the release documentation also begins, thus decreasing the lag time between tagging a release and an official release.

I don't understand why the videos were finished up long before the change-log/documentation were finished, this sounds backwards to me.

Remember, when Zini tags a release... it's a release. Option #2 is impossible in open-source because when Zini tags, that's that. Downstream (arch,ubuntu,debian,fedora,freebsd... etc.) are not going to wait for an 'official announcement'.


Just keep in mind that people only work on this when they have time, we can't expect everyone to be fast on turnaround time for a volunteer project. People are just going to have to deal with that. We're not a commercial venture, we don't pretend to be and if users don't like that, tough shit. We're not here for the money, we're allowed to push back against the expectations.

User avatar
Atahualpa
Posts: 732
Joined: 09 Feb 2016, 20:03

Re: Release process changes

Post by Atahualpa » 04 Sep 2016, 09:21

psi29a wrote:I don't understand why the videos were finished up long before the change-log/documentation were finished, this sounds backwards to me.
The videos were finished a long time before the "final" changelog because making them normally requires more than a week of, not full-time but concentrated, work -- plus time for the first review, the updated version, and the final review. Last-minute changes to the videos' contents are awkward because I have a certain narrative structure. Also, delaying the videos until the final changelog is ready would further delay the release itself. Look at the changes which popped in this time. Over weeks.

That said, I don't mind starting work on the videos a bit later. This time it was forced due to my holidays. Nobody could foresee that the release wasn't finished when I came back over two weeks later.

User avatar
Okulo
Posts: 634
Joined: 05 Feb 2012, 16:11

Re: Release process changes

Post by Okulo » 04 Sep 2016, 09:53

As much as I am a fan of transparency, there is the problem of people coming here, jacking the links for the videos and posting it everywhere. It's a problem since people will think a release is already done when it isn't. They'll search around a bit and give up. That's not a good way for OpenMW to go about doing things.

So... have the video come out later, once everything is uploaded and raevol has posted his changelog? I don't think that works either. The video is a major communicator towards the community so we need to be able to give feedback.

It's not that the current release schedule is necessarily bad or anything, but I do think something needs to change for the sake of impact. It could be as simple as a phpBB plugin that hides links from everyone except a select bunch of users, of course.

I'm probably one of the least qualified people (or relevant for that matter) to talk about this here as I'm not even part of the devteam (I just troll some Morrowind forums from time to time, copypaste changelogs and mail some journalists), but raevol made two suggestions that I'd still like to make a few comments about.
raevol wrote:Now, we could still host binaries in downloads.openmw.org for people, but compiling them, testing them, and distributing them would be the responsibility of the packager. This way, if there's something wrong with the release package that does *not* stem from our code, we don't have to roll back or hold up our release. We just direct users to the packager, and keep working.
I'm not quite sure if there is a lot of difference between this suggestion and what is already done. Zini will put a feature stop on the current version, but developers don't sit on their hands, right? Aren't they already continuing with the next version as is? And if the people compiling for OSX, Linux and Windows fail somewhere, they already talk to the developers, correct?
raevol wrote:Release videos, release packages, the release announcement, etc, will stay on a private board on these forums accessible only by core team members and release packagers. Packages will be vetted by a private team of testers before release, and no packages will be released without testing.
This sounds like it would work very well. It's true that repositories won't be waiting for a release but considering the kind of people that use Linux, I don't think that will be much of a problem. The Linux crowd tends to be more aware when it comes to software in general so those few days between the time that computer automatically updates and the release announcement should not pose a problem, I think.

What would be needed though - and from what I "feel" during release time here it seems needed anyway - is a much more structured way of doing things. Sometimes it looks like that work here is being done without planning. Now I'm sure that's not entirely true, but setting up a planning for each release will probably help. Having different roles with their own tasks and regular status updates (could be as simple as a shared page where people can tick off their tasks when they're done) would make sure everybody is on the same page. Perhaps some scrumming-esque activity wouldn't be amiss.

In short, I think a more rigid structure in the release process would really help.

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

Re: Release process changes

Post by raevol » 04 Sep 2016, 09:59

psi29a wrote:You haven't actually stated what you dislike about our current release cycle.
True! Here's what I dislike:
  • No testing or even expectations of testing are done. If there are any errors with the release packages they are caught far too late. This is actually a HUGE issue. Developers and packagers tend to assume that any work that they do is blessed by the Almighty Father In Heaven Himself, and that they can Do No Wrong. In reality this couldn't be farther from the truth.
  • All release planning is public, causing non-team members to assume that the release is finalized before it actually is. Imagine if our "1.0" is leaked before release, and has some massive flaw. How embarrassing would that be, and what a huge disservice would that be to every contributor to this project from the original Niko to the most recent contributors to the Example Suite. Let's not do that, mmkay?
  • If you really need more reasons please let me know. But honestly if this is not enough to convince you, I've probably picked the wrong hill to die on.
psi29a wrote:Just keep in mind that people only work on this when they have time, we can't expect everyone to be fast on turnaround time for a volunteer project. People are just going to have to deal with that. We're not a commercial venture, we don't pretend to be and if users don't like that, tough shit. We're not here for the money, we're allowed to push back against the expectations.
This is absolutely 100% true. However, my counter to this is that even though we are a volunteer project, we can still have an established process. If it takes the next step in line a few days to happen that's fine, as long as the process is followed.
Atahualpa wrote:That said, I don't mind starting work on the videos a bit later.
First, I haven't seen any issues with the video creation process so far. But second, I also see no issues with the videos being created later, and "holding up" the release. Better to get it right than to rush it. Thank you so much Atahualpa for all the work you do on the videos: I studied film in undegrad, and I know the ridiculous amount of unappreciated and thankless work you are putting into every video. Hats off to you.

User avatar
sjek
Posts: 407
Joined: 22 Nov 2014, 10:51

Re: Release process changes

Post by sjek » 04 Sep 2016, 10:05

in the same way as a side scroller these past releases have seem more cluttered than previous ones. it's have been hard at times to keep in crack what the heck is happening and causing overheat. i think one solution would be to plan as okulo said.
one way to this would be putting needed separate threads from the start to not confuse people so much and less rush xP

another point that would possible help would be put disting RC names to packages that no-one on his right mind can't make the error althought those packages have't been the source or pre release tag .?
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

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

Re: Release process changes

Post by raevol » 04 Sep 2016, 10:07

@Okulo!!! <3 <3 <3
Okulo wrote:I'm not quite sure if there is a lot of difference between this suggestion and what is already done. Zini will put a feature stop on the current version, but developers don't sit on their hands, right?
Developers still work when there is a hold on a release; the difference is that if there is an issue with release packages in Option 1, it would be completely separate from the "official" release. The benefit: the core project givers zero ****s. The drawback: users are confused about the abyssal divide between the core project and the release packages. To clarify: in Option 1, release packages are basically not recognized as official by the "core project". Any issues encountered with them are offloaded to the release packagers.
Okulo wrote:In short, I think a more rigid structure in the release process would really help.
It sounds like you are more of an Option 2 kind of person. While I am more of an Option 1 fan, I do think Option 2 would serve us better than our current release process.

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

Re: Release process changes

Post by raevol » 04 Sep 2016, 10:09

sjek wrote:another point that would possible help would be put disting RC names to packages that no-one on his right mind can't make the error althought those packages have't been the source or pre release tag .?
Honestly I think that most of our issue is the release announcement draft being posted publicly. If that was kept private it would probably assuage most of the grievances we have with the RC publicity. But that itself doesn't solve our issue with release packages not seeing any testing.

User avatar
sjek
Posts: 407
Joined: 22 Nov 2014, 10:51

Re: Release process changes

Post by sjek » 04 Sep 2016, 10:16

But that itself doesn't solve our issue with release packages not seeing any testing.
i think that not inherently a problem but the repoted amounts of it. taking the amount of modding and reddit activity anyway there must be more users than reporters and........ are you meaning the gettrought of reported and solved issues in changelog? the game itself runs plentitly on hours and hours for majority of people nowadays
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest