Proton: Stop making next proton commits private

[barfin]

Feature Request

I confirm:

• [x] that I haven't found another request for this feature.
• [x] that I have checked whether there are updates for my system available that
  contain this feature already.

Description

commits to proton-master must be visible to everyone so users will test them and bugs will be found before rolling it into steam

Risks [optional]

No Risks, It's all good things

[aeikum]

The reason I haven't been doing this is because the release cycle is actually very short. There isn't a long-lived next branch where changes are stacked up over weeks. We have a number of developers working on various things in between Proton releases. When we have enough new work to be interesting, I pull all of that work into the next branch and begin the release cycle. The time between pulling that work into next and pushing the release public is usually 2-5 days. Our (CodeWeavers's) QA team tests builds and works with me to solve problems over the course of that release cycle. Once we have a build with no known problems, we push it live, and the next branch goes idle again for a few weeks. Outside of that release cycle window, there isn't a meaningful next branch to do any testing on.

And there is definitely a cost here, both in terms of developer (my) time and possibly in user confusion. During those couple of days, we usually have 2-5 different RC builds. It's easy to imagine users falling behind and testing a now-outdated build. That means I need to spend time sorting through any user feedback we get to ensure they're not finding an issue that was already fixed in an earlier RC. I also think it would be frustrating for users if I didn't explain what changed in each RC. So that's time I need to spend on user communication (how would this communication take place?). And if an RC build breaks something in the user's prefix, we now need to communicate that to users so they don't continue testing in a broken prefix. There's a lot of added complexity when you're working with the public. It's not something where we just flick a switch and everything is done.

[barfin]

The reason I haven't been doing this is because the release cycle is actually very short. There isn't a long-lived next branch where changes are stacked up over weeks. We have a number of developers working on various things in between Proton releases. When we have enough new work to be interesting, I pull all of that work into the next branch and begin the release cycle. The time between pulling that work into next and pushing the release public is usually 2-5 days. Our (CodeWeavers's) QA team tests builds and works with me to solve problems over the course of that release cycle. Once we have a build with no known problems, we push it live, and the next branch goes idle again for a few weeks. Outside of that release cycle window, there isn't a meaningful next branch to do any testing on.

And there is definitely a cost here, both in terms of developer (my) time and possibly in user confusion. During those couple of days, we usually have 2-5 different RC builds. It's easy to imagine users falling behind and testing a now-outdated build. That means I need to spend time sorting through any user feedback we get to ensure they're not finding an issue that was already fixed in an earlier RC. I also think it would be frustrating for users if I didn't explain what changed in each RC. So that's time I need to spend on user communication (how would this communication take place?). And if an RC build breaks something in the user's prefix, we now need to communicate that to users so they don't continue testing in a broken prefix. There's a lot of added complexity when you're working with the public. It's not something where we just flick a switch and everything is done.

Awww thank you so much for your amazing job and hard work mister valve ❤

[aeikum]

@barfin Decided to give something like this a shot after all. See #3721