Lgtm
On Mon, Jun 11, 2018 at 7:58 PM Lars Volker wrote:
> Hi All,
>
> It seems that we intend to have two parallel jobs at most:
>
>- Maximum Total Concurrent Builds: 2
>- Maximum Concurrent Builds Per Node: 1
>
> However, all jobs run on master and then spawn subsequent jobs on worker
>
That looks fine - thanks Lars!
On Mon, Jun 11, 2018 at 7:48 PM, Lars Volker wrote:
> It seems that Jenkins now posted the "Build started" message twice. I
> removed one of them from the config. Tim, can you verify that I removed the
> right one?
>
> https://jenkins.impala.io/job/gerrit-verify-dr
Hi All,
It seems that we intend to have two parallel jobs at most:
- Maximum Total Concurrent Builds: 2
- Maximum Concurrent Builds Per Node: 1
However, all jobs run on master and then spawn subsequent jobs on worker
nodes. This limits the maximum number of concurrent jobs to 1.
If no-one
It seems that Jenkins now posted the "Build started" message twice. I
removed one of them from the config. Tim, can you verify that I removed the
right one?
https://jenkins.impala.io/job/gerrit-verify-dryrun/jobConfigHistory/showDiffFiles?timestamp1=2018-06-11_22-09-04×tamp2=2018-06-12_02-47-10
O
Ok, I applied the changes. Let me know if you run into any issues.
On Mon, Jun 11, 2018 at 3:05 PM, Sailesh Mukil wrote:
> +1
>
> On Mon, Jun 11, 2018 at 3:02 PM, Jim Apple wrote:
>
> > No objection from me.
> >
> > On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstrong >
> > wrote:
> >
> > > > On ni
The latest version of the job only rebases when DRY_RUN==false, so it
should only rebase the patch when the user is actually serious about
merging it. I agree it would be annoying if it rebased as part of a dry run.
On Mon, Jun 11, 2018 at 3:02 PM, Jim Apple wrote:
> No objection from me.
>
> On
+1
On Mon, Jun 11, 2018 at 3:02 PM, Jim Apple wrote:
> No objection from me.
>
> On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstrong
> wrote:
>
> > > On nit: as GVD gets more complex, it becomes harder for new people to
> > understand the messages and +Ns applied to their patches. That doesn't
> me
No objection from me.
On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstrong
wrote:
> > On nit: as GVD gets more complex, it becomes harder for new people to
> understand the messages and +Ns applied to their patches. That doesn't mean
> we shouldn't do this, only that it's something to keep an eye on.
This is great, I'm in favor of automatic rebasing. It's be nice to have a
flag that turns it off though, since rebases sometimes can clutter a review
with many patch sets.
On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstrong
wrote:
> > On nit: as GVD gets more complex, it becomes harder for new peopl
Phil, if Jeszy's solution is possible (feature flag, off by default in the
3.x line), would that align with your preference?
On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky
wrote:
> I agree with Jim. It would be better to bump to 4.0 in my opinion. We
> should follow the simple rule: Breaking
I agree with Jim. It would be better to bump to 4.0 in my opinion. We
should follow the simple rule: Breaking changes must bump the major version
number.
On Mon, Jun 11, 2018 at 2:17 PM, Jeszy wrote:
> My assumption was that the workaround Phil mentioned must be simple to
> toggle (e.g. flag). I
My assumption was that the workaround Phil mentioned must be simple to
toggle (e.g. flag). If it's not, it probably shouldn't be considered a
viable workaround.
On 11 June 2018 at 10:42, Jim Apple wrote:
> Csaba, is that possible with th change similar to how it is now, or would
> it have to be
> On nit: as GVD gets more complex, it becomes harder for new people to
understand the messages and +Ns applied to their patches. That doesn't mean
we shouldn't do this, only that it's something to keep an eye on.
I think this helps with that problem in net by removing the manual rebase
step that
I've tried my job a few times and it's working as expected. Any objections
to me switching over gerrit-verify-dryrun to my approach?
On Thu, Jun 7, 2018 at 2:42 PM, Tim Armstrong
wrote:
> Ok, I was able to put together a test job that does the automatic rebase
> and carries a +2 here: https://je
Csaba, is that possible with th change similar to how it is now, or would
it have to be rewritten?
On Mon, Jun 11, 2018 at 1:30 AM Jeszy wrote:
> I think we should include it in 3.1, with the feature disabled by default
> (to not break on a minor upgrade), but recommend enabling it in docs and
>
I think we should include it in 3.1, with the feature disabled by default
(to not break on a minor upgrade), but recommend enabling it in docs and
make it enabled by default in 4.0.
On 11 June 2018 at 10:23, Jim Apple wrote:
> Any more thoughts? This question is for everyone in the Impala commun
Any more thoughts? This question is for everyone in the Impala community.
Right now the plan is to fold it into 3.1, with two to one in favor of that
over bumping to 4.0.
On Mon, Jun 4, 2018 at 8:48 PM Jim Apple wrote:
> I am more in favor of bumping to 4.0. It is a rapid escalation, but we
> w
17 matches
Mail list logo
