Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defined release process? #1604

Closed
dsernst opened this issue Jun 17, 2019 · 11 comments
Closed

Defined release process? #1604

dsernst opened this issue Jun 17, 2019 · 11 comments

Comments

@dsernst
Copy link
Contributor

dsernst commented Jun 17, 2019

Is there a defined process to publish new releases?

Looks like the latest (v0.20.0) is from April 2018, over a year ago.

Since then, there have been dozens of PRs merged, and it looks like 181 commits to master. (Cheers, great work everyone. 🥂)

I'm particularly interested in seeing Remove (BETA) from app window title & Add YouTube style hotkeys shipped.

I do see Package the App instructions at the bottom of README.

(I'm happy to package new releases if that's the only blocker on this. Working from a beefy Mac so can build for all platforms, although obv don't have key to sign.)

@DiegoRBaquero
Copy link
Member

We could distribute an unsigned version, as @feross holds the certs and keys, maybe he could share them with me, but only if webtorrent.io updates itself with the repo. Else we are still "blocked" by @feross to also update website.

Hopefully he sees this. If these are blockers we could setup an automated process.

@Borewit
Copy link
Member

Borewit commented Jun 18, 2019

Thanks for your quick reply @DiegoRBaquero.

Can you help us moving on @feross?

@feross
Copy link
Member

feross commented Jul 10, 2019

Hey everyone! I'm happy to do a release (and to do them at more regular intervals going forward). Is the current version on master in a shippable state? Which contributors have done most of the work on this release? Who is willing to own handling issues that arise after the new version goes out by monitoring the telemetry dashboard (i.e. if there is a bad bug, quickly working on a fix for a new release)? Is the changelog written up?

@Borewit
Copy link
Member

Borewit commented Jul 10, 2019

Feross, I think releasing more often will encourage contributors.

I think the master is in a shippable state.

@mathiasvr has done a significant part of the changes. I hope @dsernst is willing to keep actively participating, as he has done a great job lately as well.

Much of the progress has been realized by a large number of contributors submitting small improvements.

I am willing to support addressing issues introduced by the new release on the condition we speed up the approval process of PR's. If I had to choose between risking a mistake slips in or loosing the interest of contributors, I would go for this first in the current situation.

ToDo:

  • Update changelog

@feross
Copy link
Member

feross commented Jul 10, 2019

Feross, I think releasing more often will encourage contributors.

I totally agree.

As most of you have probably gathered, I needed to step away from OSS for a while to rest and recover. I achieved a lot in a short time in the early days of WebTorrent by working really hard but I got totally burned out after several years of working on it full-time. (literally. I worked exclusively on WebTorrent and didn't even have a job to support me for many years). I now feel that I've recovered sufficiently to return with a healthier attitude. We'll see :)

I just want to emphasize how much I appreciate the work that you and all the other contributors have been doing while I've been away.

@Borewit
Copy link
Member

Borewit commented Jul 11, 2019

I wasn't aware you had a burn out.

Let this be a wise lesson to all of you. Especially those hard workers among us, the boys and girls who do not plan to give up, who do the few extra miles every day to do things right.

I am happy to hear you are feeling better Feross.

@mathiasvr
Copy link
Contributor

mathiasvr commented Aug 4, 2019

Just saw this now, good to see you're back @feross!

I haven't been very active in this repo for the past 6 months, but I believe @Borewit has done a great job and have a good overview of the changes during that period.

Quite a while ago I drafted a release with some of the changes (don't know if you can see it?),
but I will try to get it up to date. (Edit: Just opened #1635).

About the approval process of PR's, the major problem IMO is that it is more difficult for active members to get code merged than for other contributors. This is because PR's requires 2 reviews, but since a member cannot approve their own PR, we now actually need 3 active members to get it merged, which have rarely been available.

@feross
Copy link
Member

feross commented Aug 4, 2019

I haven't been very active in this repo for the past 6 months, but I believe @Borewit has done a great job and have a good overview of the changes during that period.

Yeah, I've noticed that. Huge thanks to @Borewit!

Quite a while ago I drafted a release with some of the changes (don't know if you can see it?),
but I will try to get it up to date

I did see this. You put in the GitHub release notes, right? I actually just deleted that since CHANGELOG.md is actually the right place for it. The npm run package script will automatically create a GitHub release at packaging time using the release notes from CHANGELOG.md. :)

@feross
Copy link
Member

feross commented Aug 4, 2019

About the approval process of PR's, the major problem IMO is that it is more difficult for active members to get code merged than for other contributors. This is because PR's requires 2 reviews, but since a member cannot approve their own PR, we now actually need 3 active members to get it merged, which have rarely been available.

I can change the setting so that only 1 review is required to merge. I think it would be best if we still waited for 2 approvals from team members for outside PRs that are not trivial. For PRs that come from a team member, only one approval should be sufficient.

We should also try to wait for a week or two for big changes, or changes that are likely to be controversial, so that everyone has a chance to see the PR and give feedback before it's merged (even if there's already enough approvals to merge).

Does this sound reasonable to everyone?

@Borewit
Copy link
Member

Borewit commented Aug 4, 2019

For PRs that come from a team member, only one approval should be sufficient.

Yes please, I lost focus so ofton on pending approvals. Let's grab the momentum, and prevent loosing focus.

@feross
Copy link
Member

feross commented Sep 7, 2019

Hey everyone, if it's okay with everyone I'd like to close this issue now. I made a new issue with some ideas to improve the release process: #1678

@feross feross closed this as completed Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants