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

Change process for landing commits on v4.x-staging #90

Closed
MylesBorins opened this issue Mar 24, 2016 · 5 comments
Closed

Change process for landing commits on v4.x-staging #90

MylesBorins opened this issue Mar 24, 2016 · 5 comments

Comments

@MylesBorins
Copy link
Contributor

Currently we only cherry-pick commits to v4.x-staging that have been in a release for at least a week.

Alternatively we could land any commit once it has been approved for LTS. In this sense we would treat v4.x-staging very similarly to the way in which we treat master for cutting v5.x releases.

This does potentially introduce a higher probability of conflict when making releases, especially if we no longer rebase v4.x-staging. It will also require more attention and effort to make a release.

This will potentially make it easier for other contributors to land code in LTS staging, and I for one would enjoy seeing that job more distributed.

I think there are a variety of other pros and cons, but to making it easier for others to participate in the LTS process wins out.

Thoughts?

TLDR;

When a commit is approved for LTS it will immediately be landed on v4.x-staging

@MylesBorins
Copy link
Contributor Author

/cc @nodejs/ctc @nodejs/tsc

@bnoordhuis
Copy link
Member

I think it should be up to the LTS and the release teams to make that decision. If you decide to go down the path you propose, consider running the CI and citgm for every commit.

(EDIT: Or every non-documentation commit.)

@MylesBorins
Copy link
Contributor Author

@bnoordhuis as it is right now we are not running ci or citgm on every commit landing on staging. It is usually run on the branch after a bunch of commits are landed.

At the moment I am the primary person doing most of this work, and a member of both the LTS and release teams. I'm trying to figure out how to better distribute the load, and avoid having a single point of failure

@mhdawson
Copy link
Member

I think having changes mature in master still makes sense and I think our current stance was that any change needed to have been in a stable release as well.

If the main work is doing the PR (due to conflicts etc.) could we not ask contributors to create the PR against 4.x but only land in staging once the above requirements have been met ?

@MylesBorins
Copy link
Contributor Author

Closing as it seems like things are working the way they are

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants