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: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Release process changes

Post by raevol »

swick wrote:Can you please stop telling me I'm wrong and instead tell me *why* I'm wrong? I actually really don't understand your problem. I don't understand what can't be solved by better communication and conventions.

I'm also kinda pissed that you're condescending here and don't have trust in the people lurking on this forum. I'm with this project for years now, I learned how to do open source here and while I'm not contributing regularly anymore I'm still testing the linux generic builds (probably the only one doing that).
Sure. I'm sorry for being abrupt. I get frustrated when people show up to threads and want to talk and have their opinions heard, but they're ignoring the rest of the discussion in the thread. I'm not trying to attack you with that statement, please hear me out.

We're having several issues with our release process, which I have outlined in this thread several times. One solution to this, which is not the solution I prefer, is to make some parts of the release process, that are absolutely irrelevant to our end users, private for a temporary period. All you are saying is "no don't do this" but not offering any counter-solution that actually works. You say we should name the RC packages RC packages: we actually already do that. So that's not a solution, because if it would work, it would already be working.

If you guys hadn't noticed, my preferred proposed solution to our issues involves absolutely no "secrecy" whatsoever. Everyone seems to be screaming and crying about this "secrecy" but no one wants to propose or even support an alternate, workable solution.

Again I am sorry for being abrupt, I am sorry for being a jerk. Please accept my apology. But please understand where I am coming from.
lysol wrote:I get the point with having RC:s public. OpenTTD announce their RC:s on their news page for example. It makes sense and the argument that no one will confuse an RC for a final release makes sense, and having more testers for the RC:s are great of course.
This is actually something I had not thought of, and might work really well. Instead of divorcing the project from the release packages, or keeping the packages under wraps, we could as a project publicly advertise the RCs and ask for testing. Then everyone knows they are RCs because we are making blog and PR posts about them being RCs, and anyone who gets confused has the entire rest of the community there to correct them.

