Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Managing the EE4J_8 Branch



On Mon, Oct 15, 2018 at 1:02 PM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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.
 

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?

Stuart
 
 
regards





On Mon, 15 Oct 2018 at 10:29, Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:
Hi Everyone,

I would like some feedback on how to best manage the EE4J_8 branch.

Greg left a comment on https://github.com/eclipse-ee4j/servlet-api/pull/211 about PR's from private repos to the release branch.

I am not 100% sure what Greg means, but I think the implication is that work is done on the master branch, and then a PR is opened from master back to EE4J_8?

I am ok with this approach in theory, however at the moment it is not really workable as master contains some commits that are not suitable for the EE4J_8 branch.

In particular:


We have been asked to refrain from adding Automatic Module name for now


These break the TCK signature tests (I have confirmed locally that these tests pass against WildFly with these commits reverted).

So as I see it we have the following options:

1) Just cherry-pick the commits we want back into the EE4J_8 branch. This means there is no merge commits from master back to EE4J_8. Every change that needs to go in both will need two seperate PR's.

This does not really seem practical, as in theory we should be running the TCK against everything in the EE4J_8 branch.

2) Temporarily revert the problematic commits in master, use master as our working branch for changes for the EE4J_8 release.

This means for now we only commit changes that are relevant to this release, then open a PR from master back to the EE4J_8 branch when we are ready to release.

3) Create a EE4J_8-dev branch, to stage all EE4J_8 commits.

This is basically similar to approach 1), but with an additional staging branch, so we can limit the amount of TCK testing required.

For what it is worth my preferred approach is approach 2). Basically revert everything that is not suitable for inclusion in the first release, focus on getting the first release done, then start looking at upstream changes once we have a first release. Autoamtic-Module-Name can go in a minor release once there is consensus on what we should be doing there, and changes that affect the signature tests can wait until the TCK has been properly open sourced and the tests can be updated to reflect our changes.

Thoughts? I would really like to get some kind of consensus on this so we can start the release process.

Stuart


_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/servlet-dev


--
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/servlet-dev

Back to the top