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 Regards, Hervé Le lundi 20 mars 2017, 00:38:26 CET Christian Schulte a écrit : > 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 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. > > s/targetBranch/targetVersion/g > > We currently have 3.5.0-SNAPSHOT on master. There is no way to create a > branch for 3.5.1-SNAPSHOT today using that naming scheme. Today, master > is at 3.5.0-SNAPSHOT, in one year master is at 3.6.0-SNAPSHOT. Creating > a branch like schulte/master/MNG-6135 today, does not indicate the > target version. The branch should be named schulte/3.6.0/MNG-6135. Not > sure the name really is needed. Finding out about the author or > committer is easy looking at the latest commits. > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
