Re: [hibernate-dev] Move beanvalidation-benchmark to Hibernate org

[Gunnar Morling]

+1, good idea. Thanks!

2018-01-09 14:46 GMT+01:00 Guillaume Smet :

> Hi,
>
> Now that we added some more value to the Bean Validation benchmark [1]
> (Marko converted them to JMH), I think it's time to move the repo to the
> Hibernate org.
>
> Anyone against it?
>
> FYI, it's Apache 2 licensed as it's derived from previous work from the
> Apache BVal people.
>
> [1] https://github.com/gsmet/beanvalidation-benchmark
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Jenkins job priorities

[Yoann Rodiere]

Hello,

TL;DR: I installed a plugin to prioritize Jenkins jobs, please let me know
if you notice anything wrong. Also, I will remove the Heavy Job plugin
soon, let me know if you're not okay with that.

I recently raised the issue on HipChat that some Jenkins builds are
triggered in batch, something like 4 or 5 at a time. Since builds are
executed in the order they are requested, this forces the next requested
builds to wait for more than one hour before being executed, regardless of
their urgency.
One example of such batch is whenever something is pushed to Hibernate ORM
master (or Search master, probably): one build is triggered for tests
against H2, another for tests against PostgreSQL, another for tests against
MariaDB, and so on.

It turns out there is a solution for this problem: the PrioritySorter
plugin. I installed the plugin on CI and configured it to give higher
priority to the following builds:

   - Builds triggered by users (highest priority)
   - Release builds (builds in the "Release" view)
   - Website builds (builds in the "Website" view)
   - PR builds (builds in the "PR" view)

In practice, such builds will be moved to the front of the queue whenever
they are triggered, resulting in reduced waiting times.

I hope we will be able to use this priority feature instead of the Heavy
Job plugin (which allows to assign weights to jobs), and avoid concurrent
builds completely. With the current setup, someone releasing his/her
project will only have to wait for the currently executing build to finish,
and will get the highest priority on the release builds. Maybe this is
enough? If you disagree, please raise your concerns now: I will disable the
Heavy Job plugin soon and set each slave to only offer one execution slot.

Please let me know if you notice anything wrong. I tested the plugin on a
local Jenkins instance, but who knows...

Yoann


-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Guillaume Smet]

Hi,

On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere  wrote:
>
> I hope we will be able to use this priority feature instead of the Heavy
> Job plugin (which allows to assign weights to jobs), and avoid concurrent
> builds completely. With the current setup, someone releasing his/her
> project will only have to wait for the currently executing build to finish,
> and will get the highest priority on the release builds. Maybe this is
> enough? If you disagree, please raise your concerns now: I will disable the
> Heavy Job plugin soon and set each slave to only offer one execution slot.
>

I'm not really convinced by this solution. Some jobs still take quite a lot
of time and having to wait 20 minutes for each job I would trigger is a bit
annoying.

If it was for only one job, it would be acceptable, but let's take the
worst case of a coordinated HV release :
- TCK release
- API release
- HV release
- website
- blog

I won't have to wait for each of them as some of them will be grouped by
the prioritization but I'm pretty sure I will have to wait for several of
them.

So, I'm +1 on having this plugin as it seems to be helpful on its own but
I'm -1 on considering it is a solution to the "let's roll a release" thing.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Move beanvalidation-benchmark to Hibernate org

[Guillaume Smet]

Hi,

So I did the move.

And then I thought why not the beanvalidation organization?

I didn't think of it before as I'm not sure this benchmark will stay
totally HV agnostic but for now it is and it could probably stay this way.
If we want some HV specific things, we can still add a specific benchmark
module and keep the BV ones separated.

It would be nice if it was considered a Bean Validation effort rather than
as a purely HV one.

But maybe it makes it too official to have it in the BV organization?

WDYT?

-- 
Guillaume

On Wed, Jan 10, 2018 at 9:33 AM, Gunnar Morling 
wrote:

> +1, good idea. Thanks!
>
> 2018-01-09 14:46 GMT+01:00 Guillaume Smet :
>
>> Hi,
>>
>> Now that we added some more value to the Bean Validation benchmark [1]
>> (Marko converted them to JMH), I think it's time to move the repo to the
>> Hibernate org.
>>
>> Anyone against it?
>>
>> FYI, it's Apache 2 licensed as it's derived from previous work from the
>> Apache BVal people.
>>
>> [1] https://github.com/gsmet/beanvalidation-benchmark
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Sanne Grinovero]

On 10 January 2018 at 10:25, Guillaume Smet  wrote:
> Hi,
>
> On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere  wrote:
>>
>> I hope we will be able to use this priority feature instead of the Heavy
>> Job plugin (which allows to assign weights to jobs), and avoid concurrent
>> builds completely. With the current setup, someone releasing his/her
>> project will only have to wait for the currently executing build to finish,
>> and will get the highest priority on the release builds. Maybe this is
>> enough? If you disagree, please raise your concerns now: I will disable the
>> Heavy Job plugin soon and set each slave to only offer one execution slot.

