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.
swick
Posts: 96
Joined: 06 Aug 2011, 13:00

Re: Release process changes

Post by swick » 08 Sep 2016, 02:47

Well, that clears things up for me. Different views on the world, different conclusion.

As a compromise, how about this:

1. reorganize the release process in the forums (and possibly on the blog)
2. make threads private if people keep abusing them

User avatar
AnyOldName3
Posts: 540
Joined: 26 Nov 2015, 03:25

Re: Release process changes

Post by AnyOldName3 » 08 Sep 2016, 02:50

It might not be of any use to this discussion, but another open-source project whose primary user group is gamers and handles things pretty well is Dolphin Emulator. While their releases are few and far between, and users are recommended to use development builds, there's never really an issue of broken packages.

Basically, instead of nightlies, 'release' packages are build for every pull request (merged or proposed) as part of the CI process. I think this is actually done on dedicated machines (or dedicated VMs in the cloud) rather than Travis or Appveyor, but I'm guessing they could theoretically be used. The gist of what I'm proposing is:
  • Appveyor & Travis do their usual thing.
  • We add a final few commands to the CI scripts that convert the build that just passed to an installable form (e.g. .msi, .deb, .dmg etc.).
  • Appveyor & Travis then upload these to other machines/VMs.
  • The other machines install the packages from a clean-slate status (e.g. they were just reimaged), and do some basic testing to check nothing's died.
  • These builds are transferred from the secondary testing machines to somewhere else, and listed under a dev build heading at openmw.org/downloads/ and are uploaded to an OpenMW-dev PPA (we might as well let people use them now we have them). They're already verified as 'working'.
The RC process would be mostly irrelevant, as all it would entail would be renaming an existing file and linking to it somewhere official. We get a consistent build environment, and as more things would be automated, there's less chance of something 'dumb' happening, like mispackaging a build. For systems that can't easily have packages generated in the CI environment, we rely on something akin to raevol's 'Option 1', but we get a bunch of coverage of users without much conscious effort.

Obviously this would require a substantial amount of work to set up in the first place (which may be seen as excessive this close to 1.0), but lots of work that happens now by hand would come out for free. There also might be a problem of me wildly simplifying something to the point of trivialising it, and missing that something I've said is actually impossible.

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

Re: Release process changes

Post by raevol » 08 Sep 2016, 03:41

swick wrote:Well, that clears things up for me. Different views on the world, different conclusion.

As a compromise, how about this:

1. reorganize the release process in the forums (and possibly on the blog)
2. make threads private if people keep abusing them
That sounds good to me. The exact structure of the forum communication will have to get sorted out, but I think your point 2 is well taken.

Would you be agreeable to keeping the review of the release video as a more internal thing? Atahualpa puts a ton of effort into that, and think it's only right if it's handled according to his wishes.
AnyOldName3 wrote:... packages are build for every pull request (merged or proposed) as part of the CI process. I think this is actually done on dedicated machines (or dedicated VMs in the cloud) rather than Travis or Appveyor, but I'm guessing they could theoretically be used.
This sounds *amazing* and automation would certainly instill a huge amount of confidence in the release packages. We would be able to hold off on tagging the release build until everything else is in place. There'd be no more issue with public/private RCs, because the release would not exist until we named it, and that package would have already been built by the system.
AnyOldName3 wrote:Obviously this would require a substantial amount of work to set up
This is the achilles heel right here, but I'm willing to chip in my part of someone has the expertise.
AnyOldName3 wrote:(which may be seen as excessive this close to 1.0)
On the contrary, when we start our post-1.0 work, we're really going to need something like this for testing.

User avatar
lysol
Posts: 701
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Release process changes

Post by lysol » 08 Sep 2016, 07:43

Just want to add one thing, although it seems you *might* have come to at least kind of a conclusion now?
swick wrote: Has it actually been a problem that people *maliciously* posted videos or RC's before the official release?
No, it's not a problem if you don't care about PR. But spreading a release video before there even IS a release makes people confused. And making people confused is bad PR. So if you care about PR, I'd say it's kind of a problem yes.

