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

Arjan,

Missed that, but my point is the same.   A branch called 4.0.2 should not contain 4.0.3-SNAPSHOT, regardless of how it was created.
I also don't think that EE4J_8 should have a SNAPSHOT version in it.  It is 4.0.2, so it should be at 4.0.2 - no SNAPSHOT.

So the steps I think are needed are: 
  1. merge 4.0.2 back to master (this get's #214 back into master and makes it 4.0.3-SNAPSHOT)
  2. commit to EE4J_8 to be 4.0.2 (no snapshot)
  3. Fix servlet bot so that 4.0.2 branch does not get the next development version commit when it is created from EE4J_8 
  4. create 4.0.x from master and then delete master
  5. set 4.0.x as the default branch in git
  6. delete stuartwdouglas-maven-remote-resources-plugin-EE4J_8

regards




On Tue, 16 Oct 2018 at 09:29, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
>We have a 4.0.2 release branch, but it's pom says it is 4.0.3-SNAPSHOT

That's a branch created by the servlet bot (look at its creator). It's simply whatever is in the EE4J_8 branch as -SNAPSHOT version, then staged to Nexus as that version without -SNAPSHOT and then a new branch is created for that by the servlet bot with the version updated by .01.

It's part of the CI/CD release process that Dmitry has been orchestrating. Many other EE4J projects have the same type of branch created by their respective bots.

Kind regards,
Arjan





On Tue, Oct 16, 2018 at 12:19 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:


All,

I think we are making a bit of a mess here as we just don't have our processes worked out:
  • master's pom says it is 4.0.2-SNAPSHOT, suggesting it is building what will eventually become 4.0.2
  • We have a 4.0.2 release branch, but it's pom says it is 4.0.3-SNAPSHOT
  • We have an EE4J_8 branch (shouldn't that be a tag off the 4.0.2 branch?) which also says it is 4.0.2-SNAPSHOT
  • There are PRs merged to EE4J_8 and 4.0.2 that are not in master (eg #214), yet have no open issue associated with them to ensure they do get merged to master.
I'd like to propose the following process:
  • We don't have a master branch, as they just become dumping grounds for unfinished ideas and you end up not being able to build releases at short notice if needed.
  • Our main branch should be 4.0.x, in which we work on what is intended to be the next 4.0 release, so it should be 4.0.3-SNAPSHOT.  
  • Anything that is not suitable for the next release will need to go into either a 4.1.x branch or a 4.0.x-feature branch
  • We should always be able to merge forward from 4.0.x to any 4.1.x or 5.0.x branch
  • Releases ideally should be pulled off 4.0.x and normally the only commit to them should be the one to update their poms to produce a definite version (not a snapshot).   The commit to update the next development version should go to 4.0.x not to the release branch.
  • PRs should never EVER be accepted into a release branch.   It should be an extraordinary event that a release branch is ever amended after it is made... ie an admission that we goofed.  Only project leads should be able to update a release branch.
  • PRs should always have an associated issue.  If a 3rd party PR is received without an issue, an issue should be created to match.   This will allow issues to be tracked beyond the merger of a PR to a single branch, reopened if necessary and to track any reversions.  It is the issues that should form the basis of release notes.
  • We should not have personally named branches in the main repo (eg stuartwdouglas-maven-remote-resources-plugin-EE4J_8).  They should be named for their feature and assumed that multiple people may work on them.  So this branch should probably have been 4.0.x-maven-remote-resources-plugin or maybe 4.0.2-maven-remote-resources-plugin if it was created to get into a release branch.

I think we can correct what we have got as follows:
  1. merge 4.0.2 back to master (this get's #214 back into master)
  2. revert the commit aacc4e7a19b16b56448e547c3b8fbd2b74548de5 in 4.0.2 to remove the 4.0.3-SNAPSHOT 
  3. create 4.0.x from master and then delete master
  4. set 4.0.x as the default branch in git
  5. merge 4.0.2 to  EE4J_8 so that it gets the reversion of the SNAPSHOT in the pom.
  6. delete stuartwdouglas-maven-remote-resources-plugin-EE4J_8

I've done these steps to my repo here: https://github.com/gregw/servlet-api

thoughts?

cheers



On Mon, 15 Oct 2018 at 22:30, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

The merge of Stuarts recent commit to master into the EE4J branch fails, since it thinks sdouglas@xxxxxxxxxx does not have a valid ECA.


Kind regards,
Arjan




On Mon, Oct 15, 2018 at 9:59 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Stuart,

OK, but lets make sure that any PR into EE4J_8 has already had a PR into master, which I think is mostly the case here.

cheers


On Mon, 15 Oct 2018 at 18:33, Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:


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


On Mon, 15 Oct 2018 at 13:25, Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:


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. 

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.

So as far as I can see the rules from PMC are (from https://www.eclipse.org/ee4j/news/?date=2018-02-16):

"The Project lead for each project creates a protected EE4J_8 branch based on the initial contribution tag. This branch will be the version for the first platform release.

In order to merge a PR into the EE4J_8 branch project lead or PMC approval is required and the change must be tested against the TCK which is currently not available."

So in theory Greg or I could manually push cherry picked commits, but really I think it would make more sense to just use the same pull request based approach we use for master, and it just falls on whoever is merging to make sure that the commit is already in master. The process guarantees at least 2 sets of eyes on the change, while Greg or I manually pushing commits does not.

I don't really like the EE4J_8-dev approach, as it will inevitably require force pushes, and I don't really think the source of the PR matters. 

Stuart

 

cheers



--
_______________________________________________
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


--
_______________________________________________
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


--
_______________________________________________
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


--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com

Back to the top