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 10:30 PM 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.



That is really weird. When I log in I have a green tick under status saying that I have signed it (and that is the email address linked to my account). When my account was set up my name was incorrectly entered as Stan Douglas, and when I corrected it I think a lot of linked eclipse services did not handle the name change very well.

Stuart


 
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

Back to the top