Thanks Yoann! that sounds great.

>>
>
> I'm not really convinced by this solution. Some jobs still take quite a lot
> of time and having to wait 20 minutes for each job I would trigger is a bit
> annoying.
>
> If it was for only one job, it would be acceptable, but let's take the
> worst case of a coordinated HV release :
> - TCK release
> - API release
> - HV release
> - website
> - blog
>
> I won't have to wait for each of them as some of them will be grouped by
> the prioritization but I'm pretty sure I will have to wait for several of
> them.
>
> So, I'm +1 on having this plugin as it seems to be helpful on its own but
> I'm -1 on considering it is a solution to the "let's roll a release" thing.

Some of our test suites used to take 2 hours to run (even 5 days some
years ago); now you say waiting 20 minutes is not good enough? You'll
have to optimise our code better :P

It's very easy to spin up extra nodes; my recommendation is that when
you know you're about to release [for example approximately one hour
in advance while you might be double-checking JIRA state and such
things] hit that manual scale-up button and have CI "warmed up" with
one or two extra nodes.

By the time you need to trigger the release job you'll have the build
queue flushed, the priority plugin helping you out, and still
additional extra slaves running to run it all in parallel.

And of course for many releases we don't care for an extra 30 minutes
so you're free to skip this all if it's not important; incidentally
for "work in progress" milestones like the module packs which we
recently re-released several times while polishing up the PR I've been
releasing from my local machine; it's good to have CI automate things
but I don't think we should get in a position to require 100%
availability from CI: practice releases locally sometimes.

If we really wanted to invest more in it (both time and budget),
there's the option of spinning up new containers for each job as soon
as you need one but I feel like we've spent too much time on CI
already; such technology is maturing so my take is let it mature a bit
more, and in 6 months we'll do another step of improvement; jumping on
those things makes us otherwise the beta testers and steals critical
time from our own projects.
Let's not forget that many Apache projects take a week or two to
perform a release, we all know of other projects needing months, so by
the law of diminishing returns I don't think we should invest much
more of out time to shave on the 10 minutes.. just spin up some extra
nodes :)

Thanks,
Sanne

>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Awestruct upgrade to version 0.5.7

[Davide D'Alto]

Hello,
I've upgraded awestruct to version 0.5.7.

Except for the minification of our stylesheets it seems to work fine
but It would be nice if someone else can have a look at generate site
and confirm to me that's
OK to apply the changes in production.

On the same note, I've noticed that we are using some custom
extensions to execute the minification, specifically the one in
_ext/css_minifier.rb.

Is there any reason to do that? I'm asking because Awestruct comes
with its own minification class called: Awestruct::Extension::Minify

The main difference I noticed is that this extension doesn't copy the
original file during deploy on the server and only uses the minified
one.
Also currently, this extension doesn't work for CSS but I guess they
are going to fix it in the next releases (it works for html and js).

Cheers,
Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Move beanvalidation-benchmark to Hibernate org

[Gunnar Morling]

I had been wondering about that, too, but I felt for now it's better
located on the impl site (Hibernate org).

It'd definitely be nice for this to be a BV effort, but for that I'd also
like to get some feedback and input from others on the EG. My thinking was
to keep that discussion for the 2.1 lifecycle, but if you like feel free to
reach out to the list and ask for feedback, we also can do it now if
there's some interest.

--Gunnar


2018-01-10 11:43 GMT+01:00 Guillaume Smet :

> Hi,
>
> So I did the move.
>
> And then I thought why not the beanvalidation organization?
>
> I didn't think of it before as I'm not sure this benchmark will stay
> totally HV agnostic but for now it is and it could probably stay this way.
> If we want some HV specific things, we can still add a specific benchmark
> module and keep the BV ones separated.
>
> It would be nice if it was considered a Bean Validation effort rather than
> as a purely HV one.
>
> But maybe it makes it too official to have it in the BV organization?
>
> WDYT?
>
> --
> Guillaume
>
> On Wed, Jan 10, 2018 at 9:33 AM, Gunnar Morling 
> wrote:
>
>> +1, good idea. Thanks!
>>
>> 2018-01-09 14:46 GMT+01:00 Guillaume Smet :
>>
>>> Hi,
>>>
>>> Now that we added some more value to the Bean Validation benchmark [1]
>>> (Marko converted them to JMH), I think it's time to move the repo to the
>>> Hibernate org.
>>>
>>> Anyone against it?
>>>
>>> FYI, it's Apache 2 licensed as it's derived from previous work from the
>>> Apache BVal people.
>>>
>>> [1] https://github.com/gsmet/beanvalidation-benchmark
>>>
>>> --
>>> Guillaume
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Davide D'Alto]

> Let's not forget that many Apache projects take a week or two to
> perform a release, we all know of other projects needing months, so by
> the law of diminishing returns I don't think we should invest much
> more of out time to shave on the 10 minutes.. just spin up some extra
> nodes :)

