Re: [DISCUSS] How to work with branches

2017-03-20 Thread Hervé BOUTEMY
+1 to the whole analysis on issue tracking vs scm one addition: currently, our PR process is "asking for a second": IMHO, it works Regards, Hervé Le dimanche 19 mars 2017, 22:27:20 CET Elliot Metsger a écrit : > Just two cents from a long-time list lurker: > > First, congrats on all the work

Re: [DISCUSS] How to work with branches

2017-03-20 Thread Hervé BOUTEMY
IMHO, we don't have sufficient *team focus* on one version: how could we have focus on multiple versions at the same time? working on creating a scheme to let people work without the others on another objective (which is supposed to be "the next one") is a recipe for split developer efforts

Re: [DISCUSS] How to work with branches

2017-03-20 Thread Fred Cooke
Because unless the unit test suite has 100% line and branch coverage, and possibly various other metrics, all of which are unfeasible for any real-world sized code base, it could miss something. The first line should/must (if you care) be manual integration of the two change sets, conflicting, or

Re: [DISCUSS] How to work with branches

2017-03-20 Thread Karl Heinz Marbaise
Hi, On 19/03/17 18:34, Stephen Connolly wrote: 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

Re: [DISCUSS] How to work with branches

2017-03-20 Thread Stephen Connolly
On Mon 20 Mar 2017 at 00:44, Fred Cooke wrote: > Sounds like the solution is for people to use a different remote that you > don't feel personally responsible for checking every commit in. And to fix > the email system. > > Split emails for commits on master to everyone and

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Elliot Metsger
On Sun, Mar 19, 2017 at 6:56 PM, Fred Cooke 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,

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Elliot Metsger
Just two cents from a long-time list lurker: First, congrats on all the work done so far! Monumental effort, and a well-deserved congratulations to everyone involved. As a Release Manager, > > I cannot tell which branches on the CI server are targeted for the release > and which are "future

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Fred Cooke
Sounds like the solution is for people to use a different remote that you don't feel personally responsible for checking every commit in. And to fix the email system. Split emails for commits on master to everyone and a new list for other branches. As for Jenkins validating a merge, that's

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Stephen Connolly
On Sun 19 Mar 2017 at 22:56, Fred Cooke 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

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Stephen Connolly
On Sun 19 Mar 2017 at 23:38, Christian Schulte wrote: > Am 03/19/17 um 18:34 schrieb Stephen Connolly: > > 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

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Christian Schulte
Am 03/19/17 um 18:34 schrieb Stephen Connolly: > 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

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Stephen Connolly
On Sun 19 Mar 2017 at 20:05, Fred Cooke wrote: > How are branches noisy? Promiscuous automated emails or some such? PMC (and committers too, but the buck stops at the PMC) are supposed to monitor the commits@m.a.o mailing list. Every time a branch is rebased... boom all

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Fred Cooke
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

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Hervé BOUTEMY
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,

Re: [DISCUSS] How to work with branches

2017-03-19 Thread Fred Cooke
How are branches noisy? Promiscuous automated emails or some such? Surely you don't need to look at all branches unless you've been asked to pre-review something prior to fast-forward? Just the ones you're interested in? Naming scheme sounds sensible, however unless everyone is constantly

[DISCUSS] How to work with branches

2017-03-19 Thread Stephen Connolly
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