On 5 January 2018 at 13:32, Steve Ebersole wrote:
> Certain parts of the release process are easy to automate, assuming nothing
> goes wrong of course. Other parts are not. Which actually circles back to
> some things I've been comtemplating about (ORM at least) releases.
> Basically we have an
BTW Gail... back to part of your original question... a branch in git is
very cheap, so I like create a branch anytime we jump to a new "line of
development". It's just much more flexible moving forward. So yes, there
is a 5.2 branch - but that does not mean we have to do something with it
(backp
On Fri, Jan 5, 2018 at 8:23 AM Guillaume Smet
wrote:
> On Fri, Jan 5, 2018 at 2:32 PM, Steve Ebersole
> wrote:
>
>> Certain parts of the release process are easy to automate, assuming
>> nothing goes wrong of course. Other parts are not. Which actually circles
>> back to some things I've been
On 5 January 2018 at 15:04, Steve Ebersole wrote:
> TBH, I'm ok with just dropping the TODO collection as a part of the Jenkins
> jobs.
Even better, that will bring down the times from 15m to 12m :)
Doing that now.
>
> On Fri, Jan 5, 2018 at 8:56 AM Sanne Grinovero wrote:
>>
>> On 5 January 201
TBH, I'm ok with just dropping the TODO collection as a part of the Jenkins
jobs.
On Fri, Jan 5, 2018 at 8:56 AM Sanne Grinovero wrote:
> On 5 January 2018 at 14:07, Steve Ebersole wrote:
> > I have no idea what GitBlamer is. Never heard of it
>
> I figured it out; it's implicitly (by default)
On 5 January 2018 at 14:07, Steve Ebersole wrote:
> I have no idea what GitBlamer is. Never heard of it
I figured it out; it's implicitly (by default) invoked by the job
tasks of finding "TODO"'s and similar markers in the project,
to add "blame" information to the final report.
So for each and
On Fri, Jan 5, 2018 at 2:32 PM, Steve Ebersole wrote:
> Certain parts of the release process are easy to automate, assuming
> nothing goes wrong of course. Other parts are not. Which actually circles
> back to some things I've been comtemplating about (ORM at least) releases.
> Basically we hav
I have no idea what GitBlamer is. Never heard of it
On Fri, Jan 5, 2018, 7:38 AM Sanne Grinovero wrote:
> On 5 January 2018 at 13:12, Sanne Grinovero wrote:
> > On 5 January 2018 at 12:28, Steve Ebersole wrote:
> >> FWIW... I do not know the rules about how these slaves spin up, but in
> the
On Fri, Jan 5, 2018 at 2:13 PM, Steve Ebersole wrote:
> While I understand the sentiment of continuing to develop old lines
> (branches) of code, that's just not viable. And this is something we have
> all discussed as a (full) team a few times now. Once the next development
> line is stable we
On 5 January 2018 at 13:12, Sanne Grinovero wrote:
> On 5 January 2018 at 12:28, Steve Ebersole wrote:
>> FWIW... I do not know the rules about how these slaves spin up, but in the
>> 10+ minutes since I kicked off that job it is still waiting in queue.
>
> When there are no slaves it might take
Certain parts of the release process are easy to automate, assuming nothing
goes wrong of course. Other parts are not. Which actually circles back to
some things I've been comtemplating about (ORM at least) releases.
Basically we have an elaborate set of steps we go through for a release
beyond j
On 5 January 2018 at 13:05, Guillaume Smet wrote:
> Hi,
>
> AFAICS there are 52 issues fixed for 5.2.13.
>
> And there are a couple of PRs waiting for review AFAICS (which might be
> ready to be integrated or not).
>
> So I think it would be really beneficial to continue doing 5.2.x releases.
>
>
On 5 January 2018 at 12:28, Steve Ebersole wrote:
> FWIW... I do not know the rules about how these slaves spin up, but in the
> 10+ minutes since I kicked off that job it is still waiting in queue.
When there are no slaves it might take some extra minutes; on top of
that I was manually killing s
While I understand the sentiment of continuing to develop old lines
(branches) of code, that's just not viable. And this is something we have
all discussed as a (full) team a few times now. Once the next development
line is stable we stop developing the older line. That's even more true
within a
Hi,
AFAICS there are 52 issues fixed for 5.2.13.
And there are a couple of PRs waiting for review AFAICS (which might be
ready to be integrated or not).
So I think it would be really beneficial to continue doing 5.2.x releases.
5.3 is not there yet. And once it's going to be released, we would
FWIW... I do not know the rules about how these slaves spin up, but in the
10+ minutes since I kicked off that job it is still waiting in queue. And
there is actually a job (Debezium Deploy Snapshots) in front of it that has
been waiting over 3.5 hours
On Fri, Jan 5, 2018 at 6:20 AM Steve Ebers
I went to manually kick off the main ORM job, but saw that you already had
- however it had failed with GC/memory problems[1]. I kicked off a new
run...
[1] http://ci.hibernate.org/job/hibernate-orm-master-h2-main/951/console
On Fri, Jan 5, 2018 at 4:59 AM Sanne Grinovero wrote:
> On 4 Januar
We should definitely stop doing 5.2 releases once we release 5.3.
Of course 5.3 is held up waiting for answers from a few people...
On Thu, Jan 4, 2018, 7:29 PM Gail Badner wrote:
> We discussed stopping 5.2 releases at the F2F, but I can't remember what
> was decided.
>
> I see that there is a
On 5 January 2018 at 07:57, Yoann Rodiere wrote:
> Great, thanks for all the work!
>
> Now that we have on-demand slave spawning, maybe we could get rid of our
> "hack" consisting in assigning 5 slots to each slave and a weight of 3 to
> each job? I would expect the website and release jobs to rar
On 4 January 2018 at 23:52, Steve Ebersole wrote:
> Awesome Sanne! Great work.
>
> Anything you need us to do to our jobs?
No changes *should* be needed. It would help me if you could all
manually trigger the jobs you consider important and highlight
suspucious problems so that we get awareness
20 matches
Mail list logo