+1



On Wed, Jan 10, 2018 at 11:08 AM, Sanne Grinovero  wrote:
> On 10 January 2018 at 10:25, Guillaume Smet  wrote:
>> Hi,
>>
>> On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere  wrote:
>>>
>>> I hope we will be able to use this priority feature instead of the Heavy
>>> Job plugin (which allows to assign weights to jobs), and avoid concurrent
>>> builds completely. With the current setup, someone releasing his/her
>>> project will only have to wait for the currently executing build to finish,
>>> and will get the highest priority on the release builds. Maybe this is
>>> enough? If you disagree, please raise your concerns now: I will disable the
>>> Heavy Job plugin soon and set each slave to only offer one execution slot.
>
> Thanks Yoann! that sounds great.
>
>>>
>>
>> I'm not really convinced by this solution. Some jobs still take quite a lot
>> of time and having to wait 20 minutes for each job I would trigger is a bit
>> annoying.
>>
>> If it was for only one job, it would be acceptable, but let's take the
>> worst case of a coordinated HV release :
>> - TCK release
>> - API release
>> - HV release
>> - website
>> - blog
>>
>> I won't have to wait for each of them as some of them will be grouped by
>> the prioritization but I'm pretty sure I will have to wait for several of
>> them.
>>
>> So, I'm +1 on having this plugin as it seems to be helpful on its own but
>> I'm -1 on considering it is a solution to the "let's roll a release" thing.
>
> Some of our test suites used to take 2 hours to run (even 5 days some
> years ago); now you say waiting 20 minutes is not good enough? You'll
> have to optimise our code better :P
>
> It's very easy to spin up extra nodes; my recommendation is that when
> you know you're about to release [for example approximately one hour
> in advance while you might be double-checking JIRA state and such
> things] hit that manual scale-up button and have CI "warmed up" with
> one or two extra nodes.
>
> By the time you need to trigger the release job you'll have the build
> queue flushed, the priority plugin helping you out, and still
> additional extra slaves running to run it all in parallel.
>
> And of course for many releases we don't care for an extra 30 minutes
> so you're free to skip this all if it's not important; incidentally
> for "work in progress" milestones like the module packs which we
> recently re-released several times while polishing up the PR I've been
> releasing from my local machine; it's good to have CI automate things
> but I don't think we should get in a position to require 100%
> availability from CI: practice releases locally sometimes.
>
> If we really wanted to invest more in it (both time and budget),
> there's the option of spinning up new containers for each job as soon
> as you need one but I feel like we've spent too much time on CI
> already; such technology is maturing so my take is let it mature a bit
> more, and in 6 months we'll do another step of improvement; jumping on
> those things makes us otherwise the beta testers and steals critical
> time from our own projects.
> Let's not forget that many Apache projects take a week or two to
> perform a release, we all know of other projects needing months, so by
> the law of diminishing returns I don't think we should invest much
> more of out time to shave on the 10 minutes.. just spin up some extra
> nodes :)
>
> Thanks,
> Sanne
>
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Awestruct upgrade to version 0.5.7

[Davide D'Alto]

Just to clarify, The websites to check are:
http://staging.in.relation.to and http://staging.hibernate.org
Sorry, I forgot to add the links in the previous mail.


On Wed, Jan 10, 2018 at 11:08 AM, Davide D'Alto  wrote:
> Hello,
> I've upgraded awestruct to version 0.5.7.
>
> Except for the minification of our stylesheets it seems to work fine
> but It would be nice if someone else can have a look at generate site
> and confirm to me that's
> OK to apply the changes in production.
>
> On the same note, I've noticed that we are using some custom
> extensions to execute the minification, specifically the one in
> _ext/css_minifier.rb.
>
> Is there any reason to do that? I'm asking because Awestruct comes
> with its own minification class called: Awestruct::Extension::Minify
>
> The main difference I noticed is that this extension doesn't copy the
> original file during deploy on the server and only uses the minified
> one.
> Also currently, this extension doesn't work for CSS but I guess they
> are going to fix it in the next releases (it works for html and js).
>
> Cheers,
> Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Guillaume Smet]

On Wed, Jan 10, 2018 at 12:08 PM, Sanne Grinovero 
wrote:

> Some of our test suites used to take 2 hours to run (even 5 days some
> years ago); now you say waiting 20 minutes is not good enough? You'll
> have to optimise our code better :P
>

What I'm saying is that in the current setup, I don't wait at all when I
have something to release.

All is passed in parallel to the currently running jobs.

And it works well.