The only issue I see with this is 95% of the time there's no change between our RCs and our release packages. We don't need widespread testing on our RCs, we just need someone (who didn't package them) to give them a whirl and make sure there's not something gravely wrong with them. The extra work of publicizing the RC and handling the community engagement isn't really justified by the need for testing.

But that's why there's really no issue with having the RCs be "private" for a few days. You're not missing anything... the only thing you would miss is the 5% of the time where something silly didn't make it into that package, and it has to get rebuilt. Remember that the code for the project is still completely public: if you really want to test the release before the release packages come out, just build it yourself. And if you're too lazy to do that, then be really lazy and let someone else test the RC for you before it ends up on your computer.

We're getting completely off track here. If people really don't understand or support the whole private testing phase being added to the release process, then support Option 1, or propose an alternate solution that actually addresses our issues. Turning this into some political drama-fest isn't constructive at all...
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Release process changes

Post by raevol »

raevol wrote:The only issue I see with this is 95% of the time there's no change between our RCs and our release packages. We don't need widespread testing on our RCs, we just need someone (who didn't package them) to give them a whirl and make sure there's not something gravely wrong with them. The extra work of publicizing the RC and handling the community engagement isn't really justified by the need for testing.
To continue this, another problem is that RC testing is not intended to find bugs: all of our releases will have bugs, and if public testers try our packages and then start reporting bugs that have nothing to do with the packaging, that doesn't help us. If you want to be a "public tester" of the project, then you should be downloading nightlies and reporting bugs to the issue tracker. But doing normal testing and bug reporting on an RC build is missing the point. All RC testing is is making sure the package is built right, bugs and all.
swick
Posts: 96
Joined: 06 Aug 2011, 13:00

Re: Release process changes

Post by swick »

There have been many good proposals on how to fix the current communication. You just seem to ignore or outright dismiss all of them.

Anyway, I'll try to summarize a possible solution.

Problem 1: git release tag
  • tag release candidates as openmw-version-RC
  • tag release as openmw-version
  • release on github and on the website at the same time
Problem 2: RC testing
  • create a new section in the forum for release preparations
  • create a thread for every round of RC testing (maybe for every OS?)
  • have a message as the first post on every site which explains what RC's are and what the thread is for
  • create a blog post for the RC release and call for testing
Problem 3: PPA
  • create a thread in the release preparations section
  • update secondary PPA
  • update public PPA from secondary PPA on official release
Problem 4: release videos (and other promotional material)
  • again, thread in the release preparations section
  • again, message as the first post on every site explaining that this is the RC phase and not an official release and also that the videos/content is promotional and premature release of them will hurt the openmw project

Basically, create a new forum section, create a bunch of threads for a specific purpose, have a (big, red, annoying) message at the top explaining what's going on, use the blog more to explain what's currently going on.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Release process changes

Post by AnyOldName3 »

I think part of the problem here is that people are expecting the RCs to do different things. AFAICT:
  • raevol thinks the RC builds only exist so we don't do something silly, like have a release build with a missing DLL or a broken installer. As long as nothing's gone horribly wrong, for example, with the CI system, allowing a commit which causes OpenMW to crash instantly on a particular OS to be included (i.e. something extremely unlikely and unpredictable), the RC builds should just be renamed as release builds. Any bug testing should have been done by keen users on a nightly build already, so an early release of an RC build just generates hype and confusion without helping the project.
  • Lurkers think the RC builds are there so we don't have a horrifically buggy release, for example a build where Vivec decides he's done with Nirn and floats off into the sky. If there are any such bugs, we need to commit a fix, create a new RC tag, and ship a new set of RC builds. We therefore want lots of coverage so as many bugs as possible are found as quickly as possible, so RC builds should be given to every man, woman, child, and continuous integration system in the world, and hiding them means more bugs will get through.
If this is the case, it explains why people don't understand each other.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Release process changes

Post by raevol »

swick wrote:Anyway, I'll try to summarize a possible solution.
I understand where you are coming from, but how does this solution address when people flagrantly disregard any and all "prerelease" messages we stamp on everything, edit those bits out, and post them around the internet for social media points, ad clicks, etc? How does it address the resulting visitors to our site wondering why they were told elsewhere that we are released, when we are not actually released? And how does it address broken RC builds also being posted everywhere in aforementioned fashion?

These are the exact problems we are trying to address, and the proposed solutions I have seen have not addressed these problems in any way, which is why I "seem to ignore or outright dismiss them". I thought previous discussion in this thread made these issues clear, but I guess I was mistaken.

In our current process, people have to dredge through our unwieldly release threads to find the links to the changelog, videos, and RCs, wading through tons of "please test the RC builds", "here's some updates to the changelog draft", "I'll get to the release asap" posts which make it abundantly clear that we are not released. And yet they still repost things, there's still miscommunication, and it's still near impossible to get even the cursory amount of testing that I am asking for on our RC packages. I don't see how your proposed solution solves any of this.

If I am completely mistaken, please explain to me how. I'm sorry that we're both at a point of frustration where we're taking it out on each other, but please just explain to me specifically how I am wrong. I'm happy to read and address your response, and if I truly am wrong, then I will admit that! This is exactly the kind of discussion we need. I came into this thread already at a really high level of frustration, and it was a mistake for me to post "you are wrong" without an explanation earlier. Again, I apologize for that.
AnyOldName3 wrote:I think part of the problem here is that people are expecting the RCs to do different things.
This is certainly true, thank you for clarifying this.
MetaCthulhu
Posts: 27
Joined: 10 Apr 2015, 23:29

Re: Release process changes

Post by MetaCthulhu »

About Option 1, (I'm going to sound like an idiot, but...) who are the release maintainers exactly? And how much more confusing would it make the process for the average user?
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Release process changes

Post by raevol »

MetaCthulhu wrote:About Option 1, (I'm going to sound like an idiot, but...) who are the release maintainers exactly? And how much more confusing would it make the process for the average user?
The release maintainers are people who take our code, and turn them into packages/binaries that people can actually run. Ace does our Windows stuff, K1ll does our Linux binaries, psi29a does our Debian packages, and corristo does our OSX packages.

It would be more confusing, because more likely than not we would "release" without any release packages being built. Users would see the announcement and come here expecting to download stuff, and instead may have to wait up to a few days for the release maintainers to get the packages out.

And if there are any issues with the packages, they would be found after the release, and users would be directed to the release packagers for support.

Of course all of these guys would remain part of the "team", we would just handle the packages differently. This is how most open source projects work- the project itself doesn't distribute packages, they just tag the code, and say "have at it". If the Ubuntu package of Firefox is busted, they don't go to the Firefox guys and complain, they go to the Ubuntu Firefox Packager, who is probably a member of the Ubuntu team, not the Firefox team. The responsibility is then on the distribution, not the project, to correct the release packages.

This would be confusing for "gamers" because in the gaming world, the developer does the packaging, since they don't distribute any source code.
MetaCthulhu
Posts: 27
Joined: 10 Apr 2015, 23:29

Re: Release process changes

Post by MetaCthulhu »

That doesn't sound so bad. As long as there's a disclaimer somewhere saying, "users may have to wait up to a few days for the release maintainers to finish preparing the packages" I can't see why anybody would be majorly turned off by it.
swick
Posts: 96
Joined: 06 Aug 2011, 13:00

Re: Release process changes

Post by swick »

raevol wrote:I understand where you are coming from, but how does this solution address when people flagrantly disregard any and all "prerelease" messages we stamp on everything, edit those bits out, and post them around the internet for social media points, ad clicks, etc? How does it address the resulting visitors to our site wondering why they were told elsewhere that we are released, when we are not actually released? And how does it address broken RC builds also being posted everywhere in aforementioned fashion?
Has it actually been a problem that people *maliciously* posted videos or RC's before the official release? It seems like those posts were due to misunderstanding the release process and not out of evilness. I'm simply assuming that people who lurk in those threads generally like what the project is doing and don't want to hurt it. Give them a chance.
raevol wrote: In our current process, people have to dredge through our unwieldly release threads to find the links to the changelog, videos, and RCs, wading through tons of "please test the RC builds", "here's some updates to the changelog draft", "I'll get to the release asap" posts which make it abundantly clear that we are not released. And yet they still repost things, there's still miscommunication, and it's still near impossible to get even the cursory amount of testing that I am asking for on our RC packages. I don't see how your proposed solution solves any of this.
By giving each tasks their own thread, organizing things better and explaining to outsiders what going on in those threads and on the blog.
raevol wrote: If I am completely mistaken, please explain to me how. I'm sorry that we're both at a point of frustration where we're taking it out on each other, but please just explain to me specifically how I am wrong. I'm happy to read and address your response, and if I truly am wrong, then I will admit that! This is exactly the kind of discussion we need. I came into this thread already at a really high level of frustration, and it was a mistake for me to post "you are wrong" without an explanation earlier. Again, I apologize for that.
You're not wrong with your proposal. I just don't like it. It probably would solve the problems you want to solve but at the cost of transparency and openness.

What I'm noticing is that you really don't seem to believe that everyone will play nice. Have a little bit more trust in the people lurking on the forums. If people really are evil trolls and do things they're not supposed to do, we can still go through with your plan, but why not try something less drastic first?
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Release process changes

Post by raevol »

swick wrote:Has it actually been a problem that people *maliciously* posted videos or RC's before the official release?
I don't think it was malicious, but I also don't see how they could misunderstand, given the context of the thread that they took the links from. And malicious or not, it resulted in big miscommunication, which is the issue we are trying to resolve.
swick wrote:By giving each tasks their own thread, organizing things better and explaining to outsiders what going on in those threads and on the blog.
I think, regardless what else happens, this is really the bare minimum of what we need to do. I don't think it will solve our other problems, but it certainly will make things run smoother. I'm a little fixated on the other issues, but this aspect of what you are suggesting is 100% useful and I think we should do it.
swick wrote:You're not wrong with your proposal. I just don't like it. It probably would solve the problems you want to solve but at the cost of transparency and openness.
But I don't see how keeping a broken RC build out of the public, or ensuring that the release video and changelog are publicized at the correct time, is a bad thing. Again, all the release process stuff can be made open after the release is ready. What's wrong with that? The code is still all on github... Heck, if it really is that big of an issue, maybe we could give access to the private forums to anyone and everyone who asks. And then if we find that they "leak" anything we can just revoke their access.
swick wrote:What I'm noticing is that you really don't seem to believe that everyone will play nice. Have a little bit more trust in the people lurking on the forums. If people really are evil trolls and do things they're not supposed to do, we can still go through with your plan, but why not try something less drastic first?
I don't think people are evil trolls, I think people don't read, and get carried away without taking things in context. I think the essence of good communication is to make it so things are impossible to misunderstand, not assuming that anyone will put in the effort required to understand something that is a little complicated. At the end of the day I'm not going to quit the project if we don't do what *I* want, but I may hand off some of my responsibilities (what little I have, let's be real) if some of the process doesn't get cleaned up. I can handle herding cats inside our own team, I love all of you to pieces. But if I have to herd cats from reddit and every wannabe gaming journalism website on the internet as well, that's... not really what I signed up for.

Edit: And swick, can I ask you what you think of Option 1? If I can get you on board with that that'd be awesome. :D
Post Reply