Weekly meetings sounds.
I can also help with porting things to 6.
PS: Sorry if you have received 2 emails, I used the wrong address in
the first one.
On Fri, Dec 14, 2018 at 11:02 AM Davide D'Alto wrote:
>
> Weekly meeting sounds.
> I can also help with porting things to 6.
>
>
> On Fri, Dec 14,
Weekly meeting sounds.
I can also help with porting things to 6.
On Fri, Dec 14, 2018 at 8:27 AM andrea boriero wrote:
>
> Agree a meeting is a good idea especially when there are fixes that are not
> easily portable to 6, as pointed out by Steve I think/hope that most of the
> fixes will be eas
Agree a meeting is a good idea especially when there are fixes that are not
easily portable to 6, as pointed out by Steve I think/hope that most of the
fixes will be easily ported by simply cherry-picking them.
On Thu, 13 Dec 2018 at 17:56, Steve Ebersole wrote:
> I would not even put it on Gail
I would not even put it on Gail specifically per-se from the 5.x side.
Really we just need to be able to identify what fixes done on 5.x need to
be ported across to 6. And then, depending on the complexity, I would
expect some help from the person who implemented the fix in 5 porting that
change
Sorry for not replying earlier, got very busy on other things.
So, now that we agree, how do we do things? I think we should have a weekly
meeting at a fixed time to discuss master -> 6, probably either with Andrea
or Chris.
I could do it for a few months if it helps but in the end, I think it
sh
I completely agree with everything you say. A few thoughts in-line...
On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet
wrote:
> == What to do then
>
> There are a couple of options:
> 1/ no workaround, then we should consider it for 5.x
>
If it is fixed in 5 then it should be fixed in 6 as well
Gave it some thoughts while walking a bit.
Note: it's just my personal opinion so sharing as such.
IMHO, there are a couple of important things:
== Triaging
We need to keep triaging bugs that are created: this is *very* important
because otherwise it will just be a pile of issues added on top o
> Le 6 déc. 2018 à 16:03, Sanne Grinovero a écrit :
> It's 200,000 lines of code difference. Just don't make any change on 5
> - it's not a good use of our time either, since the future is 6.
Make 5.x a dead branch is not a good option.
Especially, since we don’t know when we will release 6.
Good points. I should have mentioned that.
At this point no new features, no improvements, no enhancements should be
done on 5. Just bug fixes.
And to be clear, I am actually fine with continuing to develop the bug
fixes on 5. The point was more about pushing something to 5 and then that
is it
On Thu, 6 Dec 2018 at 13:17, Guillaume Smet wrote:
>
> Hi Steve,
>
> I don't particularly like it.
>
> We have very few resources to work on 5.x and clearly we won't be able to
> do that + learn about 6 in parallel and fix issues in both, probably in 2
> completely different ways. And we won't rea
In my opinion we have to distinguish between the types of issues:
- improvements, I think they must be done only in 6.0 and backported
only if it is easy
- minor bugs or bugs with a workaround, I think they should be resolved
in 6.0 (in case the feature causing the issue is not yet imp
Also, keep in mind that's so far we've been merging from master to 6.0. In
other words, so far any changes you have made on master have automatically
been moved to 6. That will no longer be the case moving forward. Outside
of some specific action, things pushed to 5 will not be on 6.
On Thu, Dec
If you really "don't push that many things to 5.x", then no worries - it
does not really affect you. I suppose what you really mean is that when
you do contribute to 5 you do not want to "waste time" porting that to
6.0. Well the same is true on the flip side - while we are (very actively)
develo
I personally don't have a problem with that, since I don't contribute very
often, but I'd like to point out this moves most of the workload of merging
changes into 6 from Andrea/Chris to Gail/Guillaume.
Another problem being that the tests created/changed in 5.x may not work in
6 for completely dif
Hi Steve,
I don't particularly like it.
We have very few resources to work on 5.x and clearly we won't be able to
do that + learn about 6 in parallel and fix issues in both, probably in 2
completely different ways. And we won't really be able to know if it
doesn't work because it's not implemente
Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
discussion about managing the master and 6.0 branches in terms of
commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
to perform very painful "merging" from master to 6.0. As 6.0 was in a
pre-Alpha state
On 15 April 2016 at 17:10, Steve Ebersole wrote:
> That's not the intent. Users do deal with Session or StatelessSession.
> SharedSessionContract simply exists as a convenience for us to make sure
> Session and StatelessSession implement some of the same signatures.
Ok, I got it know. Sorry I ha
That's not the intent. Users do deal with Session or StatelessSession.
SharedSessionContract simply exists as a convenience for us to make sure
Session and StatelessSession implement some of the same signatures.
Now, if you are talking about the *Implementor forms those are the same as
any of the
Do you have a practical need for SharedSessionContract and
SharedSessionContractImplementor to exist within the internal
contracts of ORM?
As a general rule, I don't mind having implementations which implement
multiple interfaces.
Assuming you need these as a convenience for internal helpers, the
+1 SharedSessionContractImplementor <- (Session
Implementor & StatelessSessionImplementor)
On 15 April 2016 at 14:30, Steve Ebersole wrote:
> So here is what I ended up doing, with one questionable decision which I'll
> highlight below.
>
> First, the existing situation... We have Session and S
So here is what I ended up doing, with one questionable decision which I'll
highlight below.
First, the existing situation... We have Session and StatelessSession
which are largely independent contracts. There is a "shared" bit that is
represented by an interface SharedSessionContract. There is
2016-04-13 0:48 GMT+02:00 Steve Ebersole :
> Another question as I work through Query...
>
> Currently both Session and StatelessSession inherit the same query creation
> methods (returning org.hibernate.Query) via SharedSessionContract (which is
> the common base type between them). There is the
QueryProducer seems the way to go for me too.
On Wed, Apr 13, 2016 at 1:48 AM, Steve Ebersole wrote:
> Another question as I work through Query...
>
> Currently both Session and StatelessSession inherit the same query creation
> methods (returning org.hibernate.Query) via SharedSessionContract (
+1 for QueryProducer
On Tue, Apr 12, 2016 at 3:48 PM, Steve Ebersole wrote:
> Another question as I work through Query...
>
> Currently both Session and StatelessSession inherit the same query creation
> methods (returning org.hibernate.Query) via SharedSessionContract (which is
> the common bas
Another question as I work through Query...
Currently both Session and StatelessSession inherit the same query creation
methods (returning org.hibernate.Query) via SharedSessionContract (which is
the common base type between them). There is therefore an inherent
difficulty in having org.hibernate
Just a quick update on my progress. I pretty much have
Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as
well as bootstrapping.
I am currently working through the different Query hierarchies.
Looking at what is left, I hope to be done with all of this by Thursday
On Fr
On 8 April 2016 at 15:04, Scott Marlow wrote:
> I'm curious if Search/OGM master branches would likely align with 5.2?
> Or some other branch?
Good question, time for an update on these.
We'll certainly have a version of Search compatible, at some point.
Not sure though about which version that
I'm curious if Search/OGM master branches would likely align with 5.2?
Or some other branch?
On 04/07/2016 11:34 AM, Steve Ebersole wrote:
> As a follow up to this...
>
> Sanne had a great suggestion on HipChat. What about turning all this work
> (sans SQM, etc) into a 5.2 as an "end of line for
I am holding off on pushing to master until I hear otherwise.
On Thu, Apr 7, 2016 at 11:48 AM, Gail Badner wrote:
> +1
>
> On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero
> wrote:
>
>> +1
>> On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote:
>>
>> > +1 too.
>> >
>> >
>> >
>> > On Thu, Apr 7, 2016 at
+1
On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero wrote:
> +1
> On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote:
>
> > +1 too.
> >
> >
> >
> > On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford
> wrote:
> >
> > > +1 for 5.2
> > >
> > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole
> > > wrote:
> >
+1
On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote:
> +1 too.
>
>
>
> On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford wrote:
>
> > +1 for 5.2
> >
> > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole
> > wrote:
> >
> > > As a follow up to this...
> > >
> > > Sanne had a great suggestion on HipChat. Wh
+1 too.
On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford wrote:
> +1 for 5.2
>
> On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole
> wrote:
>
> > As a follow up to this...
> >
> > Sanne had a great suggestion on HipChat. What about turning all this
> work
> > (sans SQM, etc) into a 5.2 as an "en
+1 for 5.2
On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole wrote:
> As a follow up to this...
>
> Sanne had a great suggestion on HipChat. What about turning all this work
> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
> 5.2 would include:
>
>1. Move to Java 8
>
As a follow up to this...
Sanne had a great suggestion on HipChat. What about turning all this work
(sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
5.2 would include:
1. Move to Java 8
2. Consolidation of hibernate-entitymanager into hibernate-core
3. Deprecati
Hi,
Until the merge is done, I'll take a break integrating the PRs that are
also relevant to the master branch.
Vlad
On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole wrote:
> I agree that would be best. If everyone agrees to stop pushing to master
> for the time being to allow me to finish this
I agree that would be best. If everyone agrees to stop pushing to master
for the time being to allow me to finish this consolidation then I can not
rush it as much
On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote:
> I have to concur with Sanne, a hold on master pushes until this merge of
> a
I have to concur with Sanne, a hold on master pushes until this merge of
artifacts is complete makes the most sense from an all around logistics
perspective.
On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero wrote:
> Sounds reasonable. Do you think it will be unstable, i.e. should we
> temporarily
Sounds reasonable. Do you think it will be unstable, i.e. should we
temporarily disable complaint emails from Jenkins, or even the full
build tasks?
Also, this implies that any future backport becomes similarly harder,
so you could also simply ask others to hold pushing on master, then
have people
Obviously consolidating hibernate-entitymanager into hibernate-core is a
fairly big effort. And I am getting concerned about the continuing pushes
to master in the meantime, many of which I know touch on code I have
changed. My concern is obviously getting done all this refactoring work
and then
I'm in the process of releasing Hibernate Search 5.3.0.CR1.
This time, we won't wait for the Final release for branching to the
next development iteration: "master" is now version 5.4.0-SNAPSHOT and
you're all welcome to start proposing pull requests meant for 5.4.
Since 5.3.0.CR1 is a candidate
Interesting. If I disable schema (xml) validation, it works. Seems that
Envers is just not producing valid XML.
On Thu, Mar 12, 2015 at 8:35 PM, Steve Ebersole wrote:
> OK, so I ran into a speed bump with Envers. For those not familiar,
> Envers essentially iterates over all the entity mappin
OK, so I ran into a speed bump with Envers. For those not familiar, Envers
essentially iterates over all the entity mappings Hibernate has built for
user entities and dynamically builds a DOM(4J) Document representing the
audit entity corollaries. I had planned to simply bridge that to our JAXB
p
At first I read that as 34,601 files added and was like "wh!!" :)
On Wed, Mar 11, 2015 at 4:20 AM, Hardy Ferentschik
wrote:
> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> > Woohoo
>
> Woot!
>
> "1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)
You mean y'all? ;)
On Wed, Mar 11, 2015 at 9:39 AM, Gunnar Morling
wrote:
>
>
> 2015-03-11 10:20 GMT+01:00 Hardy Ferentschik :
>
>> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
>> > Woohoo
>>
>> Woot!
>>
>> "1,291 changed files with 34,601 additions and 220 deletions" - not
2015-03-11 10:20 GMT+01:00 Hardy Ferentschik :
> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> > Woohoo
>
> Woot!
>
> "1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)
>
My thoughts are with the poor soul who had to review that PR ;)
>
> --Hardy
>
On Wed, Mar 11, 2015 at 4:04 AM, Sanne Grinovero
wrote:
> On 11 March 2015 at 08:43, Emmanuel Bernard
> wrote:
> > Woohoo
>
> +1 Nice!
>
> The Envers module seems broken though?
>
> Sanne
>
> >
> > On Tue 2015-03-10 17:17, Steve Ebersole wrote:
> >> I wanted to given everyone a heads up that I j
On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> Woohoo
Woot!
"1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)
--Hardy
pgprUPt3Ud2Vb.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate
On 11 March 2015 at 08:43, Emmanuel Bernard wrote:
> Woohoo
+1 Nice!
The Envers module seems broken though?
Sanne
>
> On Tue 2015-03-10 17:17, Steve Ebersole wrote:
>> I wanted to given everyone a heads up that I just pushed the work I have
>> been doing up to master. It is alot. It covers m
Woohoo
On Tue 2015-03-10 17:17, Steve Ebersole wrote:
> I wanted to given everyone a heads up that I just pushed the work I have
> been doing up to master. It is alot. It covers most of what was planned
> as required for 5.0. The only outstanding item from that initial work is
> to integrate th
I wanted to given everyone a heads up that I just pushed the work I have
been doing up to master. It is alot. It covers most of what was planned
as required for 5.0. The only outstanding item from that initial work is
to integrate the changes into Envers, but I was still waiting to hear back
fro
-- I can give it another shot.
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> - Original Message -
> From: "Steve Ebersole"
> To: "hibernate-dev"
> Sent: Wednesday, December 4, 2013 1:39:39 PM
> Subject: [hibernate-dev] ma
conflicts when it's rebased
into master.
If there's now a need, let me know -- I can give it another shot.
Brett Meyer
Software Engineer
Red Hat, Hibernate ORM
- Original Message -
From: "Steve Ebersole"
To: "hibernate-dev"
Sent: Wednesday, December 4, 20
When is the last time we have synced merged master to the metamodel branch?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Thanks! fixed
On 3 March 2013 15:42, Steve Ebersole wrote:
> master branch is currently 4.3 which will be JPA 2.1 support. In JIra, this
> is indicated by the version jpa21 (I just have not updated the version name
> yet).
>
> metamodel branch is 5.0.
>
> On 03/02/2013 03:03 PM, Sanne Grinovero
master branch is currently 4.3 which will be JPA 2.1 support. In JIra,
this is indicated by the version jpa21 (I just have not updated the
version name yet).
metamodel branch is 5.0.
On 03/02/2013 03:03 PM, Sanne Grinovero wrote:
> Hi, sorry if this was discussed before.
>
> Having pushed an e
Hi, sorry if this was discussed before.
Having pushed an extremely minor change to master, is that to be
marked as 5.0 as far as JIRA is concerned?
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listin
Ok, starting then...
On Fri 07 Sep 2012 07:20:42 AM CDT, Steve Ebersole wrote:
> I want to merge master to metamodel again. Gail already asked me to
> wait until next week. So I will plan on holding off until Monday..
>
> Any concerns with doing it Monday?
>
--
st...@hibernate.org
http://hibern
I want to merge master to metamodel again. Gail already asked me to
wait until next week. So I will plan on holding off until Monday..
Any concerns with doing it Monday?
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibe
Yep, a schedule for syncing was never decided.
Thanks for investigating the specific here Hardy.
On Wed 13 Jun 2012 05:33:56 AM CDT, Hardy Ferentschik wrote:
>
> On Jun 13, 2012, at 9:43 AM, Strong Liu wrote:
>
>> are the master and metamodel supposed to be synced?
>
> Yes, but not automatically.
On Jun 13, 2012, at 9:43 AM, Strong Liu wrote:
> are the master and metamodel supposed to be synced?
Yes, but not automatically. The plan is to sync them regularly, but I don't
think we have determined yet how
often.
> I see there are some mismatch
>
> org.hibernate.internal.SessionFactoryI
are the master and metamodel supposed to be synced?
I see there are some mismatch
org.hibernate.internal.SessionFactoryImpl#determineCustomEntityDirtinessStrategy
org.hibernate.internal.SessionFactoryImpl#determineCurrentTenantIdentifierResolver
these two methods only exist in master, but not in
If I had to guess, some of the unit tests are expecting the h2 database
explicitly but are relying that the system properties are set up to
point to it rather than specifying those settings explicitly.
On Mon 11 Jun 2012 09:29:04 AM CDT, Steve Ebersole wrote:
> Not sure how else to "all tests" ;
Not sure how else to "all tests" ;)
On Mon 11 Jun 2012 09:14:28 AM CDT, Strong Liu wrote:
>
> On Jun 11, 2012, at 10:02 PM, Steve Ebersole wrote:
>
>> 1) `gradle test` runs all tests (there is just src/test now) against
>> default database (h2)
>>
>> 2) `gradle matrix_XYZ` essentially runs [gradle
On Jun 11, 2012, at 10:02 PM, Steve Ebersole wrote:
> 1) `gradle test` runs all tests (there is just src/test now) against default
> database (h2)
>
> 2) `gradle matrix_XYZ` essentially runs [gradle test] but against the XYZ
> "database profile"
so, for example, those metamodel unit tests are
1) `gradle test` runs all tests (there is just src/test now) against
default database (h2)
2) `gradle matrix_XYZ` essentially runs [gradle test] but against the
XYZ "database profile"
3) `gradle matrix` runs all all tests against all "database profiles".
It does not currently run against h2 I
On Jun 8, 2012, at 9:20 PM, Steve Ebersole wrote:
> I am done with consolidating src/matrix into src/test and merging master
> into metamodel. Everything seems to be working. Let me know if you see
> any issues.
>
> I did need to adjust the "matrix plugin" a little bit. We should talk
> ab
On Fri 08 Jun 2012 08:49:45 AM CDT, Hardy Ferentschik wrote:
> Nice. I checkout out the metamodel branch and all builds fine.
> You seem to have chosen the merge path for the integration. Is this what we
> are going to do in
> the future as well (merging instead of rebasing)?
Well that's what we
On Jun 8, 2012, at 3:20 PM, Steve Ebersole wrote:
> I am done with consolidating src/matrix into src/test and merging master
> into metamodel. Everything seems to be working. Let me know if you see
> any issues.
Nice. I checkout out the metamodel branch and all builds fine.
You seem to have
I am done with consolidating src/matrix into src/test and merging master
into metamodel. Everything seems to be working. Let me know if you see
any issues.
I did need to adjust the "matrix plugin" a little bit. We should talk
about testing as it relates to the database matric a little more a
On Jun 5, 2012, at 5:51 PM, John Verhaeg wrote:
>
> On Jun 5, 2012, at 10:27 AM, Steve Ebersole wrote:
>
>> Out of curiosity, why 2 merges?
>
> I was just thinking it might help reduce the number of potential conflicts
> during the first merge. If not, then one is fine in my mind.
Same here
On Jun 5, 2012, at 10:27 AM, Steve Ebersole wrote:
> Out of curiosity, why 2 merges?
I was just thinking it might help reduce the number of potential conflicts
during the first merge. If not, then one is fine in my mind.
___
hibernate-dev mailing l
If we merge (not rebase) then we should be fine to do it without
everyone having to push first. So lets set a time for this to happen.
I really want to hold off branching for JPA 2.1 implementation work
until this happens, so the sooner the better. Tomorrow (6/5)?
Out of curiosity, why 2 mer
+1 for early merges and Hardy's suggestion to merge first w/o combining test &
matrix, then again after combining.
On Jun 5, 2012, at 9:11 AM, Hardy Ferentschik wrote:
>
> On Jun 5, 2012, at 3:56 PM, Steve Ebersole wrote:
>
>> Would we merge the directories on each branch and then merge branch
On Jun 5, 2012, at 3:56 PM, Steve Ebersole wrote:
> Would we merge the directories on each branch and then merge branches? From
> what little I know of git I think this would be best.
What's about doing first a merge keeping test and matrix and then combining
test+matrix on master and do anot
Would we merge the directories on each branch and then merge branches?
>From what little I know of git I think this would be best.
On Jun 5, 2012 8:30 AM, "Hardy Ferentschik" wrote:
>
> On Jun 5, 2012, at 2:32 PM, Steve Ebersole wrote:
>
> > I want to start discussing a plan to integrate the mast
On Jun 5, 2012, at 2:32 PM, Steve Ebersole wrote:
> I want to start discussing a plan to integrate the master and metamodel
> branches together.
>
> One point of discussion is whether we want to pull master over on to
> metamodel on a regular basis or whether we want to just wait until the
>
I want to start discussing a plan to integrate the master and metamodel
branches together.
One point of discussion is whether we want to pull master over on to
metamodel on a regular basis or whether we want to just wait until the
"very end" and do a single painful integration. I did some sear
I do not understand this desire to deploy javadoc jars at all. The
source code is there, what does the javadoc add?
On 06/22/2011 04:29 AM, Strong Liu wrote:
> yeah, i made that change since there are users ask we deploy javadoc jar, but
> don't know why test depends on javadoc task
> feel
yeah, i made that change since there are users ask we deploy javadoc jar, but
don't know why test depends on javadoc task
feel free to remove/comment off it
---
Strong Liu
http://hibernate.org
http://github.com/stliu
On Jun 22, 2011, at 2:12 PM, Hardy Ferentschik wrote:
> No idea,
No idea, I wanted to ask the same question.
I modified the build file last, but was just updating the HV version.
Looking at the history I see that Strong did some changes related to
javadocs (fc90bc3a8af3db8c8aa09dd0b2879c883d557e7e)
The message says "deploy javadoc jar". My guess is that this c
Anyone know why I get javadocs being generated now whenever I run
`gradle test` ? Did anyone change up task deps?
--
Steve Ebersole
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/lis
81 matches
Mail list logo
