On Sun, Mar 19, 2017 at 6:56 PM, Fred Cooke <fred.co...@gmail.com> wrote:
> No need to cherry-pick, that should be a rare operation. > > Clean up the branch and prepare it for a fast forward with high quality > commits, then just push it when it's ready and passes scrutiny and tests. > I agree, cherry picking is _not_ a normal operation. There are plusses and minuses to different merge strategies, but I don't really consider cherry picking to be one of them. As an aside, I'm not sure if this would be too much for Maven, but check out git-flow [0], which provides conventions and rationale around git branch management vis-a-vis "hotfixes", "release branches", "feature branches" etc. Whilst adopting the whole of git-flow may be more complex than this project needs, it does offer a clear rationale and definition for different kinds of branches, and it may provide some ideas as the Maven developers investigate their own solutions. [0] https://datasift.github.io/gitflow/IntroducingGitFlow.html +1 on ugly masters. Last time I looked at the docker project the displayed > history showed 15 or so merge commits and NO content commits. Useless. > > On 20 March 2017 at 11:46, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > > until now, target version was managed through Jira issue: I'm not > convinced > > putting the info in an additional place like branch name will help keep > > info > > in sync > > > > For the merge idea, the "target branch" concept seems too much for me: if > > the > > branch was automatically locally rebased on master, this would be simpler > > and > > sufficient IMHO > > > > And I completely dislike merge commits and remaining branches in master: > > commits should be cherry picked and merge commit totally avoided IMHO. > > Merge commits (and complex history retained from this practice) is a big > > pain > > point to me to have a clear master history > > > > Regards, > > > > Hervé > > > > Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit : > > > Unlike the other discuss threads, I think I have some extra context > that > > > means I am going to start from my proposal... or rather my requirements > > and > > > then proposal to solve those requirements. > > > > > > Requirements > > > =========== > > > > > > As a Release Manager, > > > > > > I cannot tell which branches on the CI server are targeted for the > > release > > > and which are "future work" > > > > > > I cannot tell who is responsible for which branches in order to know > who > > to > > > ask w.r.t. their status > > > > > > As a PMC member tasked with reviewing commits > > > > > > I cannot keep track of all the many commits and rebases > > > > > > Proposal > > > ======== > > > > > > 1. We should use a naming scheme for all branches. I am suggesting > > > owner/targetBranch/mng-XXXX - this gives me the information about who > > owns > > > the branch and where the branch is targeted for. > > > > > > 2. We should have the Jenkinsfile build not just the head commit but > the > > > head commit merged to the target branch for any branch following the > > naming > > > scheme. We get the target branch from the naming scheme and by having > the > > > build verify that the branch can be merged without conflict onto the > > target > > > branch we remove the need for constant rebases > > > > > > 3. We merge branches with an explicit merge commit and stop using > > > fast-forward merging only. Again this makes it easier to review and > > allows > > > the noisy branches to be quiet when looked at from the PoV of master > > > > > > This will not solve all the issues, but it would solve the pain points > I > > > have currently. > > > > > > Now if others have a different PoV or a counter-proposal, please speak > > up! > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
