ith the developers
> > total/committers ratio that we have now, it helps the process scale
> better.
> >
> > --
> > AY
> >
> > On May 7, 2015 at 19:02:36, Benedict Elliott Smith (
> > belliottsm...@datastax.com) wrote:
> >
> > >
> > > I wou
process scale better.
>
> --
> AY
>
> On May 7, 2015 at 19:02:36, Benedict Elliott Smith (
> belliottsm...@datastax.com) wrote:
>
> >
> > I would argue that we must *at least* do the following for now.
>
>
> If we get this right, t
tio that we have now, it helps the process scale better.
>
> --
> AY
>
> On May 7, 2015 at 19:02:36, Benedict Elliott Smith (
> belliottsm...@datastax.com) wrote:
>
> >
> > I would argue that we must *at least* do the following for now.
>
>
> If we get this right
>
> I would argue that we must *at least* do the following for now.
If we get this right, the extra staging branches can certainly wait to be
assessed until later.
IMO, any patch should have a branch in CI for each affected mainline
branch, and should have the commit comp
>
> I would argue that we must *at least* do the following for now.
If we get this right, the extra staging branches can certainly wait to be
assessed until later.
IMO, any patch should have a branch in CI for each affected mainline
branch, and should have the commit completely wi
the new merge
> > did
> > > > not
> > > > >> >> > conflict or mess up the other people's C2 to C4 commits, and
> > they
> > > > >> have to
> > > > >> >> > now merge on top. But what if another merge comes in, C6
On Thu, May 7, 2015 at 7:13 AM, Aleksey Yeschenko
wrote:
>
> That said, perhaps it’s too much change at once. We still have missing
> pieces of infrastructure, and TE is busy with what’s already back-logged.
> So let’s revisit this proposal in a few months, closer to 3.1 or 3.2, maybe?
>
Agreed.
meantime;
> > > >> >> > and C2 really did also break the tests in some way; how do we
> > > >> determine
> > > >> >> C2
> > > >> >> > was to blame, and not C6, or C3 or C4? What do the commit
lved. Really we
> > have
> > >> to
> > >> >> > prevent any merges to the staging repository until the mistakes
> are
> > >> >> fixed.
> > >> >> > Since our races in these scenario are the length of time taken
> for
&
a link to cassci for both of those branches passing doesn’t
qualify as done to me.
That alone will be enough to catch most merge-related regressions.
Going with staging branches would also prevent any issues from concurrent
pushes, but given the opposition, I’m fine with dropping that
cassci
> >> >> > to vet them, these problems are much more likely than current race
> to
> >> >> > commit.
> >> >> >
> >> >> > In the scheme I propose, in this scenario, the person who broke the
> >> build
> >&g
re
> trying to do.
>
> So the phrase "Trunk is always releasable" definitely has some wiggle room
> because you have to define what your release process is.
>
> If your requirement is that at any time you be able to tag trunk and ship
> it within minutes then yes staging
build
>> >> > rebases everyone's branches to his now fixed commit, and the next
>> broken
>> >> > commit gets blamed, and all other commits being merged in on top can
>> go
>> >> in
>> >> > smoothly. The only pain point I can think
quot; definitely has some wiggle room
because you have to define what your release process is.
If your requirement is that at any time you be able to tag trunk and ship
it within minutes then yes staging branches help solve that problem.
The reality is that the release process always takes low singl
> > but this is solved by git rerere.
> >> >
> >> > I agree running tests is painful, but at least for the build, this
> should
> >> >> be the responsibility of the committer to build before merging
> >> >
> >> >
> >> &
l-clean && ant tasks, and
>> increases
>> > the race window for merging (which is painful whether or not involves a
>> > rebase), and it is not a *typical* occurrence ("alarming" is subjective)
>> >
>> > On Thu, May 7, 2015 at 2:12 PM, Sylvai
> >
> > Ariel
> >
> > On Thu, May 7, 2015 at 5:05 AM, Benedict Elliott Smith <
> > belliottsm...@datastax.com> wrote:
> >
> > > A good practice as a committer applying a patch is to build and run the
> > > unit tests before updating the main r
typical* occurrence ("alarming" is subjective)
> >
> > On Thu, May 7, 2015 at 2:12 PM, Sylvain Lebresne
> > wrote:
> >
> >> > If one of them breaks, we go and edit the _staging branch in place to
> >> correct
> >> > the problem, and let CI
gt;> unit tests before updating the main repository, but to do this for every
>>> branch is infeasible and impacts local productivity. Alternatively,
>>> uploading the result to your development tree and waiting a few hours for
>>> CI to validate it is likely to result
ranch is infeasible and impacts local productivity. Alternatively,
> > uploading the result to your development tree and waiting a few hours for
> > CI to validate it is likely to result in a painful cycle of race-to-merge
> > conflicts, rebasing and waiting again for the
roductivity. Alternatively,
> > uploading the result to your development tree and waiting a few hours for
> > CI to validate it is likely to result in a painful cycle of race-to-merge
> > conflicts, rebasing and waiting again for the tests to run.
> >
> > So I would like
it is likely to result in a painful cycle of race-to-merge
> conflicts, rebasing and waiting again for the tests to run.
>
> So I would like to propose a new strategy: staging branches.
>
> Every major branch would have a parallel branch:
>
> cassandra-2.0 <- cassandr
painful cycle of race-to-merge
> conflicts, rebasing and waiting again for the tests to run.
>
> So I would like to propose a new strategy: staging branches.
>
> Every major branch would have a parallel branch:
>
> cassandra-2.0 <- cassandra-2.0_staging
> cassandra-2.1 &l
; > wrote:
> >
> >> > If one of them breaks, we go and edit the _staging branch in place to
> >> correct
> >> > the problem, and let CI run again.
> >>
> >> I would strongly advise against *in place* edits. If we do it, we'll
> end u
nch in place to
>> correct
>> > the problem, and let CI run again.
>>
>> I would strongly advise against *in place* edits. If we do it, we'll end up
>> in
>> weird situations which will be annoying for everyone. Editing commits that
>> have
>> been
up
> in
> weird situations which will be annoying for everyone. Editing commits that
> have
> been shared is almost always a bad idea and that's especially true for
> branch
> that will have some amount of concurrency like those staging branches.
>
> Even if such problems
r
>> CI to validate it is likely to result in a painful cycle of race-to-merge
>> conflicts, rebasing and waiting again for the tests to run.
>>
>> So I would like to propose a new strategy: staging branches.
>>
>> Every major branch would have a parallel branch:
g a few hours for
> CI to validate it is likely to result in a painful cycle of race-to-merge
> conflicts, rebasing and waiting again for the tests to run.
>
> So I would like to propose a new strategy: staging branches.
>
> Every major branch would have a parall
the tests to run.
>
> So I would like to propose a new strategy: staging branches.
>
> Every major branch would have a parallel branch:
>
> cassandra-2.0 <- cassandra-2.0_staging
> cassandra-2.1 <- cassandra-2.1_staging
> trunk <- trunk_staging
>
> On commit,
> Agreed as far as having staging branches vetoed by CI goes. Less sure about
> the edit-commit-in-place part as said above.
Right. That’s just an implementation detail (in place vs. extra fix up
commits). The latter is less annoying for the team in general, let’s do that
instead.
>
d is almost always a bad idea and that's especially true for
branch
that will have some amount of concurrency like those staging branches.
Even if such problems are rare, better to avoid them in the first place by
simply
commit new "fixup" commits as we currently do. Granted thi
ng and waiting again for the tests to run.
>
> So I would like to propose a new strategy: staging branches.
>
> Every major branch would have a parallel branch:
>
> cassandra-2.0 <- cassandra-2.0_staging
> cassandra-2.1 <- cassandra-2.1_staging
> trunk <- trunk_stagi
. Alternatively,
uploading the result to your development tree and waiting a few hours for
CI to validate it is likely to result in a painful cycle of race-to-merge
conflicts, rebasing and waiting again for the tests to run.
So I would like to propose a new strategy: staging branches.
Every
validate it is likely to result in a painful cycle of race-to-merge
conflicts, rebasing and waiting again for the tests to run.
So I would like to propose a new strategy: staging branches.
Every major branch would have a parallel branch:
cassandra-2.0 <- cassandra-2.0_staging
cassandra-
34 matches
Mail list logo