> It's very easy to spin up extra nodes; my recommendation is that when
> you know you're about to release [for example approximately one hour
> in advance while you might be double-checking JIRA state and such
> things] hit that manual scale-up button and have CI "warmed up" with
> one or two extra nodes.
>
> By the time you need to trigger the release job you'll have the build
> queue flushed, the priority plugin helping you out, and still
> additional extra slaves running to run it all in parallel.
>
> And of course for many releases we don't care for an extra 30 minutes
> so you're free to skip this all if it's not important; incidentally
> for "work in progress" milestones like the module packs which we
> recently re-released several times while polishing up the PR I've been
> releasing from my local machine; it's good to have CI automate things
> but I don't think we should get in a position to require 100%
> availability from CI: practice releases locally sometimes.
>

Well, the ultimate goal of releasing on CI is to have consistent releases
and an automated process.

I really don't want to build a release locally and be at risk of doing
something wrong.

That's the main purpose of an automated process and having a stable machine
doing it.


> Let's not forget that many Apache projects take a week or two to
> perform a release, we all know of other projects needing months, so by
> the law of diminishing returns I don't think we should invest much
> more of out time to shave on the 10 minutes.. just spin up some extra
> nodes :)
>

What I'm saying is that the current setup is working very well for releases
and the proposed setup won't work as well.

You can find all sorts of workarounds but it won't work as well and be as
practical as it used to be. Yeah, you can think of starting another node 1
hour before doing your release and hope it will still be there and you
won't have another project's commit triggering 4 jobs just before you
start. Sure. But I'm pretty sure it's going to be a pain.

I'm probably the one doing releases the most frequently with HV, that's why
I am vocal about it.

And maybe I'm the only one but, when I'm working on a release, I don't like
to do stuff in parallel because I don't want to forget something or make a
mistake. So I'm fully focused on it. Waiting 20 minutes before having my
job running will be a complete waste of time. And if it has to happen more
than one time on a given release time, I can predict I will get grumpy :).

That being said, if you have nothing against me cancelling the running jobs
because they are in the way, we can do that. But I'm not sure people will
like it very much.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Plans to release 5.2.13?

[Guillaume Smet]

Hi,

On Fri, Jan 5, 2018 at 4:24 PM, Steve Ebersole  wrote:

> Yep, I know how long it takes to do a release - I've been doing them for
> almost 15 years ;)
>
> I'm not sure if you are agreeing or disagreeing about blogging every
> bugfix release.  But anyway, Sanne asked what would help automate the
> release process, so I am listing things that would help.  Of course you can
> feel free to contribute blogging and emailing announcement plugins for
> Gradle for us to use in the automated release tasks ;)
>

AFAICS, lately, the ORM bugfix releases announcement is just a link to the
changelog. I don't think it would buy you a lot to automate it.

For the NoORM projects, the announcement part (Twitter, Mail, Blog) is
still manual. I don't think it's that bad.


> If you release something every month, it's not that bad if a bugfix slips
>> to the next release. If a PR is not completely ready, well, it's going to
>> be in the next one, no need to wait. It helps getting the release
>> coordination easier.
>>
>
> 5.2 just got lost in the cracks as Andrea, Chris and I were all working on
> 6.0.
>
>
> It's also easier to detect and fix regressions when you release more
>> frequently.
>>
>
> That's a fallacy.  Or at least its not true in isolation.  It depends on
> the things that would highlight the regression picking up that release and
> playing with it, since your entire premise here is that the regression is
> not tested as part of the test suite.  But that's actually not what happens
> today in terms of our inter-project integrations... really we find out many
> releases later when OGM or Search update to these newer ORM releases.
>

I did a quite a lot of regression hunt myself in $previousJob (mostly on
Search but a bit on ORM too), and it did help to upgrade often and when the
releases were not too big. Easier to find the commit causing the regression.

I don't know if there are a lot of companies doing that (I know mine
stopped to do that after I left) but it did really help to upgrade in
smaller steps.

That's what I was trying to explain.

FWIW, in the active community branches, I usually do the backport right
>> away - if I think the issue requires backporting, sometimes, it's just not
>> worth it or too risky. And I'm doing the "what should I backport?" thing
>> only on product only branches.
>>
>
>
> This right here is the crux - "active community branch".  By definition no
> branch is in active community development.  Again, we have discussed this
> as a team multiple times.  Once the next release is stable we stop
> developing the previous one, with a few caveats.  E.g.:
>
>- Once 5.3 is stable we do generally expect to do a *few* additional
>5.2 releases.  But let's be careful about the expectation about the phrase
>"few" here.  I really mean one or 2...
>- For major releases (5.x -> 6.x) we generally expect to do a larger
>number of releases of the 5.3 line.  Again though, not indefinite.
>
> The basic gist is that we are an open source community.  We simply do not
> have the resources to maintain infinite lines of development.  We need to
> focus on what is important.  I think we all agree that currently 5.2 is
> still important, but I think we may all have different expectations for
> what that means moving forward as 5.3 becomes the stable release.  I cannot
> give a concrete "we will only do X more 5.2 releases after 5.3 is stable"
> answer.  It might be 2.  It might be 3.  And it might be 1.
>

