A few questions

[misterdjules]

I'm not sure if opening one issue with multiple questions is the preferred way to give some feedback, so please let me know if there's a better way to do that.

First things first, that is some impressive work James, thank you :)

• "The Project source repository will be organized into a single master branch,
  multiple Release branches, and multiple Development Branches."
  Can you give an example of what the multiple development branches could be?
• In the "Landing pull requests" section, instead of hinting at a manual process, why not
  mention the node-accept-pull-request Jenkins job that joyent/node is using?
• This document doesn't mention any roadmap, but both the Node.js and io.js
  projects have worked on a roadmap. How is such a roadmap integrated into the
  development process?
• For LTS releases, I'm not sure I understand properly what LTS "candidates" and
  LTS "versions" are. In the first example, 2.0.0 is an LTS "candidate", and
  2.0.10 is the LTS "version". If a bug is fixed in 2.0.10 and 2.0.11 is
  released, does 2.0.11 automatically become the new LTS version?
• In the "Repository Reconciliation Plan", it says that "Each subsequent release
  ("interim releases") for each project should incrementally bring the two code
  bases closer together", have we already thought about in what way and how we can
  bring the two code bases closer?

[Fishrock123]

I'm not sure if opening one issue with multiple questions is the preferred way to give some feedback, so please let me know if there's a better way to do that.

So far we've been commenting on the commits.

Can you give an example of what the multiple development branches could be?

a v8-next branch is an example.

why not mention the node-accept-pull-request Jenkins job that joyent/node is using?

It's mentioned in the notes. That's just CI and doesn't actually do the merge, right?

[jasnell]

@misterdjules ... it certainly wasn't just me.. but thank you.

The roadmap is the next bit I'm going to be looking at actually. Not sure how that's going to fit in just yet.

An "LTS Candidate" is kind of like a "Release Candidate" only Fuzzier. It's also a sort of Milestone. For instance, if we started working on 2.0.0 today, the LTS WG might come up and say, "We're hoping to make 2.0.x an LTS Release". That makes 2.0.x the LTS Candidate. Let's assume there are a bunch of Patch iterations on it tho to fix issues that come along. The Actual LTS Release may end up being 2.0.23 or some such. If the master ends up rolling over into 2.1 before the LTS Release is cut, then the LTS WG can decide to either stick with it's original LTS Candidate and make the last 2.0.x patch the LTS Release or reset a bit and make 2.1 the next LTS Candidate (hopefully that makes sense).

Re: bringing the code bases back together... that's still an open question. The Convergence WG will largely be responsible for that decision but I will be putting some ideas down in this document before the call on Thursday.

[mikeal]

IMO the roadmap should be another working group. A big part of what that working group should do is find good ways of collecting community and corporate feedback and using that as a guide for reconciling the two existing roadmaps. For the roadmap it is far more important that it address the needs of users than reconciling the future visions both projects had together.

[jasnell]

Yeah, but too many WG's runs the risk of just kicking the ball down the road without setting any clear direction. It may be a bit difficult, but we really need to try to get the combined TC membership to come to a consensus on the high level points then leave it to the WG's to fill in the detail as we go

[mikeal]

Can someone point me to the current node.js roadmap?

[misterdjules]

@Fishrock123 Thanks! Regarding node-accept-pull-request, it does perform the actual merge. The goals are, among other things:

1. Commit messages' metadata is consistent.
2. There's no risk of merging changes that used to pass all tests when the CI ran, but don't at the time they're merged because of others changes that break them have landed in the meantime.

[Fishrock123]

@misterdjules does it preserve both the commiter and author?

I'd kinda like to be able for people to just use git, and jenkins already acts up enough as it is though.

[misterdjules]

@Fishrock123 It does preserve both the committer and the author.

[misterdjules]

@mikeal There is no roadmap for Node.js, but work on defining a roadmap has started a while ago with a meeting during the Node Summit. The minute of the meeting are available here: https://nodejs.org/about/core-team/meetings/2015-02-09/minutes.html.

Since then, there hasn't been any substantial discussions around a road map, as far as I know.

[jasnell]

Which is part of the challenge and why we should get some of this documented now.

[Fishrock123]

@misterdjules can the merging collaborator make edits with node-accept-pull-request?

We have enough cases where the author simply isn't experienced enough with git, or doesn't have the time, where it is valuable enough for us to fix some git and nits and land something.

[misterdjules]

@Fishrock123 Currently, It is not possible to make changes when using node-accept-pull-request.

I personally find this is an acceptable trade-off. It gives me confidence that all changes that landed passed the tests suite and going through the nits with a contributor is a good way to make them more familiar with our process.

I found that when a change lands and breaks a given version because tests were not run on some platform(s) is much more costly in time and energy than going through these details with the original contributor.

[Fishrock123]

I'm not advocating not using CI. I think it is very worthwhile to use CI for basically every non-docs PR.

That being said, sometimes people do make worthwhile contributes, and they never come back to the thread. It happens, but we shouldn't have to throw those out.

I suppose you could argue we could just make an extra PR, but that is just excess process.

[Fishrock123]

Related to node-accept-pull-request..

We have a discussion about force-pushing on the io.js tracker where it was just suggested we could have a pre-commit hook to validate the metadata.

[orangemocha]

Related to node-accept-pull-request..

Making edits to the commit message is certainly something we can easily add to node-accept-pull-request.

My biggest concern about node-accept-pull-request, would be that the existing hardware resources will probably not scale to the volume of commits in a merged project. This probably warrants a separate issue...