process refinement: auto deploy from a different branch than "main"

[mr-c]

To facilitate review by @mr-c and others, we should stop auto deploying from the main branch and create a single release branch (or other similar name) that deployments to https://www.commonwl.org/user_guide happen from.

This would enable me and others to batch up reviews for weekly or twice-monthly review + deployment cycles.

Especially for Outreachy, this will enable @swzCuroverse and @tetron to process contributions without needing to wait for me.

This is also an opportunity to be thoughtful about the releases; for example confirming that existing links aren't broken.

Once this is setup , I will adjust merge permissions and I'll probably unsubscribe from most notifications so that @tetron and @swzCuroverse can focus on Outreachy.

• [x] create release branch
• [x] update deployment script to use release instead of main
• [x] Upgrade @tetron's permissions
• [ ] Document release process

[tetron]

Having a separate release branch is a good idea. Can there be a persistent "latest main" rendered somewhere as well? I would also expect to have the permission to merge to release with the understanding that you want an opportunity to do additional review before it goes to live.

[mr-c]

The easy hack is a standing PR to the release branch from the dev branch, and then using the read the docs preview. I'm sure there would be other options with more work than that.

[kinow]

Out of the loop, had a quick read, and remembered that there are also GH actions with an approval process. It requires someone from a group of users with permission to approve the workflow to run. Just in case it sounds helpful to use for this new process :+1:

[swzCuroverse]

Several thoughts.

• It seems that you are confusing returning Peter to his previous role in the CWL repos (i.e. the same permissions he used to have and all the leadership team currently has (except for Michael). We need transparency in this. Who has what permissions and why and why were Peter's permissions changed. I respectfully ask again that Peter be giving the same permissions as the rest of the leadership team.

As for your suggestion. I would like to ask a few questions and make some suggestions.

• Since we haven't used this release process before with User guide, I would suggest we put off the change until we have time to work out the kinks and make a change while Outreachy folks are trying to contribute.

• If we decide to switch to this, it needs to be documented in full ASAP (i.e. in the next few days) or we are going to have a mess on our hands.

• Are we having specific named release branches i.e. User Guide 1.2,.1.3,. Etc Or are we just having a single release branch?

• What does the public facing User Guide point to? The release branch or do we have a latest repo or main repo that changes are pushed to once a release is deemed finished. If that is the case, who and how do we determine a release is finished and who then merges it with this latest repo?

• I personally think of the User guide to be documentation. I don't understand why we would need release notes? I think we should check links but not sure why we can't do that with the process now.

• I am not sure why we need a release repo to recognize authors or people who work on the User Guide. Currently, we have an author's list on the readme and it is empty. Editing that and perhaps putting what people have done would be a good first way to do this?

• Who would in charge of writing release notes?

• If @mr-c is the only one who can declare a release ro be latest, write release note, determine if a "release" is done, etc then we still have a bottleneck problem.

• Additionally, we have a technical team, but it seems they never meet or approve these types of changes. I think we should change what is stated as our process on the website be changed if we aren't following it. It seems currently that all decisions and changes have to realistically go through @mr-c and if that is the case we should be transparent and open about that.

[mr-c]

I clarified a few points in my proposal. As for who else could help with the release process, I would be happy to consider other people who do not work for a commercial CWL implementation, to avoid the conflict of interest problems we had in the past.

[mr-c]

I've created the release branch and updated the deployment action to run from there only; I've upgraded @tetron access; he can accept and merge PRs to the main branch

[swzCuroverse]

I clarified a few points in my proposal. As for who else could help with the release process, I would be happy to consider other people who do not work for a commercial CWL implementation, to avoid the conflict of interest problems we had in the past.

That is strange @mr-c . Peter has built a large chunk of CWL with Seven Bridges. The only issue in the past was with the website and quickly resolved. And that wasn't even a conflict of interest. This is pretty much against the Open Standard policy.

[swzCuroverse]

You do understand everyone with an implementation they are funding via grants or customer support has a similar "conflict of interest". It doesn't matter if it is coming from commerical sources or grant sources. So, unless you block everyone with an implemenation or tool they are funding from release this isn't consistent. I think it is breaking the rules of our community for you to change this without discussing it with both the technical team AND the leadership team AND SFC. Additionally, I believe at BOSC you told Peter you would return his permissions. I guess you changed your mind?

[swzCuroverse]

Additionally we still have the issue that what is released to the public is still hung up on you @mr-c as both a blocker and bus problem. They way to fix a conflict of interest (which I don't think really exists) is to allow several people allow to release and if we absolutely need a vote from either the technical team or leadership to approve a release. I think this is overkill, but it is a better more democratic way than having only 1 person to do the release.

[mr-c]

I'm talking about the final review before publishing updates to the user guide.

Contributions are welcome from all regardless of affiliation, of course.

[swzCuroverse]

I'm talking about the final review before publishing updates to the user guide.

Contributions are welcome from all regardless of affiliation, of course.

Yes, I know. But this means ultimately you are the final decision of what goes into the User Guide (and every other repo you are the only person to release) and that is then this is not decision of the community, leadership team or technical but your decision. Having a single person decide what goes into a project is really against the idea that it is a community standard. It then becomes a Michael standard

[swzCuroverse]

I'm talking about the final review before publishing updates to the user guide.

Contributions are welcome from all regardless of affiliation, of course.

And you didn't address why a commerical implementation is any different than a grant funded one. You didn't address that if seems you made this decision without any leadership or community discussion, and we still have a bus problem

[swzCuroverse]

What would make more sense to me if anyone on the technical team could make a release candidate. Then there could be a reasonable time set for those in tech or leadership team to veto for larger discussion. If there is no veto, then the candidate can go out. This way we don't have a bus problem, there is no slow down since you are busy with your PhD, any "conflicts" of interest can be addressed if they pop up, and we have more a community based release. However, I think major changes to release process and declaring people with commercial ties aren't able to release isn't a decision you should make without consult the other members of the community.

[tetron]

@mr-c could you please also give write permissions to @swzCuroverse so that she can also approve and merge changes to main.

[mr-c]

@mr-c could you please also give write permissions to @swzCuroverse so that she can also approve and merge changes to main.

Sure, this is done