I think we agree on the principles. We just need to have a viable
definition of "stable" for the users.


> I'm not saying it would be that easy with ORM as the flow of issues is
>> significantly larger. Just stating how we do it.
>>
>
> Sure.  And time-boxed releases are what we normally strive for as well in
> ORM.  5.2 is largely an aberration in this regard.  Again - Andrea, Chris
> and I were focused on 6.0 work and since there is no 5.2 based Red Hat work
> this fell between the cracks
>

So I think we all agree that the situation with 5.2 is less than ideal.

And it's the version currently recommended for community usage. Which is a
large part of Hibernate usage.

Could we agree on releasing it regularly from now on and at least plan a
5.2.13 release soon to release all the fixes already in?

Thanks!

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Awestruct upgrade to version 0.5.7

[Guillaume Smet]

Thanks for taking care of that.

I clicked here and there, especially on the complex pages, and it looks
good to me.

Be careful when merging, we don't want the Corporate contributors page on
the public website yet.

Thanks!

-- 
Guillaume

On Wed, Jan 10, 2018 at 12:25 PM, Davide D'Alto 
wrote:

> Just to clarify, The websites to check are:
> http://staging.in.relation.to and http://staging.hibernate.org
> Sorry, I forgot to add the links in the previous mail.
>
>
> On Wed, Jan 10, 2018 at 11:08 AM, Davide D'Alto 
> wrote:
> > Hello,
> > I've upgraded awestruct to version 0.5.7.
> >
> > Except for the minification of our stylesheets it seems to work fine
> > but It would be nice if someone else can have a look at generate site
> > and confirm to me that's
> > OK to apply the changes in production.
> >
> > On the same note, I've noticed that we are using some custom
> > extensions to execute the minification, specifically the one in
> > _ext/css_minifier.rb.
> >
> > Is there any reason to do that? I'm asking because Awestruct comes
> > with its own minification class called: Awestruct::Extension::Minify
> >
> > The main difference I noticed is that this extension doesn't copy the
> > original file during deploy on the server and only uses the minified
> > one.
> > Also currently, this extension doesn't work for CSS but I guess they
> > are going to fix it in the next releases (it works for html and js).
> >
> > Cheers,
> > Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Awestruct upgrade to version 0.5.7

[Davide D'Alto]

Thanks,
I will only add the additional commits I made.



On Wed, Jan 10, 2018 at 11:45 AM, Guillaume Smet
 wrote:
> Thanks for taking care of that.
>
> I clicked here and there, especially on the complex pages, and it looks good
> to me.
>
> Be careful when merging, we don't want the Corporate contributors page on
> the public website yet.
>
> Thanks!
>
> --
> Guillaume
>
> On Wed, Jan 10, 2018 at 12:25 PM, Davide D'Alto 
> wrote:
>>
>> Just to clarify, The websites to check are:
>> http://staging.in.relation.to and http://staging.hibernate.org
>> Sorry, I forgot to add the links in the previous mail.
>>
>>
>> On Wed, Jan 10, 2018 at 11:08 AM, Davide D'Alto 
>> wrote:
>> > Hello,
>> > I've upgraded awestruct to version 0.5.7.
>> >
>> > Except for the minification of our stylesheets it seems to work fine
>> > but It would be nice if someone else can have a look at generate site
>> > and confirm to me that's
>> > OK to apply the changes in production.
>> >
>> > On the same note, I've noticed that we are using some custom
>> > extensions to execute the minification, specifically the one in
>> > _ext/css_minifier.rb.
>> >
>> > Is there any reason to do that? I'm asking because Awestruct comes
>> > with its own minification class called: Awestruct::Extension::Minify
>> >
>> > The main difference I noticed is that this extension doesn't copy the
>> > original file during deploy on the server and only uses the minified
>> > one.
>> > Also currently, this extension doesn't work for CSS but I guess they
>> > are going to fix it in the next releases (it works for html and js).
>> >
>> > Cheers,
>> > Davide
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Sanne Grinovero]

On 10 January 2018 at 11:33, Guillaume Smet  wrote:
> On Wed, Jan 10, 2018 at 12:08 PM, Sanne Grinovero 
> wrote:
>>
>> Some of our test suites used to take 2 hours to run (even 5 days some
>> years ago); now you say waiting 20 minutes is not good enough? You'll
>> have to optimise our code better :P
>
>
> What I'm saying is that in the current setup, I don't wait at all when I
> have something to release.
>
> All is passed in parallel to the currently running jobs.
>
> And it works well.

I'm confused now. AFAIK this has never been the case? I understand
that the release process itself runs without running the tests, but
I'd still run the tests by triggering a full build before.
You made the example of the TCK and various tests; to run them you'd
not be allowed to run them in parallel with other builds, so you
wanted to release and the jobs happened to be building ORM and all its
RDBMS, you'd have had to wait for a couple hours.

