+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
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
16 matches
Mail list logo