Stuart,
My concern is that by accepting PRs directly into a release branch we are at risk of losing them from master in the long run. You say that having 2 PRs unworkable, yet it cannot be avoided because even if we accept PRs directly into a release branch then in all but exceptional circumstances we will still need another PR to get those changes back into master.
I am still not sure exactly what you mean. I don't think two PR's in unworkable (as you say with multiple branches you always get multiple PR's).
Are you saying that we should have a policy that all changes must be merged into master before they go into the release branch? If so I am in 100% agreement.
Yes, that's what I'm saying.
Typically a release branch should be created with a branch of master... it might then get a few merges if development continues, but should eventually either freeze or if there are some more developments needed it should be done by cherry picking from master or from a feature branch that is used to develop whatever the change is and is kept in sync with master.
So I'm very much in favour of 1) : that contributions go to master and that we are very explicit in what we cherry pick and/or merge to a release branch.
This all makes sense going forward, but the question is what to do about the current state of affairs where master has changes that will fail the TCK and so are not suitable for the release branch? If I understand your position you are ok with just cherry-picking fixes back to EE4J_8, as long as they are merged into master first?
I'm not exactly sure how this step should be done. It could be that project leads can cherry pick directly into EE4J_8. Alternately any committer can create a new branch off EE4J_8 (say EE4J_8-dev), cherry pick into that branch from master and then do a PR to merge with the main EE4J_8.
The alternative is a bit of faff.... so if we know the specific commits to master we wish to merge, then I'm OK with you or I doing the cherry pick directly to release branch if the rules permit it.
cheers