>
>>
>> It's very easy to spin up extra nodes; my recommendation is that when
>> you know you're about to release [for example approximately one hour
>> in advance while you might be double-checking JIRA state and such
>> things] hit that manual scale-up button and have CI "warmed up" with
>> one or two extra nodes.
>>
>> By the time you need to trigger the release job you'll have the build
>> queue flushed, the priority plugin helping you out, and still
>> additional extra slaves running to run it all in parallel.
>>
>> And of course for many releases we don't care for an extra 30 minutes
>> so you're free to skip this all if it's not important; incidentally
>> for "work in progress" milestones like the module packs which we
>> recently re-released several times while polishing up the PR I've been
>> releasing from my local machine; it's good to have CI automate things
>> but I don't think we should get in a position to require 100%
>> availability from CI: practice releases locally sometimes.
>
>
> Well, the ultimate goal of releasing on CI is to have consistent releases
> and an automated process.
>
> I really don't want to build a release locally and be at risk of doing
> something wrong.
>
> That's the main purpose of an automated process and having a stable machine
> doing it.
>
>>
>> Let's not forget that many Apache projects take a week or two to
>> perform a release, we all know of other projects needing months, so by
>> the law of diminishing returns I don't think we should invest much
>> more of out time to shave on the 10 minutes.. just spin up some extra
>> nodes :)
>
>
> What I'm saying is that the current setup is working very well for releases
> and the proposed setup won't work as well.
>
> You can find all sorts of workarounds but it won't work as well and be as
> practical as it used to be. Yeah, you can think of starting another node 1
> hour before doing your release and hope it will still be there and you won't
> have another project's commit triggering 4 jobs just before you start. Sure.
> But I'm pretty sure it's going to be a pain.

Still I don't really understand if you're having a better idea. In a
nutshell these jobs need resources, if they are busy you either add
more resources, or change priorities, or you wait. That's the three
aspects you can play with "safely".

Then there's the option of playing with parallelism, but it's really
dangerous: it risks failing both your release and causing failures in
the other tests which are hard to expliain, cause confusion among us
all, and ultimately lead to have to repeat all involved jobs so
consuming unnecessarily more resources and time.
In many cases parallelism isn't even an option, for examplethe ORM
builds consume most system memory so you just can't run additional
JVMs to run the TCK or similar jobs; if it was safe, I would be using
smaller machines.

> I'm probably the one doing releases the most frequently with HV, that's why
> I am vocal about it.
>
> And maybe I'm the only one but, when I'm working on a release, I don't like
> to do stuff in parallel because I don't want to forget something or make a
> mistake. So I'm fully focused on it. Waiting 20 minutes before having my job
> running will be a complete waste of time. And if it has to happen more than
> one time on a given release time, I can predict I will get grumpy :).
>
> That being said, if you have nothing against me cancelling the running jobs
> because they are in the way, we can do that. But I'm not sure people will
> like it very much.

Just make sure you ask for permissions, but yea we've done that
previously, hopefully won't be needed often, but it's always an
option.

>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Steve Ebersole]

And in advance I say I would not be cool with you killing my jobs for your
job to run

On Wed, Jan 10, 2018 at 9:52 AM Sanne Grinovero  wrote:

