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.
+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 > >
