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

Re: Release process changes

Post by swick » 07 Sep 2016, 22:33

raevol wrote:All "private" discussions can and should be made public after the release is finalized. We're not trying to hide things from the community, just trying to prevent miscommunication.
I'm sorry raevol, but what you're trying to do is removing communication and not preventing miscommunication. Can we at least first try to solve this problem by better and more communication?

darkbasic
Posts: 104
Joined: 18 Apr 2016, 15:45
Contact:

Re: Release process changes

Post by darkbasic » 07 Sep 2016, 22:36

psi29a wrote:Already thought about this and it will happen eventually, but there is still going to be a private PPA. So testers get their openmw-beta, which I have been doing by hand anyway but now we can get more coverage. The Private PPA will host the finalized package that awaits to be copied over to the public PPA when release is finalized. It is quite possible they Canonical will say no, in which I would have no choice to keep things 'status quo'.
And what do you thing you will gain by hiding almost-ready-to-be-renamed packages from the public? I think nothing.
What you will lose? Testing coverage. And public involvement mostly, which helps to build communities. Someone else may test the packages and find some nasty packaging bugs you (yourself and the closed beta staff) didn't notice.

This is my suggested workflow, already battle tested by several projects:

When you want to release let's start by creating a stable branch (which you already do), then you can start by tagging betas, IF you think that the final will almost certainly differ. When you are satisfied by the quality of the last beta you can tag the first RC, which, if everything goes well, is supposed to point to the very same commit of the final. In the meantime packagers started to target betas/RCs and to release their packages in their beta channel/PPA/whatever, so that everyone can test them. When everybody is satisfied with the current release quality a final tag is made, pointing to the same commit of latest RC. Also packages will be renamed to final and published to the stable channel. Otherwise, if something gone wrong, another RC will be issued.

Such a way you will gain all the benefits from the public involvement (which are not limited to better quality packages, the greater benefit will be helping to keep the community alive through people's involvement). You also have no downsides compared to the public PPA approach.

I also suggest you to create a new PUBLIC forum section called "Release Crafting"/whatever_you_prefer, which will help to avoid confusion allowing to separate contents by topic. Such a forum section should have a PRIVATE subsection for the youtube videos.

Just my 2 cents

P.S.
If the "final" version is supposed to be still an alpha it doesn't matter at all. That's just a naming convention and openmw is already in a far better shape than lots of other "stable" projects.

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

Re: Release process changes

Post by raevol » 07 Sep 2016, 22:39

@swick, @darkbasic, I'm sorry but you guys are completely wrong. Maybe it's because you don't have any involvement in our release process. None of what you are suggesting will help solve any of the problems we are having.

darkbasic
Posts: 104
Joined: 18 Apr 2016, 15:45
Contact:

Re: Release process changes

Post by darkbasic » 07 Sep 2016, 22:43

raevol wrote:as well as an unavoidable backlash from the community from people who don't understand the reasons for this, or who choose not to understand because they want access to stuff they shouldn't have access too (probably because they are using it for social media points) is just going to be a mess for us.
I built my own multi-architecture build servers because I maintain my own fork of Debian for internal usage, getting early access to some pre-built packages is really the last of my thoughts, especially since I prefer to play git master.
On the contrary my first thought is trying to keep the community the more active as possible, because I wish the best to this project.

darkbasic
Posts: 104
Joined: 18 Apr 2016, 15:45
Contact:

Re: Release process changes

Post by darkbasic » 07 Sep 2016, 22:44

raevol wrote:@swick, @darkbasic, I'm sorry but you guys are completely wrong. Maybe it's because you don't have any involvement in our release process. None of what you are suggesting will help solve any of the problems we are having.
Then what I fail to understand is what are the problems you're currenctly facing which you think will get magically solved by a private PPA.

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

Re: Release process changes

Post by raevol » 07 Sep 2016, 22:48

darkbasic wrote:Then what I fail to understand is what are the problems you're currenctly facing which you think will get magically solved by a private PPA.
raevol wrote:
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.
The private PPA thing is not my suggestion, but it is a strategy to prevent confusion when release packages are pushed through to end users before our release announcement is made.

darkbasic
Posts: 104
Joined: 18 Apr 2016, 15:45
Contact:

Re: Release process changes

Post by darkbasic » 07 Sep 2016, 22:51

raevol wrote:[The private PPA thing is not my suggestion, but it is a strategy to prevent confusion when release packages are pushed through to end users before our release announcement is made.
Confusion which can be avoided with naming conventions, as I suggested. Nobody is going to confuse 0.41-RC1 with the 0.41 final.

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

Re: Release process changes

Post by raevol » 07 Sep 2016, 22:56

darkbasic wrote:Confusion which can be avoided with naming conventions, as I suggested. Nobody is going to confuse 0.41-RC1 with the 0.41 final.
So if we assume users actually read the package names when they apt update, then your suggestion does solve the problem for a small portion of our user base. But what about the rest of the issue? There's a lot more to this than just the PPA.

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

Re: Release process changes

Post by lysol » 07 Sep 2016, 23:12

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.

Release videos and the final release packages on the other hand has no reason to be public before release IMO.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

swick
Posts: 96
Joined: 06 Aug 2011, 13:00

Re: Release process changes

Post by swick » 07 Sep 2016, 23:15

raevol wrote:@swick, @darkbasic, I'm sorry but you guys are completely wrong. Maybe it's because you don't have any involvement in our release process. None of what you are suggesting will help solve any of the problems we are having.
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).

I love this project and part of what I love is the openness, that I can still keep track of everything that's going on even though I'm doing other things now.

Post Reply