> On 10 January 2018 at 11:33, Guillaume Smet 
> wrote:
> > On Wed, Jan 10, 2018 at 12:08 PM, Sanne Grinovero 
> > wrote:
> >>
> >> Some of our test suites used to take 2 hours to run (even 5 days some
> >> years ago); now you say waiting 20 minutes is not good enough? You'll
> >> have to optimise our code better :P
> >
> >
> > What I'm saying is that in the current setup, I don't wait at all when I
> > have something to release.
> >
> > All is passed in parallel to the currently running jobs.
> >
> > And it works well.
>
> I'm confused now. AFAIK this has never been the case? I understand
> that the release process itself runs without running the tests, but
> I'd still run the tests by triggering a full build before.
> You made the example of the TCK and various tests; to run them you'd
> not be allowed to run them in parallel with other builds, so you
> wanted to release and the jobs happened to be building ORM and all its
> RDBMS, you'd have had to wait for a couple hours.
>
> >
> >>
> >> It's very easy to spin up extra nodes; my recommendation is that when
> >> you know you're about to release [for example approximately one hour
> >> in advance while you might be double-checking JIRA state and such
> >> things] hit that manual scale-up button and have CI "warmed up" with
> >> one or two extra nodes.
> >>
> >> By the time you need to trigger the release job you'll have the build
> >> queue flushed, the priority plugin helping you out, and still
> >> additional extra slaves running to run it all in parallel.
> >>
> >> And of course for many releases we don't care for an extra 30 minutes
> >> so you're free to skip this all if it's not important; incidentally
> >> for "work in progress" milestones like the module packs which we
> >> recently re-released several times while polishing up the PR I've been
> >> releasing from my local machine; it's good to have CI automate things
> >> but I don't think we should get in a position to require 100%
> >> availability from CI: practice releases locally sometimes.
> >
> >
> > Well, the ultimate goal of releasing on CI is to have consistent releases
> > and an automated process.
> >
> > I really don't want to build a release locally and be at risk of doing
> > something wrong.
> >
> > That's the main purpose of an automated process and having a stable
> machine
> > doing it.
> >
> >>
> >> Let's not forget that many Apache projects take a week or two to
> >> perform a release, we all know of other projects needing months, so by
> >> the law of diminishing returns I don't think we should invest much
> >> more of out time to shave on the 10 minutes.. just spin up some extra
> >> nodes :)
> >
> >
> > What I'm saying is that the current setup is working very well for
> releases
> > and the proposed setup won't work as well.
> >
> > You can find all sorts of workarounds but it won't work as well and be as
> > practical as it used to be. Yeah, you can think of starting another node
> 1
> > hour before doing your release and hope it will still be there and you
> won't
> > have another project's commit triggering 4 jobs just before you start.
> Sure.
> > But I'm pretty sure it's going to be a pain.
>
> Still I don't really understand if you're having a better idea. In a
> nutshell these jobs need resources, if they are busy you either add
> more resources, or change priorities, or you wait. That's the three
> aspects you can play with "safely".
>
> Then there's the option of playing with parallelism, but it's really
> dangerous: it risks failing both your release and causing failures in
> the other tests which are hard to expliain, cause confusion among us
> all, and ultimately lead to have to repeat all involved jobs so
> consuming unnecessarily more resources and time.
> In many cases parallelism isn't even an option, for examplethe ORM
> builds consume most system memory so you just can't run additional
> JVMs to run the TCK or similar jobs; if it was safe, I would be using
> smaller machines.
>
> > I'm probably the one doing releases the most frequently with HV, that's
> why
> > I am vocal about it.
> >
> > And maybe I'm the only one but, when I'm working on a release, I don't
> like
> > to do stuff in parallel because I don't want to forget something or make
> a
> > mistake. So I'm fully focused on it. Waiting 20 minutes before having my
> job
> > running will be a complete waste of time. And if it has to happen more
> than
> > one time on a given release time, I can predict I will get grumpy :).
> >
> > That being said, if you have nothing against me cancelling the running
> jobs
> > because they are in the way, we can do that. But I'm not sure people will
> > like it very much.
>
> Just make sure you ask for permissions, but yea we've done that
> previously, hopefully won't be needed often, but it's always an
> option.
>
> >
>

[hibernate-dev] Delay 5.3.0.Beta1 until next week

[Steve Ebersole]

I am going to delay 5.3.0.Beta1 until next week to investigate OSSRH
publishing.  I noticed yesterday that Bintray has a 10G storage limit which
we would hit too quickly.

Feel free to add issues to Beta1, but only if you plan on having them done
by next week (1/17).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Delay 5.3.0.Beta1 until next week

[Yoann Rodiere]

It would be nice to have
https://github.com/hibernate/hibernate-orm/pull/2092 in 5.3.0.Beta1, so
that we can start experimenting in Search :)
Just saw there's a conflict (again), I will rebase.

On Wed, 10 Jan 2018 at 17:14 Steve Ebersole  wrote:

> I am going to delay 5.3.0.Beta1 until next week to investigate OSSRH
> publishing.  I noticed yesterday that Bintray has a 10G storage limit which
> we would hit too quickly.
>
> Feel free to add issues to Beta1, but only if you plan on having them done
> by next week (1/17).
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Guillaume Smet]

On Wed, Jan 10, 2018 at 5:00 PM, Steve Ebersole  wrote:

> And in advance I say I would not be cool with you killing my jobs for your
> job to run
>

Yeah, that was my understanding.

I don't expect anyone to be cool with it.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Guillaume Smet]

On Wed, Jan 10, 2018 at 4:50 PM, Sanne Grinovero 
wrote:

> I'm confused now. AFAIK this has never been the case? I understand
> that the release process itself runs without running the tests, but
> I'd still run the tests by triggering a full build before.
> You made the example of the TCK and various tests; to run them you'd
> not be allowed to run them in parallel with other builds, so you
> wanted to release and the jobs happened to be building ORM and all its
> RDBMS, you'd have had to wait for a couple hours.
>

When I start my release process, all my test jobs are green. That's the
precondition.

I usually don't commit something in a haste just before the release.

When I start my release process, my release job has a weight of 2 so it
passes in parallel of the other jobs (be it ORM, Search, or even BV/HV, as
the release job pushes a commit so builds are triggered).

That's why I like this weight plugin.

And yes, this works because the release jobs don't run the tests so I'm
sure there's no conflict of resources with another job.


> Still I don't really understand if you're having a better idea. In a
> nutshell these jobs need resources, if they are busy you either add
> more resources, or change priorities, or you wait. That's the three
> aspects you can play with "safely".