I still support the idea of having RC:s public (maybe not in a news post, but having a new thread for each version's and OS:s RC:s and have a very clear message at the first post what the RC is for) and the video closed until release. For the sake of PR. Basically, to only have the videos hidden until release.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

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

Re: Release process changes

Post by raevol » 08 Sep 2016, 07:47

lysol wrote:it seems you *might* have come to at least kind of a conclusion now?
I think swick and I are just done yelling at each other. :lol: Apologies again swick.

But we still need to nail down our actual path forward. I was hoping for some others to chime in before I launch into my next phase of irrational behavior. 8-)

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

Re: Release process changes

Post by psi29a » 08 Sep 2016, 08:54

Just got into the office...

anyway, my rational behind having a private PPA is that the end result (non-RC, but final version) can be put there, hence the name staging. Since I have better things to do with my time than wait for an OpenMW release (really, house renovations, 4 children and work), I rather have it waiting for me, ready to go. When raevol or whoever says "GO", I would just copy the package from private staging PPA to public PPA.

The private PPA is for _me_, so I don't have to spent too much time on it. Just a click and I'm done. I can do it from my mobile.

If I do what darkbasic suggests, then I have to spend the time to modify changelogs, renaming them, build package, upload for for every release of ubuntu we are currently supporting thus delaying a release even more. I would much rather do it before hand, having it waiting and ready.

Having a Private PPA is no different than doing the above, having the packages sitting on my laptop ready/waiting to be uploaded... except that if something has gone wrong with the upload or the package, I won't know about it until the upload has happened and possibly delay the release. With the Private PPA, I can fix whatever problems come up before the official release.

I still don't see how this effects anyone other than me by making my life easier.

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

Re: Release process changes

Post by raevol » 08 Sep 2016, 09:07

psi29a wrote:I still don't see how this effects anyone other than me by making my life easier.
So what you should do is just do this and not tell anyone, because we won't know any better. :D

What do you think about the CI thing AnyOldName3 mentioned? Would that be possible for our project? Do you have any experience with that sort of thing? Should I research/contact the Dolphin team?

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

Re: Release process changes

Post by psi29a » 08 Sep 2016, 09:16

As for the PPA thing, I thought people would like to know what I was planning on doing instead of totally being out of the loop. I mean, sure, we have done lots of stuff without discussing it in public before, but now with more eyes on the project it doesn't hurt to get feedback to make a better decision. ;)

I'm still a one-man-show here, so if anyone would like to help, I'm more than willing to mentor someone to help handle PPA things. K1ll is my only backup atm.

As for the CI stuff, I already do this with other projects I work on with appveyor, let it create packages and it hosts them for me for the lifetime of the build. That way people can download and test as they like. So doing this for OpenMW shouldn't be a problem.

travis-ci is another ballgame, it does not support hosting artifacts. they suggest that after our builds, we push them to some 3rd-party hosting service like amazon's s3. This costs money. Another solution is to see if Lgro can setup a write only sftp or ftp account and see if we can push the builds to there after every build.

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

Re: Release process changes

Post by raevol » 08 Sep 2016, 09:24

psi29a wrote:I'm still a one-man-show here, so if anyone would like to help, I'm more than willing to mentor someone to help handle PPA things.
*frantically raises hand* If we do this CI thing I won't bother with the Ubuntu Daily PPA, since it will be redundant, but I'd still like to learn packaging!

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

Re: Release process changes

Post by psi29a » 08 Sep 2016, 09:33

Sure, we'll do a google hangout g/talk thing sometime. You know, in case I and/or k1ll get hit by a bus. Speaking of which, how k1ll makes his releases is also black-magic. From what I gather, he creates static builds of all libraries that he can so that it is generic enough. It also has to be built with an older version of glibc since he says it should run on older Fedora/RH/CentOS releases, probably in a VM. Would be interesting if he could also clarify how he goes about things so we can duplicate work should the unthinkable happen.

Either way, what we discuss and if he also talks about his build process, we can document for the wiki and/or openmw's documentation.

Update: There is also a Travis-CI option to upload binaries of a tag. So when Zini tags a release, a build is triggered and anything we want to collect can go there. Not sure if this is helpful for us since k1ll does this for us already.
github: https://docs.travis-ci.com/user/deployment/releases
ftp/sftp: https://docs.travis-ci.com/user/deployment/custom/
lots of others: https://docs.travis-ci.com/user/deployment

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests