On Sun 19 Mar 2017 at 22:56, 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. > > +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. All depends on POV I happen to prefer merge commits - but I would say that having gotten correct --first-parent support added to more of the git CLI Having looked at how people abuse git, I actually think we'd have a cleaner history if we required merge commits and banned fast-forward commits. Certainly keeps code review simpler.., OTOH perhaps this is just a problem that can be solved by INFRA if we get them to only notify for tags and protected branches > > 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 > > > > > -- Sent from my phone