As explained above, there's no conflict of resources in the case of the
current release jobs: they don't run tests.

That's why it works.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Delay 5.3.0.Beta1 until next week

[Steve Ebersole]

Yoann, yes, I will get that in.  Honestly it would have even been in the
one today - the Bintray concern was just very last minute that I felt it
best to hold off for the week.

On Wed, Jan 10, 2018 at 10:18 AM Yoann Rodiere  wrote:

> It would be nice to have
> https://github.com/hibernate/hibernate-orm/pull/2092 in 5.3.0.Beta1, so
> that we can start experimenting in Search :)
> Just saw there's a conflict (again), I will rebase.
>
> On Wed, 10 Jan 2018 at 17:14 Steve Ebersole  wrote:
>
>> I am going to delay 5.3.0.Beta1 until next week to investigate OSSRH
>> publishing.  I noticed yesterday that Bintray has a 10G storage limit
>> which
>> we would hit too quickly.
>>
>> Feel free to add issues to Beta1, but only if you plan on having them done
>> by next week (1/17).
>>
> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins job priorities

[Steve Ebersole]

I know ;)

Anyway I do agree that any release jobs should be given the highest
priority in the job queue

On Wed, Jan 10, 2018, 10:29 AM Guillaume Smet 
wrote:

> On Wed, Jan 10, 2018 at 5:00 PM, Steve Ebersole 
> wrote:
>
>> And in advance I say I would not be cool with you killing my jobs for
>> your job to run
>>
>
> Yeah, that was my understanding.
>
> I don't expect anyone to be cool with it.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Serializable SessionFactory

[Vlad Mihalcea]

Hi,

While reviewing old PRs we have in the ORM project, I stumbled on this one
about serializing the SessionFactory.

I created a new PR, rebased on top of the current master branch and all
tests are passing fine.

If anyone wants to take a look, this is the PR:

https://github.com/hibernate/hibernate-orm/pull/2107

I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there
are some unforeseen changes.

The only drawback is that, if we allow the SF to be Serializable, upgrading
will be much more difficult in case we change object structure.
We could make it clear that this might not be supported or use the
serialVersionUID to point to Hibernate version: major.minor.patch.

The main benefit is that, for a microservices architecture, Hibernate could
start much faster this way.

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Serializable SessionFactory

[Steve Ebersole]

The SessionFactory being Serialized outside the VM?  Because otherwise it
is already "serializable" via VM serialization hooks
and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
convinced we should support serializing it for "out of" VM use aside from
what we already do which assumes the new target VM has a similarly named
SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.

On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea 
wrote:

> Hi,
>
> While reviewing old PRs we have in the ORM project, I stumbled on this one
> about serializing the SessionFactory.
>
> I created a new PR, rebased on top of the current master branch and all
> tests are passing fine.
>
> If anyone wants to take a look, this is the PR:
>
> https://github.com/hibernate/hibernate-orm/pull/2107
>
> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there
> are some unforeseen changes.
>
> The only drawback is that, if we allow the SF to be Serializable, upgrading
> will be much more difficult in case we change object structure.
> We could make it clear that this might not be supported or use the
> serialVersionUID to point to Hibernate version: major.minor.patch.
>
> The main benefit is that, for a microservices architecture, Hibernate could
> start much faster this way.
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] proposition to create a new Constraint for @Age

[Gunnar Morling]

Hi Hilmer,

Welcome to the list and +1 to that constraint. I think it's a good idea
overall, will comment on the PR on some details as needed.

Cheers,

--Gunnar


2018-01-08 13:04 GMT+01:00 Guillaume Smet :

> Hi Hilmer,
>
> On Sat, Jan 6, 2018 at 9:10 PM, Hilmer Chona  wrote:
>
> > I have created a new issue on Jira  HV-1552 > atlassian.net/browse/HV-1552>, it is to add a new Constraint to check if
> > the number of years from a given date to today is igual or greater to a
> > specified value.
> >
> > This validation can be very useful when someone who wants to access, sign
> > up, or buy something must be over than one established age.
> >
> > What do you think?
> >
>
> Looks interesting. I think I would mimic what we do with Min/Max i.e. have
> AgeMin/AgeMax and an inclusive option.
>
> What I'm not sure about is if we should limit that to years. Or be more
> flexible and also support months/days for instance. But I'm not sure it's
> going to be easy (or useful?). Might be worth a try though.
>
> I would recommend doing an experiment with one date type before writing all
> the validators as it's going to be a bit tedious.
>
> I suppose you have seen Marko's post about how to contribute a constraint:
> http://in.relation.to/2018/01/04/adding-new-constraint-to-engine/ ?
>
> Have a nice day.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release Hibernate ORM 5.1.11.Final

[Gail Badner]

As $subject. Please don't push anything to 5.1 branch.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.1.11.Final Released

[Gail Badner]

http://in.relation.to/2018/01/10/hibernate-orm-5111-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev