From guillaume.smet at gmail.com Tue Dec 4 09:22:36 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Dec 2018 15:22:36 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of today's meeting: 15:20 < jbott> Meeting ended Tue Dec 4 14:20:52 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:20 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-12-04-14.00.html 15:20 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-12-04-14.00.txt 15:20 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-12-04-14.00.log.html Have a nice day. -- Guillaume From yoann at hibernate.org Wed Dec 5 02:59:40 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 5 Dec 2018 08:59:40 +0100 Subject: [hibernate-dev] Hibernate Search 5.11.0.CR1 released Message-ID: Hello, We just published 5.11.0.CR1, the first candidate release for the 5.11 branch. This release mainly includes an upgrade to Hibernate ORM 5.4.0.CR2. If you want to test it, now is the time! More info: http://in.relation.to/2018/12/05/hibernate-search-5-11-0-CR1/ Cheers, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From steve at hibernate.org Wed Dec 5 08:42:45 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 07:42:45 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep Message-ID: As I am preparing the Alpha1 release a few topics of discussion have come up... Previously (last year's f2f) we had decided to unify the artifact naming conventions; specifically for ORM this meant renaming the groupId from `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if everyone still agrees with this. There are a few artifacts we need to decide how to handle: - `hibernate-entitymanager` and `hibernate-java8` have been part of `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` happened way earlier, but seems like not). Should we drop these? They have been defined as relocations for quite some time now). - `hibernate-ehcache` defines support for using Ehcache 2 as a second-level cache, which is a version the Ehcache team does not even support anymore and have not for quite a few years. Ehcache 3 is a JCache compliant version and the way that the Ehcache team prefer to handle the integration (in fact they wrote most of `hibernate-jcache`). IMO this should be removed as well. Thoughts? - `hibernate-infinispan` - support for using Infinispan as a Hibernate L2C has been moved to the Infinispan project. Again, IMO this module should go away. Thoughts? Andrea, Chris.. anything you can think of that I missed? From christian.beikov at gmail.com Wed Dec 5 08:49:55 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 5 Dec 2018 14:49:55 +0100 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Am 05.12.2018 um 14:42 schrieb Steve Ebersole: > As I am preparing the Alpha1 release a few topics of discussion have come > up... > > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > everyone still agrees with this. +1 > There are a few artifacts we need to decide how to handle: > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). +1 for dropping the relocation artifacts > - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a JCache > compliant version and the way that the Ehcache team prefer to handle the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? Sounds reasonable. > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module should > go away. Thoughts? +1 as well > Andrea, Chris.. anything you can think of that I missed? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Dec 5 08:54:33 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 07:54:33 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: One other artifact note... `hibernate-envers` has been merged into `hibernate-core` as of 6. Should we just drop this one since this is a new major release? Or do the relocation for a few? On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole wrote: > As I am preparing the Alpha1 release a few topics of discussion have come > up... > > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > everyone still agrees with this. > > There are a few artifacts we need to decide how to handle: > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). > - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a JCache > compliant version and the way that the Ehcache team prefer to handle the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module should > go away. Thoughts? > > > Andrea, Chris.. anything you can think of that I missed? > > From steve at hibernate.org Wed Dec 5 09:20:41 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 08:20:41 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Another one.. `hibernate-orm-modules` defines a `hibernate-envers` module (in the WF modules sense). Since envers is now part of `hibernate-core` should we remove that module or have it just act as an alias for the main orm module? On Wed, Dec 5, 2018 at 7:54 AM Steve Ebersole wrote: > One other artifact note... > > `hibernate-envers` has been merged into `hibernate-core` as of 6. Should > we just drop this one since this is a new major release? Or do the > relocation for a few? > > On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole wrote: > >> As I am preparing the Alpha1 release a few topics of discussion have come >> up... >> >> Previously (last year's f2f) we had decided to unify the artifact naming >> conventions; specifically for ORM this meant renaming the groupId from >> `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if >> everyone still agrees with this. >> >> There are a few artifacts we need to decide how to handle: >> >> - `hibernate-entitymanager` and `hibernate-java8` have been part of >> `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` >> happened way earlier, but seems like not). Should we drop these? They >> have been defined as relocations for quite some time now). >> - `hibernate-ehcache` defines support for using Ehcache 2 as a >> second-level cache, which is a version the Ehcache team does not even >> support anymore and have not for quite a few years. Ehcache 3 is a JCache >> compliant version and the way that the Ehcache team prefer to handle the >> integration (in fact they wrote most of `hibernate-jcache`). IMO this >> should be removed as well. Thoughts? >> - `hibernate-infinispan` - support for using Infinispan as a >> Hibernate L2C has been moved to the Infinispan project. Again, IMO this >> module should go away. Thoughts? >> >> >> Andrea, Chris.. anything you can think of that I missed? >> >> From christian.beikov at gmail.com Wed Dec 5 09:31:24 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 5 Dec 2018 15:31:24 +0100 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: <7fe75616-470e-7037-05e0-0625c2da4240@gmail.com> Am 05.12.2018 um 15:20 schrieb Steve Ebersole: > Another one.. > > `hibernate-orm-modules` defines a `hibernate-envers` module (in the WF > modules sense). Since envers is now part of `hibernate-core` should we > remove that module or have it just act as an alias for the main orm module? IMO a major version like 6 is a good opportunity to do things like removing obsolete modules. > > > On Wed, Dec 5, 2018 at 7:54 AM Steve Ebersole wrote: > >> One other artifact note... >> >> `hibernate-envers` has been merged into `hibernate-core` as of 6. Should >> we just drop this one since this is a new major release? Or do the >> relocation for a few? >> >> On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole wrote: >> >>> As I am preparing the Alpha1 release a few topics of discussion have come >>> up... >>> >>> Previously (last year's f2f) we had decided to unify the artifact naming >>> conventions; specifically for ORM this meant renaming the groupId from >>> `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if >>> everyone still agrees with this. >>> >>> There are a few artifacts we need to decide how to handle: >>> >>> - `hibernate-entitymanager` and `hibernate-java8` have been part of >>> `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` >>> happened way earlier, but seems like not). Should we drop these? They >>> have been defined as relocations for quite some time now). >>> - `hibernate-ehcache` defines support for using Ehcache 2 as a >>> second-level cache, which is a version the Ehcache team does not even >>> support anymore and have not for quite a few years. Ehcache 3 is a JCache >>> compliant version and the way that the Ehcache team prefer to handle the >>> integration (in fact they wrote most of `hibernate-jcache`). IMO this >>> should be removed as well. Thoughts? >>> - `hibernate-infinispan` - support for using Infinispan as a >>> Hibernate L2C has been moved to the Infinispan project. Again, IMO this >>> module should go away. Thoughts? >>> >>> >>> Andrea, Chris.. anything you can think of that I missed? >>> >>> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Wed Dec 5 09:42:19 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 5 Dec 2018 16:42:19 +0200 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Hi, I also agree with Christian. For the `hibernate-entitymanager`, the problem came from Spring as they wanted to support multiple versions of Hibernate. I wrote them on Twitter about this change so that they can adjust their framework to accommodate it. Vlad On Wed, Dec 5, 2018 at 3:53 PM Christian Beikov wrote: > Am 05.12.2018 um 14:42 schrieb Steve Ebersole: > > As I am preparing the Alpha1 release a few topics of discussion have come > > up... > > > > Previously (last year's f2f) we had decided to unify the artifact naming > > conventions; specifically for ORM this meant renaming the groupId from > > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see > if > > everyone still agrees with this. > +1 > > There are a few artifacts we need to decide how to handle: > > > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > > `hibernate-core` since 5.2 (I thought moving > `hibernate-entitymanager` > > happened way earlier, but seems like not). Should we drop these? > They > > have been defined as relocations for quite some time now). > +1 for dropping the relocation artifacts > > - `hibernate-ehcache` defines support for using Ehcache 2 as a > > second-level cache, which is a version the Ehcache team does not even > > support anymore and have not for quite a few years. Ehcache 3 is a > JCache > > compliant version and the way that the Ehcache team prefer to handle > the > > integration (in fact they wrote most of `hibernate-jcache`). IMO > this > > should be removed as well. Thoughts? > Sounds reasonable. > > - `hibernate-infinispan` - support for using Infinispan as a > Hibernate > > L2C has been moved to the Infinispan project. Again, IMO this module > should > > go away. Thoughts? > +1 as well > > Andrea, Chris.. anything you can think of that I missed? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Dec 5 09:55:26 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 08:55:26 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Do you guys feel the same way about `hibernate-envers`? Or should we relocate that for a few? On Wed, Dec 5, 2018 at 8:51 AM Vlad Mihalcea wrote: > Hi, > > I also agree with Christian. For the `hibernate-entitymanager`, the problem > came from Spring as they wanted to support multiple versions of Hibernate. > > I wrote them on Twitter about this change so that they can adjust their > framework to accommodate it. > > Vlad > > On Wed, Dec 5, 2018 at 3:53 PM Christian Beikov < > christian.beikov at gmail.com> > wrote: > > > Am 05.12.2018 um 14:42 schrieb Steve Ebersole: > > > As I am preparing the Alpha1 release a few topics of discussion have > come > > > up... > > > > > > Previously (last year's f2f) we had decided to unify the artifact > naming > > > conventions; specifically for ORM this meant renaming the groupId from > > > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see > > if > > > everyone still agrees with this. > > +1 > > > There are a few artifacts we need to decide how to handle: > > > > > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > > > `hibernate-core` since 5.2 (I thought moving > > `hibernate-entitymanager` > > > happened way earlier, but seems like not). Should we drop these? > > They > > > have been defined as relocations for quite some time now). > > +1 for dropping the relocation artifacts > > > - `hibernate-ehcache` defines support for using Ehcache 2 as a > > > second-level cache, which is a version the Ehcache team does not > even > > > support anymore and have not for quite a few years. Ehcache 3 is a > > JCache > > > compliant version and the way that the Ehcache team prefer to > handle > > the > > > integration (in fact they wrote most of `hibernate-jcache`). IMO > > this > > > should be removed as well. Thoughts? > > Sounds reasonable. > > > - `hibernate-infinispan` - support for using Infinispan as a > > Hibernate > > > L2C has been moved to the Infinispan project. Again, IMO this > module > > should > > > go away. Thoughts? > > +1 as well > > > Andrea, Chris.. anything you can think of that I missed? > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Dec 5 10:27:25 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 5 Dec 2018 16:27:25 +0100 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Hi, On Wed, Dec 5, 2018 at 2:47 PM Steve Ebersole wrote: > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > everyone still agrees with this. > Yes. We have renamed Validator and Search for their respective 6 already. > There are a few artifacts we need to decide how to handle: > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). > So it's a detail but it's pretty handy to have relocations for these artifacts in the case of our test case template as we can test various versions without changing anything. If it's not a nightmare, I would keep them. > - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a > JCache > compliant version and the way that the Ehcache team prefer to handle the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? > Last release was 2.10.6 of October 2018. So it's still alive. I know we have users still using it. If JCache covers all the features we had before, we could remove it and see how people reacts to it. It would still be time to reinject it later if someone comes up with a very compelling use case. And be done with it, if not. > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module > should > go away. Thoughts? > No opinion here. -- Guillaume From sanne at hibernate.org Wed Dec 5 10:36:51 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 5 Dec 2018 15:36:51 +0000 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018 at 13:56, Steve Ebersole wrote: > > As I am preparing the Alpha1 release a few topics of discussion have come > up... > > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > everyone still agrees with this. +1 > There are a few artifacts we need to decide how to handle: > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). +1, relocations need to be cleaned up eventually and this is a good time. > - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a JCache > compliant version and the way that the Ehcache team prefer to handle the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? +1 > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module should > go away. Thoughts? About this one, and the `hibernate-envers` you mentioned in previous email, it would be nice to help people a little more. Especially Envers's integration as it just happened. I wouldn't make it a release requirement though; I propose to not get distracted by such details at this stage - we can always add a truckload of such metadata later according to feedback - even beyond a 0.Final Similarly the WildFly modules I contributed just recently :-/ .. feel free to remove those, we'll see to re-introduce support as needed, and IF needed. I'd propose to ignore OSGi headers as well - not sure of the consequences though, so let's keep it IF it's not too much of a burden. We can re-introduce support and tests in a later feature release. Thanks, Sanne > > > Andrea, Chris.. anything you can think of that I missed? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Dec 5 10:47:41 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 09:47:41 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 9:28 AM Guillaume Smet wrote: There are a few artifacts we need to decide how to handle: >> >> - `hibernate-entitymanager` and `hibernate-java8` have been part of > > >> `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` >> happened way earlier, but seems like not). Should we drop these? They >> have been defined as relocations for quite some time now). >> > > So it's a detail but it's pretty handy to have relocations for these > artifacts in the case of our test case template as we can test various > versions without changing anything. > > If it's not a nightmare, I would keep them. > Define nightmare ;) As for "test case templates", that is code we write/control - so not understanding that point. In many ways it is the same discussion as how to handle deprecations. Some believe you should never remove deprecations using essentially the same exact logic you used here. > > >> - `hibernate-ehcache` defines support for using Ehcache 2 as a > > >> second-level cache, which is a version the Ehcache team does not even >> support anymore and have not for quite a few years. Ehcache 3 is a >> JCache >> compliant version and the way that the Ehcache team prefer to handle >> the >> integration (in fact they wrote most of `hibernate-jcache`). IMO this >> should be removed as well. Thoughts? >> > > Last release was 2.10.6 of October 2018. So it's still alive. I know we > have users still using it. > > If JCache covers all the features we had before, we could remove it and > see how people reacts to it. It would still be time to reinject it later if > someone comes up with a very compelling use case. > > And be done with it, if not. > Not sure what to tell you about a new release aside from saying that we often continue to release very old versions of ORM even though we do not support them. The existence of a release does not mean it is supported. I have been told by the Ehcache developers that version 2 has not been supported for many years (and that was almost a year ago). Interpret that how you want I guess. As for users still using it, that is a documentation issue imo. I had discussed this with Vlad previously that we ought to prefer hibernate-jcache + ehcache 3 in the documentation, but it looks like that has not happened. Vlad? > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > > >> L2C has been moved to the Infinispan project. Again, IMO this module >> should >> go away. Thoughts? >> > > No opinion here. > I am curious. Why is this different to you compared to hibernate-ehcache. To me it is the same exact situation. From steve at hibernate.org Wed Dec 5 11:03:05 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 10:03:05 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: Comments inline. However, a general point - the argument about "seamless" support for people upgrading is a bit misguided here I think. The argument is that someone can just change the version and everything will work as before. But we know that is not the case. They will also have to change the groupId. So its already a requirement for users to go back and change their dependencies in a non-trivial way... On Wed, Dec 5, 2018 at 9:37 AM Sanne Grinovero wrote: > > > - `hibernate-infinispan` - support for using Infinispan as a Hibernate > > L2C has been moved to the Infinispan project. Again, IMO this module > should > > go away. Thoughts? > > About this one, and the `hibernate-envers` you mentioned in previous > email, it would be nice to help people a little more. Especially > Envers's integration as it just happened. > We already deprecated hibernate-infinispan as of 5.2 or 5.3. Cannot remember atm if we did an actual relocation though. But it is definitely a valid point about envers. What we had planned was to keep the hibernate-envers *artifact* as an "empty" jar and add a relocation though I am not sure Maven likes pom with a relocation that also has a jar... However, I do think we should remove envers as (1) an karaf feature (hibernate-osgi) and as a WF module (hibernate-orm-modules). I wouldn't make it a release requirement though; I propose to not get > distracted by such details at this stage - we can always add a > truckload of such metadata later according to feedback - even beyond a > 0.Final > Not a "requirement". Let's say a VERY-nice-to-have. The more of these container integrations we can enable, the wider our potential pool of early adopters... > Similarly the WildFly modules I contributed just recently :-/ .. feel > free to remove those, we'll see to re-introduce support as needed, and > IF needed. > > I'd propose to ignore OSGi headers as well - not sure of the > consequences though, so let's keep it IF it's not too much of a > burden. We can re-introduce support and tests in a later feature > release. > The OSGi headers (assuming you mean the headers added to the jar manifests) are trivial and I am not sure why you think those would be a problem. More likely, you probably mean hibernate-osgi which to me fits into the "container integration" discusasion above. From guillaume.smet at gmail.com Wed Dec 5 11:03:40 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 5 Dec 2018 17:03:40 +0100 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 4:47 PM Steve Ebersole wrote: > On Wed, Dec 5, 2018 at 9:28 AM Guillaume Smet > wrote: > >> So it's a detail but it's pretty handy to have relocations for these >> artifacts in the case of our test case template as we can test various >> versions without changing anything. >> >> If it's not a nightmare, I would keep them. >> > > Define nightmare ;) > > As for "test case templates", that is code we write/control - so not > understanding that point. > When someone uses our test case template, I often check if the issue also applies to previous versions. Often helps to narrow down the issue. If artifacts are consistent across versions, it's easier. It's convenient, not required. > Last release was 2.10.6 of October 2018. So it's still alive. I know we >> have users still using it. >> > >> If JCache covers all the features we had before, we could remove it and >> see how people reacts to it. It would still be time to reinject it later if >> someone comes up with a very compelling use case. >> >> And be done with it, if not. >> > > Not sure what to tell you about a new release aside from saying that we > often continue to release very old versions of ORM even though we do not > support them. The existence of a release does not mean it is supported. I > have been told by the Ehcache developers that version 2 has not been > supported for many years (and that was almost a year ago). Interpret that > how you want I guess. > > As for users still using it, that is a documentation issue imo. I had > discussed this with Vlad previously that we ought to prefer > hibernate-jcache + ehcache 3 in the documentation, but it looks like that > has not happened. Vlad? > Let's agree to agree on this one and remove it :). > > >> - `hibernate-infinispan` - support for using Infinispan as a Hibernate >> >> >>> L2C has been moved to the Infinispan project. Again, IMO this module >>> should >>> go away. Thoughts? >>> >> >> No opinion here. >> > > I am curious. Why is this different to you compared to > hibernate-ehcache. To me it is the same exact situation. > It's mostly the "If JCache covers all the features we had before" I mentioned above that makes the difference. For Infinispan, we decided JCache was good enough. As for Ehcache, I'm wondering it all the features are exposed. The other thing is that I don't really know when the Infinispan code has been moved so I don't know if it's too early to remove it without relocation or not. So, no opinion :). -- Guillaume From steve at hibernate.org Wed Dec 5 16:09:04 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Dec 2018 15:09:04 -0600 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: At this point I feel comfortable that everything is good to go for Alpha1. I've done a few dry runs using just publish and it looks good. I have not yet tried the full set of release tasks. I am having trouble getting the staging hibernate.org build to work[1]. So I won't be able to publish the website updates. I have not yet started with the release announcement. But its probably better to come back to these tasks after and just do the release and finish up these tasks after. Any objections? Note that this also includes relocations for all published 6.0 artifacts under their old org.hibernate group-id [1] http://ci.hibernate.org/view/Website/job/staging.hibernate.org/808 On Wed, Dec 5, 2018 at 10:04 AM Guillaume Smet wrote: > On Wed, Dec 5, 2018 at 4:47 PM Steve Ebersole wrote: > >> On Wed, Dec 5, 2018 at 9:28 AM Guillaume Smet >> wrote: >> >>> So it's a detail but it's pretty handy to have relocations for these >>> artifacts in the case of our test case template as we can test various >>> versions without changing anything. >>> >>> If it's not a nightmare, I would keep them. >>> >> >> Define nightmare ;) >> >> As for "test case templates", that is code we write/control - so not >> understanding that point. >> > > When someone uses our test case template, I often check if the issue also > applies to previous versions. Often helps to narrow down the issue. > > If artifacts are consistent across versions, it's easier. > > It's convenient, not required. > > >> Last release was 2.10.6 of October 2018. So it's still alive. I know we >>> have users still using it. >>> >> >>> If JCache covers all the features we had before, we could remove it and >>> see how people reacts to it. It would still be time to reinject it later if >>> someone comes up with a very compelling use case. >>> >>> And be done with it, if not. >>> >> >> Not sure what to tell you about a new release aside from saying that we >> often continue to release very old versions of ORM even though we do not >> support them. The existence of a release does not mean it is supported. I >> have been told by the Ehcache developers that version 2 has not been >> supported for many years (and that was almost a year ago). Interpret that >> how you want I guess. >> >> As for users still using it, that is a documentation issue imo. I had >> discussed this with Vlad previously that we ought to prefer >> hibernate-jcache + ehcache 3 in the documentation, but it looks like that >> has not happened. Vlad? >> > > Let's agree to agree on this one and remove it :). > > >> >> >>> - `hibernate-infinispan` - support for using Infinispan as a Hibernate >>> >>> >>>> L2C has been moved to the Infinispan project. Again, IMO this module >>>> should >>>> go away. Thoughts? >>>> >>> >>> No opinion here. >>> >> >> I am curious. Why is this different to you compared to >> hibernate-ehcache. To me it is the same exact situation. >> > > It's mostly the "If JCache covers all the features we had before" I > mentioned above that makes the difference. For Infinispan, we decided > JCache was good enough. As for Ehcache, I'm wondering it all the features > are exposed. > > The other thing is that I don't really know when the Infinispan code has > been moved so I don't know if it's too early to remove it without > relocation or not. > > So, no opinion :). > > -- > Guillaume > From sanne at hibernate.org Wed Dec 5 16:49:03 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 5 Dec 2018 21:49:03 +0000 Subject: [hibernate-dev] 6.0 Alpha1 prep In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018 at 20:10, Steve Ebersole wrote: > > Another one.. > > `hibernate-orm-modules` defines a `hibernate-envers` module (in the WF > modules sense). Since envers is now part of `hibernate-core` should we > remove that module or have it just act as an alias for the main orm module? Removal is fine. The `hibernate-envers` dedicated module was just new, it never made it in any WF release. Also, when it comes to WF modules, the WF team can easily add additional backwards compatibility aliases - that's in their control. > > > On Wed, Dec 5, 2018 at 7:54 AM Steve Ebersole wrote: > > > One other artifact note... > > > > `hibernate-envers` has been merged into `hibernate-core` as of 6. Should > > we just drop this one since this is a new major release? Or do the > > relocation for a few? > > > > On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole wrote: > > > >> As I am preparing the Alpha1 release a few topics of discussion have come > >> up... > >> > >> Previously (last year's f2f) we had decided to unify the artifact naming > >> conventions; specifically for ORM this meant renaming the groupId from > >> `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > >> everyone still agrees with this. > >> > >> There are a few artifacts we need to decide how to handle: > >> > >> - `hibernate-entitymanager` and `hibernate-java8` have been part of > >> `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > >> happened way earlier, but seems like not). Should we drop these? They > >> have been defined as relocations for quite some time now). > >> - `hibernate-ehcache` defines support for using Ehcache 2 as a > >> second-level cache, which is a version the Ehcache team does not even > >> support anymore and have not for quite a few years. Ehcache 3 is a JCache > >> compliant version and the way that the Ehcache team prefer to handle the > >> integration (in fact they wrote most of `hibernate-jcache`). IMO this > >> should be removed as well. Thoughts? > >> - `hibernate-infinispan` - support for using Infinispan as a > >> Hibernate L2C has been moved to the Infinispan project. Again, IMO this > >> module should go away. Thoughts? > >> > >> > >> Andrea, Chris.. anything you can think of that I missed? > >> > >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Thu Dec 6 02:52:15 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 6 Dec 2018 08:52:15 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: The WildFly team is moving from Slack to Zulip, because Zulip seems to be the only solution that is free, provides unlimited history, and allows unlimited users even in private rooms (for OSS projects, at least). Gitter has all that, except unlimited users, as we are limited to 25 people per private room. You can join them here: https://wildfly.zulipchat.com/ Back to our solution... We are now 71 days away from the decommissioning of HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to keep looking for another solution? For my part, I noticed problems with the web client, in particular with notifications, which are sub-standard, but with the desktop client everything seems to work fine. It's simple, but it does the job. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere wrote: > On top of not being able to add more than 25 people to a private room, > there's another limitation of Gitter that Fabio just noticed: the chat > history for 1-to-1 conversations is very limited. In our case, we can only > see 2 days back, and there's no concept of archives like there is in rooms. > > Meanwhile, the WildFly team is giving up on Slack because of the very > limited size of history in free plans. They are investigating Zulip, > RocketChat and MatterMost in particular. Maybe let's see what they end up > choosing and why? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere wrote: > >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere wrote: >> >>> > Assuming the new chat platform takes off, there's a risk it might be >>> too successful as well >>> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think forcing >>> people to have a GitHub account will be very effective, but I can't suggest >>> a perfect solution either. Bots answering with a few links (documentation, >>> etc.) to the first message of each user come to mind, but that could be >>> considered rude, so I wouldn't do that unless the traffic becomes >>> unmanageable. Other solutions include kicking out "spammers" (but that >>> doesn't work if it's many users asking a single question), or making the >>> -dev rooms invite-only and only checking the user rooms once in a while >>> (might work if Gitter sends emails when your are mentioned while offline). >>> So, yeah, in short: I don't really know. >>> >>> > More just accountability. But if some form of login in needed to use >>> Gitter, that's enough for me. Sounded like the other option was "allow >>> anonymous", which I wanted to avoid. >>> >>> Then it should be fine: anonymous access apparently only allows to read >>> messages. Login through GitLab, GitHub or Twitter is necessary in order to >>> start posting new messages. >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole >>> wrote: >>> >>>> For me its not so much about "the right kind of people". More just >>>> accountability. But if some form of login in needed to use Gitter, that's >>>> enough for me. Sounded like the other option was "allow anonymous", which >>>> I wanted to avoid. >>>> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero >>>> wrote: >>>> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere >>>>> wrote: >>>>> > >>>>> > I don't see why we should force people to have a GitHub account, >>>>> considering there are other means of logging into Gitter. >>>>> >>>>> Ok. >>>>> >>>>> > >>>>> > As to getting the right type of people, I'm not sure it's relevant. >>>>> Most people are likely to have one, and those who don't are likely to not >>>>> have one for political reasons (think free software extremists) rather than >>>>> because they aren't tech savvy enough: while the "hibernate" naming might >>>>> confuse users looking for information about grizzly bears, I doubt my >>>>> grandmother, my 7-year-old nephew or even my non-software-engineer of a >>>>> wife would end up on Gitter by mistake. >>>>> >>>>> Well since that's obvious, clearly I was referring to a different way >>>>> of cathegorizing people joining@ not by age or expertise in technology >>>>> but in having reasonable expectations and willing to do some research >>>>> before bothering us all. >>>>> >>>>> You probably weren't around yet, but Hibernate has had hard times in >>>>> which it was "victim of its own success": just too many >>>>> kinda-interested people making a ton of basic questions that could be >>>>> easily solved otherwise. >>>>> >>>>> Some "barriers" we have in place have made it manageable; of course I >>>>> can't tell if it's all merit of the barriers of entry or just people >>>>> coming in lower volumes with better intentions, but I'm confident that >>>>> some of the barriers we have have helped to keep some sanity (e.g. >>>>> login on #hibernate-dev on IRC requiring an account). >>>>> >>>>> Assuming the new chat platform takes off, there's a risk it might be >>>>> too successful as well. But I guess we'll see, or let's use a very >>>>> bad chat platform so to keep people from coming :P >>>>> >>>>> > >>>>> > >>>>> > Yoann Rodi?re >>>>> > Hibernate NoORM Team >>>>> > yoann at hibernate.org >>>>> > >>>>> > >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero >>>>> wrote: >>>>> >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole >>>>> wrote: >>>>> >> > >>>>> >> > What is it a conscious decision to not require a GitHub account >>>>> to join these rooms? I just noticed that is a toggle-option in the room's >>>>> settings also. >>>>> >> >>>>> >> I don't remember. We created these rooms as an experiment in 2014.. >>>>> >> Yoann created some more rooms recently. >>>>> >> >>>>> >> Should we enforce people to have a Github account? I'd like that, I >>>>> >> think it would better nudge towards getting the right type of people >>>>> >> to join. >>>>> >> >>>>> >> Thanks, >>>>> >> Sanne >>>>> >> >>>>> >> >>>>> >> > >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < >>>>> guillaume.smet at gmail.com> wrote: >>>>> >> >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < >>>>> sanne at hibernate.org> >>>>> >> >> wrote: >>>>> >> >> >>>>> >> >> > If one wants a lot of features then clearly only Slack is the >>>>> way to >>>>> >> >> > go. Not saying we should go with Slack, just that we'll need >>>>> to be >>>>> >> >> > patient and we'll always be short of some features - if that's >>>>> not >>>>> >> >> > acceptable then only Slack will make you happy. >>>>> >> >> > >>>>> >> >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for me but >>>>> yeah not >>>>> >> >> having sound is really annoying. >>>>> >> >> >>>>> >> >> I might miss notifications from time to time. >>>>> >> >> >>>>> >> >> In any case, it will mostly be a problem for you all if you ping >>>>> me :). >>>>> >> >> >>>>> >> >> >>>>> >> >> > BTW the issue you linked to suggests the native clients don't >>>>> have >>>>> >> >> > this specific problem.. might want to try that? >>>>> >> >> > >>>>> >> >> >>>>> >> >> I prefer to have it in the browser where I do most of my >>>>> interactions with >>>>> >> >> people. >>>>> >> >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb (and not >>>>> very excited >>>>> >> >> about compiling it). >>>>> >> >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it if >>>>> they want to >>>>> >> >> become a player in this area. They certainly have some work to >>>>> do to catch >>>>> >> >> up with others. >>>>> >> >> >>>>> >> >> -- >>>>> >> >> Guillaume >>>>> >> >> _______________________________________________ >>>>> >> >> hibernate-dev mailing list >>>>> >> >> hibernate-dev at lists.jboss.org >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >> _______________________________________________ >>>>> >> hibernate-dev mailing list >>>>> >> hibernate-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> From christian.beikov at gmail.com Thu Dec 6 03:54:06 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Thu, 6 Dec 2018 09:54:06 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: I'm fine with it. Am 06.12.2018 um 08:52 schrieb Yoann Rodiere: > The WildFly team is moving from Slack to Zulip, because Zulip seems to be > the only solution that is free, provides unlimited history, and allows > unlimited users even in private rooms (for OSS projects, at least). Gitter > has all that, except unlimited users, as we are limited to 25 people per > private room. > > You can join them here: https://wildfly.zulipchat.com/ > > Back to our solution... We are now 71 days away from the decommissioning of > HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to > keep looking for another solution? > > For my part, I noticed problems with the web client, in particular with > notifications, which are sub-standard, but with the desktop client > everything seems to work fine. It's simple, but it does the job. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere wrote: > >> On top of not being able to add more than 25 people to a private room, >> there's another limitation of Gitter that Fabio just noticed: the chat >> history for 1-to-1 conversations is very limited. In our case, we can only >> see 2 days back, and there's no concept of archives like there is in rooms. >> >> Meanwhile, the WildFly team is giving up on Slack because of the very >> limited size of history in free plans. They are investigating Zulip, >> RocketChat and MatterMost in particular. Maybe let's see what they end up >> choosing and why? >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere wrote: >> >>> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere wrote: >>> >>>>> Assuming the new chat platform takes off, there's a risk it might be >>>> too successful as well >>>> >>>> Ok. Well, I guess we'll see. As I mentioned above, I don't think forcing >>>> people to have a GitHub account will be very effective, but I can't suggest >>>> a perfect solution either. Bots answering with a few links (documentation, >>>> etc.) to the first message of each user come to mind, but that could be >>>> considered rude, so I wouldn't do that unless the traffic becomes >>>> unmanageable. Other solutions include kicking out "spammers" (but that >>>> doesn't work if it's many users asking a single question), or making the >>>> -dev rooms invite-only and only checking the user rooms once in a while >>>> (might work if Gitter sends emails when your are mentioned while offline). >>>> So, yeah, in short: I don't really know. >>>> >>>>> More just accountability. But if some form of login in needed to use >>>> Gitter, that's enough for me. Sounded like the other option was "allow >>>> anonymous", which I wanted to avoid. >>>> >>>> Then it should be fine: anonymous access apparently only allows to read >>>> messages. Login through GitLab, GitHub or Twitter is necessary in order to >>>> start posting new messages. >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> >>>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole >>>> wrote: >>>> >>>>> For me its not so much about "the right kind of people". More just >>>>> accountability. But if some form of login in needed to use Gitter, that's >>>>> enough for me. Sounded like the other option was "allow anonymous", which >>>>> I wanted to avoid. >>>>> >>>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero >>>>> wrote: >>>>> >>>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere >>>>>> wrote: >>>>>>> I don't see why we should force people to have a GitHub account, >>>>>> considering there are other means of logging into Gitter. >>>>>> >>>>>> Ok. >>>>>> >>>>>>> As to getting the right type of people, I'm not sure it's relevant. >>>>>> Most people are likely to have one, and those who don't are likely to not >>>>>> have one for political reasons (think free software extremists) rather than >>>>>> because they aren't tech savvy enough: while the "hibernate" naming might >>>>>> confuse users looking for information about grizzly bears, I doubt my >>>>>> grandmother, my 7-year-old nephew or even my non-software-engineer of a >>>>>> wife would end up on Gitter by mistake. >>>>>> >>>>>> Well since that's obvious, clearly I was referring to a different way >>>>>> of cathegorizing people joining@ not by age or expertise in technology >>>>>> but in having reasonable expectations and willing to do some research >>>>>> before bothering us all. >>>>>> >>>>>> You probably weren't around yet, but Hibernate has had hard times in >>>>>> which it was "victim of its own success": just too many >>>>>> kinda-interested people making a ton of basic questions that could be >>>>>> easily solved otherwise. >>>>>> >>>>>> Some "barriers" we have in place have made it manageable; of course I >>>>>> can't tell if it's all merit of the barriers of entry or just people >>>>>> coming in lower volumes with better intentions, but I'm confident that >>>>>> some of the barriers we have have helped to keep some sanity (e.g. >>>>>> login on #hibernate-dev on IRC requiring an account). >>>>>> >>>>>> Assuming the new chat platform takes off, there's a risk it might be >>>>>> too successful as well. But I guess we'll see, or let's use a very >>>>>> bad chat platform so to keep people from coming :P >>>>>> >>>>>>> >>>>>>> Yoann Rodi?re >>>>>>> Hibernate NoORM Team >>>>>>> yoann at hibernate.org >>>>>>> >>>>>>> >>>>>>> On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero >>>>>> wrote: >>>>>>>> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole >>>>>> wrote: >>>>>>>>> What is it a conscious decision to not require a GitHub account >>>>>> to join these rooms? I just noticed that is a toggle-option in the room's >>>>>> settings also. >>>>>>>> I don't remember. We created these rooms as an experiment in 2014.. >>>>>>>> Yoann created some more rooms recently. >>>>>>>> >>>>>>>> Should we enforce people to have a Github account? I'd like that, I >>>>>>>> think it would better nudge towards getting the right type of people >>>>>>>> to join. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sanne >>>>>>>> >>>>>>>> >>>>>>>>> On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < >>>>>> guillaume.smet at gmail.com> wrote: >>>>>>>>>> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < >>>>>> sanne at hibernate.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> If one wants a lot of features then clearly only Slack is the >>>>>> way to >>>>>>>>>>> go. Not saying we should go with Slack, just that we'll need >>>>>> to be >>>>>>>>>>> patient and we'll always be short of some features - if that's >>>>>> not >>>>>>>>>>> acceptable then only Slack will make you happy. >>>>>>>>>>> >>>>>>>>>> TBH, I don't care about fancy features. Gitter is OK for me but >>>>>> yeah not >>>>>>>>>> having sound is really annoying. >>>>>>>>>> >>>>>>>>>> I might miss notifications from time to time. >>>>>>>>>> >>>>>>>>>> In any case, it will mostly be a problem for you all if you ping >>>>>> me :). >>>>>>>>>> >>>>>>>>>>> BTW the issue you linked to suggests the native clients don't >>>>>> have >>>>>>>>>>> this specific problem.. might want to try that? >>>>>>>>>>> >>>>>>>>>> I prefer to have it in the browser where I do most of my >>>>>> interactions with >>>>>>>>>> people. >>>>>>>>>> >>>>>>>>>> And AFAIK, Yoann wrote they were only packaged as deb (and not >>>>>> very excited >>>>>>>>>> about compiling it). >>>>>>>>>> >>>>>>>>>> BTW, tbh, I'm a bit worried GitLab has only one dev on it if >>>>>> they want to >>>>>>>>>> become a player in this area. They certainly have some work to >>>>>> do to catch >>>>>>>>>> up with others. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Guillaume >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Dec 6 04:40:31 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 6 Dec 2018 10:40:31 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: So, I'm using Zulip right now on a daily basis. I maintain my first impression that it's really not user friendly. The fact that you are required to create topics for discussions (or find a suitable topic in a list of a gazillion topics previously created, obviously without a search engine where you need it - you have a global one at the top where you can find topics) is a pain. You also need to use ctrl+enter to send a message, the default enter is a new line in your message. The UI is not very good and I don't see any improvement since the last time I tested it so I'm wondering if they are investing in it. We could decide to use it as a dev team as I suppose we would get used to it, but I seriously don't think it's a good alternative for our users to occasionally come chat with us. As for Gitter, I agree with the notification issue, the web client is all buggy. Haven't tested the desktop client yet. I must admit that I prefer using Gitter. Probably until I get bitten by the 1-1 history issue :). >From what I can see, GitLab doesn't invest much in Gitter either so I wonder if it's gonna be viable in the long term. I suppose we'll see. -- Guillaume On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere wrote: > The WildFly team is moving from Slack to Zulip, because Zulip seems to be > the only solution that is free, provides unlimited history, and allows > unlimited users even in private rooms (for OSS projects, at least). Gitter > has all that, except unlimited users, as we are limited to 25 people per > private room. > > You can join them here: https://wildfly.zulipchat.com/ > > Back to our solution... We are now 71 days away from the decommissioning of > HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to > keep looking for another solution? > > For my part, I noticed problems with the web client, in particular with > notifications, which are sub-standard, but with the desktop client > everything seems to work fine. It's simple, but it does the job. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere wrote: > > > On top of not being able to add more than 25 people to a private room, > > there's another limitation of Gitter that Fabio just noticed: the chat > > history for 1-to-1 conversations is very limited. In our case, we can > only > > see 2 days back, and there's no concept of archives like there is in > rooms. > > > > Meanwhile, the WildFly team is giving up on Slack because of the very > > limited size of history in free plans. They are investigating Zulip, > > RocketChat and MatterMost in particular. Maybe let's see what they end up > > choosing and why? > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere wrote: > > > >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > wrote: > >> > >>> > Assuming the new chat platform takes off, there's a risk it might be > >>> too successful as well > >>> > >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > forcing > >>> people to have a GitHub account will be very effective, but I can't > suggest > >>> a perfect solution either. Bots answering with a few links > (documentation, > >>> etc.) to the first message of each user come to mind, but that could be > >>> considered rude, so I wouldn't do that unless the traffic becomes > >>> unmanageable. Other solutions include kicking out "spammers" (but that > >>> doesn't work if it's many users asking a single question), or making > the > >>> -dev rooms invite-only and only checking the user rooms once in a while > >>> (might work if Gitter sends emails when your are mentioned while > offline). > >>> So, yeah, in short: I don't really know. > >>> > >>> > More just accountability. But if some form of login in needed to use > >>> Gitter, that's enough for me. Sounded like the other option was "allow > >>> anonymous", which I wanted to avoid. > >>> > >>> Then it should be fine: anonymous access apparently only allows to read > >>> messages. Login through GitLab, GitHub or Twitter is necessary in > order to > >>> start posting new messages. > >>> > >>> Yoann Rodi?re > >>> Hibernate NoORM Team > >>> yoann at hibernate.org > >>> > >>> > >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole > >>> wrote: > >>> > >>>> For me its not so much about "the right kind of people". More just > >>>> accountability. But if some form of login in needed to use Gitter, > that's > >>>> enough for me. Sounded like the other option was "allow anonymous", > which > >>>> I wanted to avoid. > >>>> > >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero > > >>>> wrote: > >>>> > >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere > >>>>> wrote: > >>>>> > > >>>>> > I don't see why we should force people to have a GitHub account, > >>>>> considering there are other means of logging into Gitter. > >>>>> > >>>>> Ok. > >>>>> > >>>>> > > >>>>> > As to getting the right type of people, I'm not sure it's relevant. > >>>>> Most people are likely to have one, and those who don't are likely > to not > >>>>> have one for political reasons (think free software extremists) > rather than > >>>>> because they aren't tech savvy enough: while the "hibernate" naming > might > >>>>> confuse users looking for information about grizzly bears, I doubt my > >>>>> grandmother, my 7-year-old nephew or even my non-software-engineer > of a > >>>>> wife would end up on Gitter by mistake. > >>>>> > >>>>> Well since that's obvious, clearly I was referring to a different way > >>>>> of cathegorizing people joining@ not by age or expertise in > technology > >>>>> but in having reasonable expectations and willing to do some research > >>>>> before bothering us all. > >>>>> > >>>>> You probably weren't around yet, but Hibernate has had hard times in > >>>>> which it was "victim of its own success": just too many > >>>>> kinda-interested people making a ton of basic questions that could be > >>>>> easily solved otherwise. > >>>>> > >>>>> Some "barriers" we have in place have made it manageable; of course I > >>>>> can't tell if it's all merit of the barriers of entry or just people > >>>>> coming in lower volumes with better intentions, but I'm confident > that > >>>>> some of the barriers we have have helped to keep some sanity (e.g. > >>>>> login on #hibernate-dev on IRC requiring an account). > >>>>> > >>>>> Assuming the new chat platform takes off, there's a risk it might be > >>>>> too successful as well. But I guess we'll see, or let's use a very > >>>>> bad chat platform so to keep people from coming :P > >>>>> > >>>>> > > >>>>> > > >>>>> > Yoann Rodi?re > >>>>> > Hibernate NoORM Team > >>>>> > yoann at hibernate.org > >>>>> > > >>>>> > > >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero > > >>>>> wrote: > >>>>> >> > >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole > > >>>>> wrote: > >>>>> >> > > >>>>> >> > What is it a conscious decision to not require a GitHub account > >>>>> to join these rooms? I just noticed that is a toggle-option in the > room's > >>>>> settings also. > >>>>> >> > >>>>> >> I don't remember. We created these rooms as an experiment in > 2014.. > >>>>> >> Yoann created some more rooms recently. > >>>>> >> > >>>>> >> Should we enforce people to have a Github account? I'd like that, > I > >>>>> >> think it would better nudge towards getting the right type of > people > >>>>> >> to join. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Sanne > >>>>> >> > >>>>> >> > >>>>> >> > > >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > >>>>> guillaume.smet at gmail.com> wrote: > >>>>> >> >> > >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > >>>>> sanne at hibernate.org> > >>>>> >> >> wrote: > >>>>> >> >> > >>>>> >> >> > If one wants a lot of features then clearly only Slack is the > >>>>> way to > >>>>> >> >> > go. Not saying we should go with Slack, just that we'll need > >>>>> to be > >>>>> >> >> > patient and we'll always be short of some features - if > that's > >>>>> not > >>>>> >> >> > acceptable then only Slack will make you happy. > >>>>> >> >> > > >>>>> >> >> > >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for me but > >>>>> yeah not > >>>>> >> >> having sound is really annoying. > >>>>> >> >> > >>>>> >> >> I might miss notifications from time to time. > >>>>> >> >> > >>>>> >> >> In any case, it will mostly be a problem for you all if you > ping > >>>>> me :). > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > BTW the issue you linked to suggests the native clients don't > >>>>> have > >>>>> >> >> > this specific problem.. might want to try that? > >>>>> >> >> > > >>>>> >> >> > >>>>> >> >> I prefer to have it in the browser where I do most of my > >>>>> interactions with > >>>>> >> >> people. > >>>>> >> >> > >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb (and not > >>>>> very excited > >>>>> >> >> about compiling it). > >>>>> >> >> > >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it if > >>>>> they want to > >>>>> >> >> become a player in this area. They certainly have some work to > >>>>> do to catch > >>>>> >> >> up with others. > >>>>> >> >> > >>>>> >> >> -- > >>>>> >> >> Guillaume > >>>>> >> >> _______________________________________________ > >>>>> >> >> hibernate-dev mailing list > >>>>> >> >> hibernate-dev at lists.jboss.org > >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> >> _______________________________________________ > >>>>> >> hibernate-dev mailing list > >>>>> >> hibernate-dev at lists.jboss.org > >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> > >>>> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Thu Dec 6 05:09:04 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 6 Dec 2018 11:09:04 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: > You also need to use ctrl+enter to send a message, the default enter is a new line in your message There's a checkbox to change that, and its value is persisted, so you only have to tick it once. It's located just beside the "Send" button, I'm sure you saw it :) But apart from that, yes, I agree it's not very user-friendly. It's more about the user getting used to the tool than the tool being made obvious from the start. I'm also unsure how long Gitter will continue to be maintained, and how well it will be. But we're mostly done migrating to Gitter; I don't see much activity on HipChat anymore. Objectively, and regardless of my preferred tool, the main drawback I can see about not moving to Zulip (or another tool) now, but only later, is the confusion it will potentially create for users: we were on HipChat, announced we were moving to Gitter and changed the links on our website, and a few months later we move again. That is, I think, something we want to avoid. So the question really is: is Gitter the right tool for us, and do we trust it to stay the right tool for us long enough (say, at least a couple of years)? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Thu, 6 Dec 2018 at 10:41, Guillaume Smet wrote: > So, I'm using Zulip right now on a daily basis. > > I maintain my first impression that it's really not user friendly. > > The fact that you are required to create topics for discussions (or find a > suitable topic in a list of a gazillion topics previously created, > obviously without a search engine where you need it - you have a global one > at the top where you can find topics) is a pain. You also need to use > ctrl+enter to send a message, the default enter is a new line in your > message. The UI is not very good and I don't see any improvement since the > last time I tested it so I'm wondering if they are investing in it. > > We could decide to use it as a dev team as I suppose we would get used to > it, but I seriously don't think it's a good alternative for our users to > occasionally come chat with us. > > As for Gitter, I agree with the notification issue, the web client is all > buggy. Haven't tested the desktop client yet. > > I must admit that I prefer using Gitter. Probably until I get bitten by > the 1-1 history issue :). > > From what I can see, GitLab doesn't invest much in Gitter either so I > wonder if it's gonna be viable in the long term. > > I suppose we'll see. > > -- > Guillaume > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere wrote: > >> The WildFly team is moving from Slack to Zulip, because Zulip seems to be >> the only solution that is free, provides unlimited history, and allows >> unlimited users even in private rooms (for OSS projects, at least). Gitter >> has all that, except unlimited users, as we are limited to 25 people per >> private room. >> >> You can join them here: https://wildfly.zulipchat.com/ >> >> Back to our solution... We are now 71 days away from the decommissioning >> of >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to >> keep looking for another solution? >> >> For my part, I noticed problems with the web client, in particular with >> notifications, which are sub-standard, but with the desktop client >> everything seems to work fine. It's simple, but it does the job. >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere wrote: >> >> > On top of not being able to add more than 25 people to a private room, >> > there's another limitation of Gitter that Fabio just noticed: the chat >> > history for 1-to-1 conversations is very limited. In our case, we can >> only >> > see 2 days back, and there's no concept of archives like there is in >> rooms. >> > >> > Meanwhile, the WildFly team is giving up on Slack because of the very >> > limited size of history in free plans. They are investigating Zulip, >> > RocketChat and MatterMost in particular. Maybe let's see what they end >> up >> > choosing and why? >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere >> wrote: >> > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere >> wrote: >> >> >> >>> > Assuming the new chat platform takes off, there's a risk it might be >> >>> too successful as well >> >>> >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think >> forcing >> >>> people to have a GitHub account will be very effective, but I can't >> suggest >> >>> a perfect solution either. Bots answering with a few links >> (documentation, >> >>> etc.) to the first message of each user come to mind, but that could >> be >> >>> considered rude, so I wouldn't do that unless the traffic becomes >> >>> unmanageable. Other solutions include kicking out "spammers" (but that >> >>> doesn't work if it's many users asking a single question), or making >> the >> >>> -dev rooms invite-only and only checking the user rooms once in a >> while >> >>> (might work if Gitter sends emails when your are mentioned while >> offline). >> >>> So, yeah, in short: I don't really know. >> >>> >> >>> > More just accountability. But if some form of login in needed to >> use >> >>> Gitter, that's enough for me. Sounded like the other option was >> "allow >> >>> anonymous", which I wanted to avoid. >> >>> >> >>> Then it should be fine: anonymous access apparently only allows to >> read >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in >> order to >> >>> start posting new messages. >> >>> >> >>> Yoann Rodi?re >> >>> Hibernate NoORM Team >> >>> yoann at hibernate.org >> >>> >> >>> >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole >> >>> wrote: >> >>> >> >>>> For me its not so much about "the right kind of people". More just >> >>>> accountability. But if some form of login in needed to use Gitter, >> that's >> >>>> enough for me. Sounded like the other option was "allow anonymous", >> which >> >>>> I wanted to avoid. >> >>>> >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < >> sanne at hibernate.org> >> >>>> wrote: >> >>>> >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere >> >>>>> wrote: >> >>>>> > >> >>>>> > I don't see why we should force people to have a GitHub account, >> >>>>> considering there are other means of logging into Gitter. >> >>>>> >> >>>>> Ok. >> >>>>> >> >>>>> > >> >>>>> > As to getting the right type of people, I'm not sure it's >> relevant. >> >>>>> Most people are likely to have one, and those who don't are likely >> to not >> >>>>> have one for political reasons (think free software extremists) >> rather than >> >>>>> because they aren't tech savvy enough: while the "hibernate" naming >> might >> >>>>> confuse users looking for information about grizzly bears, I doubt >> my >> >>>>> grandmother, my 7-year-old nephew or even my non-software-engineer >> of a >> >>>>> wife would end up on Gitter by mistake. >> >>>>> >> >>>>> Well since that's obvious, clearly I was referring to a different >> way >> >>>>> of cathegorizing people joining@ not by age or expertise in >> technology >> >>>>> but in having reasonable expectations and willing to do some >> research >> >>>>> before bothering us all. >> >>>>> >> >>>>> You probably weren't around yet, but Hibernate has had hard times in >> >>>>> which it was "victim of its own success": just too many >> >>>>> kinda-interested people making a ton of basic questions that could >> be >> >>>>> easily solved otherwise. >> >>>>> >> >>>>> Some "barriers" we have in place have made it manageable; of course >> I >> >>>>> can't tell if it's all merit of the barriers of entry or just people >> >>>>> coming in lower volumes with better intentions, but I'm confident >> that >> >>>>> some of the barriers we have have helped to keep some sanity (e.g. >> >>>>> login on #hibernate-dev on IRC requiring an account). >> >>>>> >> >>>>> Assuming the new chat platform takes off, there's a risk it might be >> >>>>> too successful as well. But I guess we'll see, or let's use a very >> >>>>> bad chat platform so to keep people from coming :P >> >>>>> >> >>>>> > >> >>>>> > >> >>>>> > Yoann Rodi?re >> >>>>> > Hibernate NoORM Team >> >>>>> > yoann at hibernate.org >> >>>>> > >> >>>>> > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < >> sanne at hibernate.org> >> >>>>> wrote: >> >>>>> >> >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < >> steve at hibernate.org> >> >>>>> wrote: >> >>>>> >> > >> >>>>> >> > What is it a conscious decision to not require a GitHub account >> >>>>> to join these rooms? I just noticed that is a toggle-option in the >> room's >> >>>>> settings also. >> >>>>> >> >> >>>>> >> I don't remember. We created these rooms as an experiment in >> 2014.. >> >>>>> >> Yoann created some more rooms recently. >> >>>>> >> >> >>>>> >> Should we enforce people to have a Github account? I'd like >> that, I >> >>>>> >> think it would better nudge towards getting the right type of >> people >> >>>>> >> to join. >> >>>>> >> >> >>>>> >> Thanks, >> >>>>> >> Sanne >> >>>>> >> >> >>>>> >> >> >>>>> >> > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < >> >>>>> guillaume.smet at gmail.com> wrote: >> >>>>> >> >> >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < >> >>>>> sanne at hibernate.org> >> >>>>> >> >> wrote: >> >>>>> >> >> >> >>>>> >> >> > If one wants a lot of features then clearly only Slack is >> the >> >>>>> way to >> >>>>> >> >> > go. Not saying we should go with Slack, just that we'll need >> >>>>> to be >> >>>>> >> >> > patient and we'll always be short of some features - if >> that's >> >>>>> not >> >>>>> >> >> > acceptable then only Slack will make you happy. >> >>>>> >> >> > >> >>>>> >> >> >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for me >> but >> >>>>> yeah not >> >>>>> >> >> having sound is really annoying. >> >>>>> >> >> >> >>>>> >> >> I might miss notifications from time to time. >> >>>>> >> >> >> >>>>> >> >> In any case, it will mostly be a problem for you all if you >> ping >> >>>>> me :). >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> > BTW the issue you linked to suggests the native clients >> don't >> >>>>> have >> >>>>> >> >> > this specific problem.. might want to try that? >> >>>>> >> >> > >> >>>>> >> >> >> >>>>> >> >> I prefer to have it in the browser where I do most of my >> >>>>> interactions with >> >>>>> >> >> people. >> >>>>> >> >> >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb (and not >> >>>>> very excited >> >>>>> >> >> about compiling it). >> >>>>> >> >> >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it if >> >>>>> they want to >> >>>>> >> >> become a player in this area. They certainly have some work to >> >>>>> do to catch >> >>>>> >> >> up with others. >> >>>>> >> >> >> >>>>> >> >> -- >> >>>>> >> >> Guillaume >> >>>>> >> >> _______________________________________________ >> >>>>> >> >> hibernate-dev mailing list >> >>>>> >> >> hibernate-dev at lists.jboss.org >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>> >> _______________________________________________ >> >>>>> >> hibernate-dev mailing list >> >>>>> >> hibernate-dev at lists.jboss.org >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>> >> >>>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From rvansa at redhat.com Thu Dec 6 05:11:27 2018 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 6 Dec 2018 11:11:27 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: <312c27a3-6758-2b64-937b-db969f44b768@redhat.com> On 12/06/2018 10:40 AM, Guillaume Smet wrote: > So, I'm using Zulip right now on a daily basis. > > I maintain my first impression that it's really not user friendly. > > The fact that you are required to create topics for discussions Why is creating a new topic (=typing three extra words) an issue? This is the killer feature why many people love Zulip. (I would not spend more than 5 seconds checking for any existing topic on similar matter) > (or find a > suitable topic in a list of a gazillion topics previously created, > obviously without a search engine where you need it - you have a global one > at the top where you can find topics) is a pain. You also need to use > ctrl+enter to send a message, the default enter is a new line in your > message. There's a checkbox just next to the Send button, check it once and the setting persists. > The UI is not very good and I don't see any improvement since the > last time I tested it so I'm wondering if they are investing in it. Maybe they don't have feedback? Besides zooming in (View - Zoom In) I am perfectly satisfied with the UI. Actually one thing that I am not 100% comfortable with is the active/inactive status, which marks people inactive despite they have the client just on the background. Radim > > We could decide to use it as a dev team as I suppose we would get used to > it, but I seriously don't think it's a good alternative for our users to > occasionally come chat with us. > > As for Gitter, I agree with the notification issue, the web client is all > buggy. Haven't tested the desktop client yet. > > I must admit that I prefer using Gitter. Probably until I get bitten by the > 1-1 history issue :). > > From what I can see, GitLab doesn't invest much in Gitter either so I > wonder if it's gonna be viable in the long term. > > I suppose we'll see. > -- Radim Vansa JBoss Performance Team From steve at hibernate.org Thu Dec 6 07:02:12 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 06:02:12 -0600 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: If it helps, Guillaume, the desktop client made all the difference for me. And I hated the idea of moving to Gitter based on just the web client. On Thu, Dec 6, 2018 at 4:25 AM Yoann Rodiere wrote: > > You also need to use ctrl+enter to send a message, the default enter is a > new line in your message > > There's a checkbox to change that, and its value is persisted, so you only > have to tick it once. It's located just beside the "Send" button, I'm sure > you saw it :) > But apart from that, yes, I agree it's not very user-friendly. It's more > about the user getting used to the tool than the tool being made obvious > from the start. > > I'm also unsure how long Gitter will continue to be maintained, and how > well it will be. But we're mostly done migrating to Gitter; I don't see > much activity on HipChat anymore. > > Objectively, and regardless of my preferred tool, the main drawback I can > see about not moving to Zulip (or another tool) now, but only later, is the > confusion it will potentially create for users: we were on HipChat, > announced we were moving to Gitter and changed the links on our website, > and a few months later we move again. That is, I think, something we want > to avoid. > > So the question really is: is Gitter the right tool for us, and do we trust > it to stay the right tool for us long enough (say, at least a couple of > years)? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet > wrote: > > > So, I'm using Zulip right now on a daily basis. > > > > I maintain my first impression that it's really not user friendly. > > > > The fact that you are required to create topics for discussions (or find > a > > suitable topic in a list of a gazillion topics previously created, > > obviously without a search engine where you need it - you have a global > one > > at the top where you can find topics) is a pain. You also need to use > > ctrl+enter to send a message, the default enter is a new line in your > > message. The UI is not very good and I don't see any improvement since > the > > last time I tested it so I'm wondering if they are investing in it. > > > > We could decide to use it as a dev team as I suppose we would get used to > > it, but I seriously don't think it's a good alternative for our users to > > occasionally come chat with us. > > > > As for Gitter, I agree with the notification issue, the web client is all > > buggy. Haven't tested the desktop client yet. > > > > I must admit that I prefer using Gitter. Probably until I get bitten by > > the 1-1 history issue :). > > > > From what I can see, GitLab doesn't invest much in Gitter either so I > > wonder if it's gonna be viable in the long term. > > > > I suppose we'll see. > > > > -- > > Guillaume > > > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere > wrote: > > > >> The WildFly team is moving from Slack to Zulip, because Zulip seems to > be > >> the only solution that is free, provides unlimited history, and allows > >> unlimited users even in private rooms (for OSS projects, at least). > Gitter > >> has all that, except unlimited users, as we are limited to 25 people per > >> private room. > >> > >> You can join them here: https://wildfly.zulipchat.com/ > >> > >> Back to our solution... We are now 71 days away from the decommissioning > >> of > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to > >> keep looking for another solution? > >> > >> For my part, I noticed problems with the web client, in particular with > >> notifications, which are sub-standard, but with the desktop client > >> everything seems to work fine. It's simple, but it does the job. > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere > wrote: > >> > >> > On top of not being able to add more than 25 people to a private room, > >> > there's another limitation of Gitter that Fabio just noticed: the chat > >> > history for 1-to-1 conversations is very limited. In our case, we can > >> only > >> > see 2 days back, and there's no concept of archives like there is in > >> rooms. > >> > > >> > Meanwhile, the WildFly team is giving up on Slack because of the very > >> > limited size of history in free plans. They are investigating Zulip, > >> > RocketChat and MatterMost in particular. Maybe let's see what they end > >> up > >> > choosing and why? > >> > > >> > Yoann Rodi?re > >> > Hibernate NoORM Team > >> > yoann at hibernate.org > >> > > >> > > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere > >> wrote: > >> > > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > >> wrote: > >> >> > >> >>> > Assuming the new chat platform takes off, there's a risk it might > be > >> >>> too successful as well > >> >>> > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > >> forcing > >> >>> people to have a GitHub account will be very effective, but I can't > >> suggest > >> >>> a perfect solution either. Bots answering with a few links > >> (documentation, > >> >>> etc.) to the first message of each user come to mind, but that could > >> be > >> >>> considered rude, so I wouldn't do that unless the traffic becomes > >> >>> unmanageable. Other solutions include kicking out "spammers" (but > that > >> >>> doesn't work if it's many users asking a single question), or making > >> the > >> >>> -dev rooms invite-only and only checking the user rooms once in a > >> while > >> >>> (might work if Gitter sends emails when your are mentioned while > >> offline). > >> >>> So, yeah, in short: I don't really know. > >> >>> > >> >>> > More just accountability. But if some form of login in needed to > >> use > >> >>> Gitter, that's enough for me. Sounded like the other option was > >> "allow > >> >>> anonymous", which I wanted to avoid. > >> >>> > >> >>> Then it should be fine: anonymous access apparently only allows to > >> read > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in > >> order to > >> >>> start posting new messages. > >> >>> > >> >>> Yoann Rodi?re > >> >>> Hibernate NoORM Team > >> >>> yoann at hibernate.org > >> >>> > >> >>> > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole > >> >>> wrote: > >> >>> > >> >>>> For me its not so much about "the right kind of people". More just > >> >>>> accountability. But if some form of login in needed to use Gitter, > >> that's > >> >>>> enough for me. Sounded like the other option was "allow > anonymous", > >> which > >> >>>> I wanted to avoid. > >> >>>> > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>> wrote: > >> >>>> > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere > >> >>>>> wrote: > >> >>>>> > > >> >>>>> > I don't see why we should force people to have a GitHub account, > >> >>>>> considering there are other means of logging into Gitter. > >> >>>>> > >> >>>>> Ok. > >> >>>>> > >> >>>>> > > >> >>>>> > As to getting the right type of people, I'm not sure it's > >> relevant. > >> >>>>> Most people are likely to have one, and those who don't are likely > >> to not > >> >>>>> have one for political reasons (think free software extremists) > >> rather than > >> >>>>> because they aren't tech savvy enough: while the "hibernate" > naming > >> might > >> >>>>> confuse users looking for information about grizzly bears, I doubt > >> my > >> >>>>> grandmother, my 7-year-old nephew or even my non-software-engineer > >> of a > >> >>>>> wife would end up on Gitter by mistake. > >> >>>>> > >> >>>>> Well since that's obvious, clearly I was referring to a different > >> way > >> >>>>> of cathegorizing people joining@ not by age or expertise in > >> technology > >> >>>>> but in having reasonable expectations and willing to do some > >> research > >> >>>>> before bothering us all. > >> >>>>> > >> >>>>> You probably weren't around yet, but Hibernate has had hard times > in > >> >>>>> which it was "victim of its own success": just too many > >> >>>>> kinda-interested people making a ton of basic questions that could > >> be > >> >>>>> easily solved otherwise. > >> >>>>> > >> >>>>> Some "barriers" we have in place have made it manageable; of > course > >> I > >> >>>>> can't tell if it's all merit of the barriers of entry or just > people > >> >>>>> coming in lower volumes with better intentions, but I'm confident > >> that > >> >>>>> some of the barriers we have have helped to keep some sanity (e.g. > >> >>>>> login on #hibernate-dev on IRC requiring an account). > >> >>>>> > >> >>>>> Assuming the new chat platform takes off, there's a risk it might > be > >> >>>>> too successful as well. But I guess we'll see, or let's use a > very > >> >>>>> bad chat platform so to keep people from coming :P > >> >>>>> > >> >>>>> > > >> >>>>> > > >> >>>>> > Yoann Rodi?re > >> >>>>> > Hibernate NoORM Team > >> >>>>> > yoann at hibernate.org > >> >>>>> > > >> >>>>> > > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>>> wrote: > >> >>>>> >> > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < > >> steve at hibernate.org> > >> >>>>> wrote: > >> >>>>> >> > > >> >>>>> >> > What is it a conscious decision to not require a GitHub > account > >> >>>>> to join these rooms? I just noticed that is a toggle-option in > the > >> room's > >> >>>>> settings also. > >> >>>>> >> > >> >>>>> >> I don't remember. We created these rooms as an experiment in > >> 2014.. > >> >>>>> >> Yoann created some more rooms recently. > >> >>>>> >> > >> >>>>> >> Should we enforce people to have a Github account? I'd like > >> that, I > >> >>>>> >> think it would better nudge towards getting the right type of > >> people > >> >>>>> >> to join. > >> >>>>> >> > >> >>>>> >> Thanks, > >> >>>>> >> Sanne > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > >> >>>>> guillaume.smet at gmail.com> wrote: > >> >>>>> >> >> > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > >> >>>>> sanne at hibernate.org> > >> >>>>> >> >> wrote: > >> >>>>> >> >> > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack is > >> the > >> >>>>> way to > >> >>>>> >> >> > go. Not saying we should go with Slack, just that we'll > need > >> >>>>> to be > >> >>>>> >> >> > patient and we'll always be short of some features - if > >> that's > >> >>>>> not > >> >>>>> >> >> > acceptable then only Slack will make you happy. > >> >>>>> >> >> > > >> >>>>> >> >> > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for me > >> but > >> >>>>> yeah not > >> >>>>> >> >> having sound is really annoying. > >> >>>>> >> >> > >> >>>>> >> >> I might miss notifications from time to time. > >> >>>>> >> >> > >> >>>>> >> >> In any case, it will mostly be a problem for you all if you > >> ping > >> >>>>> me :). > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients > >> don't > >> >>>>> have > >> >>>>> >> >> > this specific problem.. might want to try that? > >> >>>>> >> >> > > >> >>>>> >> >> > >> >>>>> >> >> I prefer to have it in the browser where I do most of my > >> >>>>> interactions with > >> >>>>> >> >> people. > >> >>>>> >> >> > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb (and > not > >> >>>>> very excited > >> >>>>> >> >> about compiling it). > >> >>>>> >> >> > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it if > >> >>>>> they want to > >> >>>>> >> >> become a player in this area. They certainly have some work > to > >> >>>>> do to catch > >> >>>>> >> >> up with others. > >> >>>>> >> >> > >> >>>>> >> >> -- > >> >>>>> >> >> Guillaume > >> >>>>> >> >> _______________________________________________ > >> >>>>> >> >> hibernate-dev mailing list > >> >>>>> >> >> hibernate-dev at lists.jboss.org > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>> >> _______________________________________________ > >> >>>>> >> hibernate-dev mailing list > >> >>>>> >> hibernate-dev at lists.jboss.org > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>> > >> >>>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Dec 6 07:53:28 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 06:53:28 -0600 Subject: [hibernate-dev] master and 6.0 branch Message-ID: 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, that was fine. However, now that we are starting the Alpha release cycle, that is no longer reasonable. So as of today we really need a new strategy here. However it works out, changes made to master than also affect 6.0 should be done in both places. This has 2 benefits IMO: 1. Obviously it removes the need to perform these massive, time-consuming "merges" 2. A great side effect is that it gets people with 6.0 code base differences. From yoann at hibernate.org Thu Dec 6 08:09:29 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 6 Dec 2018 14:09:29 +0100 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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 different reasons (e.g. "not implemented yet"). Which will be hard to diagnose for those not working on 6 on a day-to-day basis. But I suppose it could work if we moved the focus away from 5.x maintenance, which is perhaps what you had in mind? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Thu, 6 Dec 2018 at 14:01, Steve Ebersole wrote: > 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, that was fine. However, now that we are starting the > Alpha release cycle, that is no longer reasonable. So as of today we > really need a new strategy here. However it works out, changes made to > master than also affect 6.0 should be done in both places. > > This has 2 benefits IMO: > > 1. Obviously it removes the need to perform these massive, > time-consuming "merges" > 2. A great side effect is that it gets people with 6.0 code base > differences. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Dec 6 08:09:58 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 6 Dec 2018 14:09:58 +0100 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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 implemented yet, not fully functional, same buggy or new buggy. We don't push that many things to 5.x so maybe you could explain why the merges are so painful so that we can try to make them less so? -- Guillaume On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole wrote: > 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, that was fine. However, now that we are starting the > Alpha release cycle, that is no longer reasonable. So as of today we > really need a new strategy here. However it works out, changes made to > master than also affect 6.0 should be done in both places. > > This has 2 benefits IMO: > > 1. Obviously it removes the need to perform these massive, > time-consuming "merges" > 2. A great side effect is that it gets people with 6.0 code base > differences. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Dec 6 08:35:50 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 07:35:50 -0600 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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) developing 6, it kind of sucks to have to waste a whole day (often more than 1 day) to perform massive merges. There are major difference between 5 and 6 and that is part of the problem. E.g. when y'all change something in EntityPersister, well that does not exist in 6... that's a conflict and has to be resolved. Who is better able to resolve that? Well I think it is a combination. The person who authored the change obviously understands the purpose, logic, etc behind the change; far more so than the person simply trying to integrate it. Of course most of the people doing any development on 5 (outside of Andrea, Chris and I for the most part) do not know the 6 code base so it is tougher for them. The other part is that it is just logical that porting one change is far easier than simultaneously porting many changes. That is doubly true when you are doing one of these massive merges and there are conflicts in stuff you did not write. Long-story-short, putting the responsibility wholly on one party or the other is not scalable. So far the onus has been on Andrea, Chris and I to do that all - again, which *was* fine. But the story has changed. What I had envisioned is that this is a collaboration. If you contribute something to 5, ask Andrea, Chris or me (1) whether that needs to be ported and we can work together to get it ported. Its not any different from any "major" - when we moved from 1.0 to 2.0, or moved 2.0 to 3.0, or ... There are always pain points due to major changes between (otherwise it would not be a major release). And for a short time there is always a period of "double development". I am all ears for better options; but "just develop on 5 and let others port to 6" is simply not a good one. On Thu, Dec 6, 2018 at 7:10 AM 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 really be able to know if it > doesn't work because it's not implemented yet, not fully functional, same > buggy or new buggy. > > We don't push that many things to 5.x so maybe you could explain why the > merges are so painful so that we can try to make them less so? > > -- > Guillaume > > > On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole wrote: > >> 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, that was fine. However, now that we are starting the >> Alpha release cycle, that is no longer reasonable. So as of today we >> really need a new strategy here. However it works out, changes made to >> master than also affect 6.0 should be done in both places. >> >> This has 2 benefits IMO: >> >> 1. Obviously it removes the need to perform these massive, >> time-consuming "merges" >> 2. A great side effect is that it gets people with 6.0 code base >> differences. > > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Thu Dec 6 09:23:27 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 08:23:27 -0600 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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 6, 2018, 7:35 AM Steve Ebersole wrote: > 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) > developing 6, it kind of sucks to have to waste a whole day (often more > than 1 day) to perform massive merges. There are major difference between > 5 and 6 and that is part of the problem. E.g. when y'all change something > in EntityPersister, well that does not exist in 6... that's a conflict and > has to be resolved. Who is better able to resolve that? Well I think it > is a combination. The person who authored the change obviously understands > the purpose, logic, etc behind the change; far more so than the person > simply trying to integrate it. Of course most of the people doing any > development on 5 (outside of Andrea, Chris and I for the most part) do not > know the 6 code base so it is tougher for them. > > The other part is that it is just logical that porting one change is far > easier than simultaneously porting many changes. That is doubly true when > you are doing one of these massive merges and there are conflicts in stuff > you did not write. > > Long-story-short, putting the responsibility wholly on one party or the > other is not scalable. So far the onus has been on Andrea, Chris and I to > do that all - again, which *was* fine. But the story has changed. > > What I had envisioned is that this is a collaboration. If you contribute > something to 5, ask Andrea, Chris or me (1) whether that needs to be ported > and we can work together to get it ported. Its not any different from any > "major" - when we moved from 1.0 to 2.0, or moved 2.0 to 3.0, or ... There > are always pain points due to major changes between (otherwise it would not > be a major release). And for a short time there is always a period of > "double development". I am all ears for better options; but "just develop > on 5 and let others port to 6" is simply not a good one. > > > > On Thu, Dec 6, 2018 at 7:10 AM 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 really be able to know if it >> doesn't work because it's not implemented yet, not fully functional, same >> buggy or new buggy. >> >> We don't push that many things to 5.x so maybe you could explain why the >> merges are so painful so that we can try to make them less so? >> >> -- >> Guillaume >> >> >> On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole >> wrote: >> >>> 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, that was fine. However, now that we are starting the >>> Alpha release cycle, that is no longer reasonable. So as of today we >>> really need a new strategy here. However it works out, changes made to >>> master than also affect 6.0 should be done in both places. >>> >>> This has 2 benefits IMO: >>> >>> 1. Obviously it removes the need to perform these massive, >>> time-consuming "merges" >>> 2. A great side effect is that it gets people with 6.0 code base >>> differences. >> >> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From andrea at hibernate.org Thu Dec 6 09:34:57 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 6 Dec 2018 14:34:57 +0000 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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 implemented in 6.0 he solution should be delayed ) and then backported - critical bugs should be solved in 6.0 and 5.x in case it is too difficult to solve them in 6.0 then just add a disabled test. On Thu, 6 Dec 2018 at 13:17, Yoann Rodiere wrote: > 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 different reasons (e.g. "not implemented yet"). Which will > be hard to diagnose for those not working on 6 on a day-to-day basis. > > But I suppose it could work if we moved the focus away from 5.x > maintenance, which is perhaps what you had in mind? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Thu, 6 Dec 2018 at 14:01, Steve Ebersole wrote: > > > 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, that was fine. However, now that we are starting the > > Alpha release cycle, that is no longer reasonable. So as of today we > > really need a new strategy here. However it works out, changes made to > > master than also affect 6.0 should be done in both places. > > > > This has 2 benefits IMO: > > > > 1. Obviously it removes the need to perform these massive, > > time-consuming "merges" > > 2. A great side effect is that it gets people with 6.0 code base > > differences. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Dec 6 10:03:56 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Dec 2018 15:03:56 +0000 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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 really be able to know if it > doesn't work because it's not implemented yet, not fully functional, same > buggy or new buggy. > > We don't push that many things to 5.x so maybe you could explain why the > merges are so painful so that we can try to make them less so? 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. As you said in the previous paragraph, we're a small team and we can't keep developing 2 branches of the same project. 5.x needs to be moved into strictly maintenance only, so please stop pushing big changes to 5.x unless there's a very important reason - we need to move on towars a situation in which all innovation happens on 6 aka master. Thanks, Sanne > > -- > Guillaume > > > On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole wrote: > > > 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, that was fine. However, now that we are starting the > > Alpha release cycle, that is no longer reasonable. So as of today we > > really need a new strategy here. However it works out, changes made to > > master than also affect 6.0 should be done in both places. > > > > This has 2 benefits IMO: > > > > 1. Obviously it removes the need to perform these massive, > > time-consuming "merges" > > 2. A great side effect is that it gets people with 6.0 code base > > differences. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Dec 6 10:07:39 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Dec 2018 15:07:39 +0000 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: On Thu, 6 Dec 2018 at 10:25, Yoann Rodiere wrote: > > > You also need to use ctrl+enter to send a message, the default enter is a > new line in your message > > There's a checkbox to change that, and its value is persisted, so you only > have to tick it once. It's located just beside the "Send" button, I'm sure > you saw it :) > But apart from that, yes, I agree it's not very user-friendly. It's more > about the user getting used to the tool than the tool being made obvious > from the start. > > I'm also unsure how long Gitter will continue to be maintained, and how > well it will be. But we're mostly done migrating to Gitter; I don't see > much activity on HipChat anymore. Hey wait a second :) You invited us to try Gitter. That's fine but we never decided we're migrating to Gitter. I'm certainly not on Gitter regularly nor right now, so I'm expecting any important matter to be discussed on mailing lists or HipChat. > > Objectively, and regardless of my preferred tool, the main drawback I can > see about not moving to Zulip (or another tool) now, but only later, is the > confusion it will potentially create for users: we were on HipChat, > announced we were moving to Gitter and changed the links on our website, > and a few months later we move again. That is, I think, something we want > to avoid. > > So the question really is: is Gitter the right tool for us, and do we trust > it to stay the right tool for us long enough (say, at least a couple of > years)? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet > wrote: > > > So, I'm using Zulip right now on a daily basis. > > > > I maintain my first impression that it's really not user friendly. > > > > The fact that you are required to create topics for discussions (or find a > > suitable topic in a list of a gazillion topics previously created, > > obviously without a search engine where you need it - you have a global one > > at the top where you can find topics) is a pain. You also need to use > > ctrl+enter to send a message, the default enter is a new line in your > > message. The UI is not very good and I don't see any improvement since the > > last time I tested it so I'm wondering if they are investing in it. > > > > We could decide to use it as a dev team as I suppose we would get used to > > it, but I seriously don't think it's a good alternative for our users to > > occasionally come chat with us. > > > > As for Gitter, I agree with the notification issue, the web client is all > > buggy. Haven't tested the desktop client yet. > > > > I must admit that I prefer using Gitter. Probably until I get bitten by > > the 1-1 history issue :). > > > > From what I can see, GitLab doesn't invest much in Gitter either so I > > wonder if it's gonna be viable in the long term. > > > > I suppose we'll see. > > > > -- > > Guillaume > > > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere wrote: > > > >> The WildFly team is moving from Slack to Zulip, because Zulip seems to be > >> the only solution that is free, provides unlimited history, and allows > >> unlimited users even in private rooms (for OSS projects, at least). Gitter > >> has all that, except unlimited users, as we are limited to 25 people per > >> private room. > >> > >> You can join them here: https://wildfly.zulipchat.com/ > >> > >> Back to our solution... We are now 71 days away from the decommissioning > >> of > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason to > >> keep looking for another solution? > >> > >> For my part, I noticed problems with the web client, in particular with > >> notifications, which are sub-standard, but with the desktop client > >> everything seems to work fine. It's simple, but it does the job. > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere wrote: > >> > >> > On top of not being able to add more than 25 people to a private room, > >> > there's another limitation of Gitter that Fabio just noticed: the chat > >> > history for 1-to-1 conversations is very limited. In our case, we can > >> only > >> > see 2 days back, and there's no concept of archives like there is in > >> rooms. > >> > > >> > Meanwhile, the WildFly team is giving up on Slack because of the very > >> > limited size of history in free plans. They are investigating Zulip, > >> > RocketChat and MatterMost in particular. Maybe let's see what they end > >> up > >> > choosing and why? > >> > > >> > Yoann Rodi?re > >> > Hibernate NoORM Team > >> > yoann at hibernate.org > >> > > >> > > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere > >> wrote: > >> > > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > >> wrote: > >> >> > >> >>> > Assuming the new chat platform takes off, there's a risk it might be > >> >>> too successful as well > >> >>> > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > >> forcing > >> >>> people to have a GitHub account will be very effective, but I can't > >> suggest > >> >>> a perfect solution either. Bots answering with a few links > >> (documentation, > >> >>> etc.) to the first message of each user come to mind, but that could > >> be > >> >>> considered rude, so I wouldn't do that unless the traffic becomes > >> >>> unmanageable. Other solutions include kicking out "spammers" (but that > >> >>> doesn't work if it's many users asking a single question), or making > >> the > >> >>> -dev rooms invite-only and only checking the user rooms once in a > >> while > >> >>> (might work if Gitter sends emails when your are mentioned while > >> offline). > >> >>> So, yeah, in short: I don't really know. > >> >>> > >> >>> > More just accountability. But if some form of login in needed to > >> use > >> >>> Gitter, that's enough for me. Sounded like the other option was > >> "allow > >> >>> anonymous", which I wanted to avoid. > >> >>> > >> >>> Then it should be fine: anonymous access apparently only allows to > >> read > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in > >> order to > >> >>> start posting new messages. > >> >>> > >> >>> Yoann Rodi?re > >> >>> Hibernate NoORM Team > >> >>> yoann at hibernate.org > >> >>> > >> >>> > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole > >> >>> wrote: > >> >>> > >> >>>> For me its not so much about "the right kind of people". More just > >> >>>> accountability. But if some form of login in needed to use Gitter, > >> that's > >> >>>> enough for me. Sounded like the other option was "allow anonymous", > >> which > >> >>>> I wanted to avoid. > >> >>>> > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>> wrote: > >> >>>> > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere > >> >>>>> wrote: > >> >>>>> > > >> >>>>> > I don't see why we should force people to have a GitHub account, > >> >>>>> considering there are other means of logging into Gitter. > >> >>>>> > >> >>>>> Ok. > >> >>>>> > >> >>>>> > > >> >>>>> > As to getting the right type of people, I'm not sure it's > >> relevant. > >> >>>>> Most people are likely to have one, and those who don't are likely > >> to not > >> >>>>> have one for political reasons (think free software extremists) > >> rather than > >> >>>>> because they aren't tech savvy enough: while the "hibernate" naming > >> might > >> >>>>> confuse users looking for information about grizzly bears, I doubt > >> my > >> >>>>> grandmother, my 7-year-old nephew or even my non-software-engineer > >> of a > >> >>>>> wife would end up on Gitter by mistake. > >> >>>>> > >> >>>>> Well since that's obvious, clearly I was referring to a different > >> way > >> >>>>> of cathegorizing people joining@ not by age or expertise in > >> technology > >> >>>>> but in having reasonable expectations and willing to do some > >> research > >> >>>>> before bothering us all. > >> >>>>> > >> >>>>> You probably weren't around yet, but Hibernate has had hard times in > >> >>>>> which it was "victim of its own success": just too many > >> >>>>> kinda-interested people making a ton of basic questions that could > >> be > >> >>>>> easily solved otherwise. > >> >>>>> > >> >>>>> Some "barriers" we have in place have made it manageable; of course > >> I > >> >>>>> can't tell if it's all merit of the barriers of entry or just people > >> >>>>> coming in lower volumes with better intentions, but I'm confident > >> that > >> >>>>> some of the barriers we have have helped to keep some sanity (e.g. > >> >>>>> login on #hibernate-dev on IRC requiring an account). > >> >>>>> > >> >>>>> Assuming the new chat platform takes off, there's a risk it might be > >> >>>>> too successful as well. But I guess we'll see, or let's use a very > >> >>>>> bad chat platform so to keep people from coming :P > >> >>>>> > >> >>>>> > > >> >>>>> > > >> >>>>> > Yoann Rodi?re > >> >>>>> > Hibernate NoORM Team > >> >>>>> > yoann at hibernate.org > >> >>>>> > > >> >>>>> > > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>>> wrote: > >> >>>>> >> > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < > >> steve at hibernate.org> > >> >>>>> wrote: > >> >>>>> >> > > >> >>>>> >> > What is it a conscious decision to not require a GitHub account > >> >>>>> to join these rooms? I just noticed that is a toggle-option in the > >> room's > >> >>>>> settings also. > >> >>>>> >> > >> >>>>> >> I don't remember. We created these rooms as an experiment in > >> 2014.. > >> >>>>> >> Yoann created some more rooms recently. > >> >>>>> >> > >> >>>>> >> Should we enforce people to have a Github account? I'd like > >> that, I > >> >>>>> >> think it would better nudge towards getting the right type of > >> people > >> >>>>> >> to join. > >> >>>>> >> > >> >>>>> >> Thanks, > >> >>>>> >> Sanne > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > >> >>>>> guillaume.smet at gmail.com> wrote: > >> >>>>> >> >> > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > >> >>>>> sanne at hibernate.org> > >> >>>>> >> >> wrote: > >> >>>>> >> >> > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack is > >> the > >> >>>>> way to > >> >>>>> >> >> > go. Not saying we should go with Slack, just that we'll need > >> >>>>> to be > >> >>>>> >> >> > patient and we'll always be short of some features - if > >> that's > >> >>>>> not > >> >>>>> >> >> > acceptable then only Slack will make you happy. > >> >>>>> >> >> > > >> >>>>> >> >> > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for me > >> but > >> >>>>> yeah not > >> >>>>> >> >> having sound is really annoying. > >> >>>>> >> >> > >> >>>>> >> >> I might miss notifications from time to time. > >> >>>>> >> >> > >> >>>>> >> >> In any case, it will mostly be a problem for you all if you > >> ping > >> >>>>> me :). > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients > >> don't > >> >>>>> have > >> >>>>> >> >> > this specific problem.. might want to try that? > >> >>>>> >> >> > > >> >>>>> >> >> > >> >>>>> >> >> I prefer to have it in the browser where I do most of my > >> >>>>> interactions with > >> >>>>> >> >> people. > >> >>>>> >> >> > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb (and not > >> >>>>> very excited > >> >>>>> >> >> about compiling it). > >> >>>>> >> >> > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it if > >> >>>>> they want to > >> >>>>> >> >> become a player in this area. They certainly have some work to > >> >>>>> do to catch > >> >>>>> >> >> up with others. > >> >>>>> >> >> > >> >>>>> >> >> -- > >> >>>>> >> >> Guillaume > >> >>>>> >> >> _______________________________________________ > >> >>>>> >> >> hibernate-dev mailing list > >> >>>>> >> >> hibernate-dev at lists.jboss.org > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>> >> _______________________________________________ > >> >>>>> >> hibernate-dev mailing list > >> >>>>> >> hibernate-dev at lists.jboss.org > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>> > >> >>>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Dec 6 10:08:01 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 09:08:01 -0600 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: 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. We have to clearly decide as a team (1) whether that change needs to be done on 6 and (2) how to go about that. Definitely for some period of time I fully expect that to mean Andrea, Chris, Davide or myself being involved in all such discussions simply because we know 6 better than others. Personally, I prefer developing on 6 and back-porting, but that distinction not really relevant yet - it will become relevant as 6 gets to more of a CR state. On Thu, Dec 6, 2018 at 8:35 AM andrea boriero wrote: > 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 > implemented in 6.0 he solution should be delayed ) and then backported > - critical bugs should be solved in 6.0 and 5.x in case it is too > difficult to solve them in 6.0 then just add a disabled test. > > > On Thu, 6 Dec 2018 at 13:17, Yoann Rodiere wrote: > >> 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 different reasons (e.g. "not implemented yet"). Which >> will >> be hard to diagnose for those not working on 6 on a day-to-day basis. >> >> But I suppose it could work if we moved the focus away from 5.x >> maintenance, which is perhaps what you had in mind? >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> On Thu, 6 Dec 2018 at 14:01, Steve Ebersole wrote: >> >> > 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, that was fine. However, now that we are starting the >> > Alpha release cycle, that is no longer reasonable. So as of today we >> > really need a new strategy here. However it works out, changes made to >> > master than also affect 6.0 should be done in both places. >> > >> > This has 2 benefits IMO: >> > >> > 1. Obviously it removes the need to perform these massive, >> > time-consuming "merges" >> > 2. A great side effect is that it gets people with 6.0 code base >> > differences. >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Thu Dec 6 10:16:00 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 09:16:00 -0600 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: I am never on HipChat at this point. So don't expect any important matters to be discussed there ;) On Thu, Dec 6, 2018 at 9:08 AM Sanne Grinovero wrote: > On Thu, 6 Dec 2018 at 10:25, Yoann Rodiere wrote: > > > > > You also need to use ctrl+enter to send a message, the default enter > is a > > new line in your message > > > > There's a checkbox to change that, and its value is persisted, so you > only > > have to tick it once. It's located just beside the "Send" button, I'm > sure > > you saw it :) > > But apart from that, yes, I agree it's not very user-friendly. It's more > > about the user getting used to the tool than the tool being made obvious > > from the start. > > > > I'm also unsure how long Gitter will continue to be maintained, and how > > well it will be. But we're mostly done migrating to Gitter; I don't see > > much activity on HipChat anymore. > > Hey wait a second :) You invited us to try Gitter. That's fine but we > never decided we're migrating to Gitter. > > I'm certainly not on Gitter regularly nor right now, so I'm expecting > any important matter to be discussed on mailing lists or HipChat. > > > > > Objectively, and regardless of my preferred tool, the main drawback I can > > see about not moving to Zulip (or another tool) now, but only later, is > the > > confusion it will potentially create for users: we were on HipChat, > > announced we were moving to Gitter and changed the links on our website, > > and a few months later we move again. That is, I think, something we want > > to avoid. > > > > So the question really is: is Gitter the right tool for us, and do we > trust > > it to stay the right tool for us long enough (say, at least a couple of > > years)? > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet > > wrote: > > > > > So, I'm using Zulip right now on a daily basis. > > > > > > I maintain my first impression that it's really not user friendly. > > > > > > The fact that you are required to create topics for discussions (or > find a > > > suitable topic in a list of a gazillion topics previously created, > > > obviously without a search engine where you need it - you have a > global one > > > at the top where you can find topics) is a pain. You also need to use > > > ctrl+enter to send a message, the default enter is a new line in your > > > message. The UI is not very good and I don't see any improvement since > the > > > last time I tested it so I'm wondering if they are investing in it. > > > > > > We could decide to use it as a dev team as I suppose we would get used > to > > > it, but I seriously don't think it's a good alternative for our users > to > > > occasionally come chat with us. > > > > > > As for Gitter, I agree with the notification issue, the web client is > all > > > buggy. Haven't tested the desktop client yet. > > > > > > I must admit that I prefer using Gitter. Probably until I get bitten by > > > the 1-1 history issue :). > > > > > > From what I can see, GitLab doesn't invest much in Gitter either so I > > > wonder if it's gonna be viable in the long term. > > > > > > I suppose we'll see. > > > > > > -- > > > Guillaume > > > > > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere > wrote: > > > > > >> The WildFly team is moving from Slack to Zulip, because Zulip seems > to be > > >> the only solution that is free, provides unlimited history, and allows > > >> unlimited users even in private rooms (for OSS projects, at least). > Gitter > > >> has all that, except unlimited users, as we are limited to 25 people > per > > >> private room. > > >> > > >> You can join them here: https://wildfly.zulipchat.com/ > > >> > > >> Back to our solution... We are now 71 days away from the > decommissioning > > >> of > > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason > to > > >> keep looking for another solution? > > >> > > >> For my part, I noticed problems with the web client, in particular > with > > >> notifications, which are sub-standard, but with the desktop client > > >> everything seems to work fine. It's simple, but it does the job. > > >> > > >> Yoann Rodi?re > > >> Hibernate NoORM Team > > >> yoann at hibernate.org > > >> > > >> > > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere > wrote: > > >> > > >> > On top of not being able to add more than 25 people to a private > room, > > >> > there's another limitation of Gitter that Fabio just noticed: the > chat > > >> > history for 1-to-1 conversations is very limited. In our case, we > can > > >> only > > >> > see 2 days back, and there's no concept of archives like there is in > > >> rooms. > > >> > > > >> > Meanwhile, the WildFly team is giving up on Slack because of the > very > > >> > limited size of history in free plans. They are investigating Zulip, > > >> > RocketChat and MatterMost in particular. Maybe let's see what they > end > > >> up > > >> > choosing and why? > > >> > > > >> > Yoann Rodi?re > > >> > Hibernate NoORM Team > > >> > yoann at hibernate.org > > >> > > > >> > > > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere > > >> wrote: > > >> > > > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > > >> wrote: > > >> >> > > >> >>> > Assuming the new chat platform takes off, there's a risk it > might be > > >> >>> too successful as well > > >> >>> > > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > > >> forcing > > >> >>> people to have a GitHub account will be very effective, but I > can't > > >> suggest > > >> >>> a perfect solution either. Bots answering with a few links > > >> (documentation, > > >> >>> etc.) to the first message of each user come to mind, but that > could > > >> be > > >> >>> considered rude, so I wouldn't do that unless the traffic becomes > > >> >>> unmanageable. Other solutions include kicking out "spammers" (but > that > > >> >>> doesn't work if it's many users asking a single question), or > making > > >> the > > >> >>> -dev rooms invite-only and only checking the user rooms once in a > > >> while > > >> >>> (might work if Gitter sends emails when your are mentioned while > > >> offline). > > >> >>> So, yeah, in short: I don't really know. > > >> >>> > > >> >>> > More just accountability. But if some form of login in needed > to > > >> use > > >> >>> Gitter, that's enough for me. Sounded like the other option was > > >> "allow > > >> >>> anonymous", which I wanted to avoid. > > >> >>> > > >> >>> Then it should be fine: anonymous access apparently only allows to > > >> read > > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in > > >> order to > > >> >>> start posting new messages. > > >> >>> > > >> >>> Yoann Rodi?re > > >> >>> Hibernate NoORM Team > > >> >>> yoann at hibernate.org > > >> >>> > > >> >>> > > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole > > > >> >>> wrote: > > >> >>> > > >> >>>> For me its not so much about "the right kind of people". More > just > > >> >>>> accountability. But if some form of login in needed to use > Gitter, > > >> that's > > >> >>>> enough for me. Sounded like the other option was "allow > anonymous", > > >> which > > >> >>>> I wanted to avoid. > > >> >>>> > > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < > > >> sanne at hibernate.org> > > >> >>>> wrote: > > >> >>>> > > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere < > yoann at hibernate.org> > > >> >>>>> wrote: > > >> >>>>> > > > >> >>>>> > I don't see why we should force people to have a GitHub > account, > > >> >>>>> considering there are other means of logging into Gitter. > > >> >>>>> > > >> >>>>> Ok. > > >> >>>>> > > >> >>>>> > > > >> >>>>> > As to getting the right type of people, I'm not sure it's > > >> relevant. > > >> >>>>> Most people are likely to have one, and those who don't are > likely > > >> to not > > >> >>>>> have one for political reasons (think free software extremists) > > >> rather than > > >> >>>>> because they aren't tech savvy enough: while the "hibernate" > naming > > >> might > > >> >>>>> confuse users looking for information about grizzly bears, I > doubt > > >> my > > >> >>>>> grandmother, my 7-year-old nephew or even my > non-software-engineer > > >> of a > > >> >>>>> wife would end up on Gitter by mistake. > > >> >>>>> > > >> >>>>> Well since that's obvious, clearly I was referring to a > different > > >> way > > >> >>>>> of cathegorizing people joining@ not by age or expertise in > > >> technology > > >> >>>>> but in having reasonable expectations and willing to do some > > >> research > > >> >>>>> before bothering us all. > > >> >>>>> > > >> >>>>> You probably weren't around yet, but Hibernate has had hard > times in > > >> >>>>> which it was "victim of its own success": just too many > > >> >>>>> kinda-interested people making a ton of basic questions that > could > > >> be > > >> >>>>> easily solved otherwise. > > >> >>>>> > > >> >>>>> Some "barriers" we have in place have made it manageable; of > course > > >> I > > >> >>>>> can't tell if it's all merit of the barriers of entry or just > people > > >> >>>>> coming in lower volumes with better intentions, but I'm > confident > > >> that > > >> >>>>> some of the barriers we have have helped to keep some sanity > (e.g. > > >> >>>>> login on #hibernate-dev on IRC requiring an account). > > >> >>>>> > > >> >>>>> Assuming the new chat platform takes off, there's a risk it > might be > > >> >>>>> too successful as well. But I guess we'll see, or let's use a > very > > >> >>>>> bad chat platform so to keep people from coming :P > > >> >>>>> > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > Yoann Rodi?re > > >> >>>>> > Hibernate NoORM Team > > >> >>>>> > yoann at hibernate.org > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < > > >> sanne at hibernate.org> > > >> >>>>> wrote: > > >> >>>>> >> > > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < > > >> steve at hibernate.org> > > >> >>>>> wrote: > > >> >>>>> >> > > > >> >>>>> >> > What is it a conscious decision to not require a GitHub > account > > >> >>>>> to join these rooms? I just noticed that is a toggle-option in > the > > >> room's > > >> >>>>> settings also. > > >> >>>>> >> > > >> >>>>> >> I don't remember. We created these rooms as an experiment in > > >> 2014.. > > >> >>>>> >> Yoann created some more rooms recently. > > >> >>>>> >> > > >> >>>>> >> Should we enforce people to have a Github account? I'd like > > >> that, I > > >> >>>>> >> think it would better nudge towards getting the right type of > > >> people > > >> >>>>> >> to join. > > >> >>>>> >> > > >> >>>>> >> Thanks, > > >> >>>>> >> Sanne > > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> >> > > > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > > >> >>>>> guillaume.smet at gmail.com> wrote: > > >> >>>>> >> >> > > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > > >> >>>>> sanne at hibernate.org> > > >> >>>>> >> >> wrote: > > >> >>>>> >> >> > > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack > is > > >> the > > >> >>>>> way to > > >> >>>>> >> >> > go. Not saying we should go with Slack, just that we'll > need > > >> >>>>> to be > > >> >>>>> >> >> > patient and we'll always be short of some features - if > > >> that's > > >> >>>>> not > > >> >>>>> >> >> > acceptable then only Slack will make you happy. > > >> >>>>> >> >> > > > >> >>>>> >> >> > > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for > me > > >> but > > >> >>>>> yeah not > > >> >>>>> >> >> having sound is really annoying. > > >> >>>>> >> >> > > >> >>>>> >> >> I might miss notifications from time to time. > > >> >>>>> >> >> > > >> >>>>> >> >> In any case, it will mostly be a problem for you all if > you > > >> ping > > >> >>>>> me :). > > >> >>>>> >> >> > > >> >>>>> >> >> > > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients > > >> don't > > >> >>>>> have > > >> >>>>> >> >> > this specific problem.. might want to try that? > > >> >>>>> >> >> > > > >> >>>>> >> >> > > >> >>>>> >> >> I prefer to have it in the browser where I do most of my > > >> >>>>> interactions with > > >> >>>>> >> >> people. > > >> >>>>> >> >> > > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb > (and not > > >> >>>>> very excited > > >> >>>>> >> >> about compiling it). > > >> >>>>> >> >> > > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on it > if > > >> >>>>> they want to > > >> >>>>> >> >> become a player in this area. They certainly have some > work to > > >> >>>>> do to catch > > >> >>>>> >> >> up with others. > > >> >>>>> >> >> > > >> >>>>> >> >> -- > > >> >>>>> >> >> Guillaume > > >> >>>>> >> >> _______________________________________________ > > >> >>>>> >> >> hibernate-dev mailing list > > >> >>>>> >> >> hibernate-dev at lists.jboss.org > > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >>>>> >> _______________________________________________ > > >> >>>>> >> hibernate-dev mailing list > > >> >>>>> >> hibernate-dev at lists.jboss.org > > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >>>>> > > >> >>>> > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Thu Dec 6 10:54:14 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 6 Dec 2018 16:54:14 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: > Hey wait a second :) You invited us to try Gitter. That's fine but we > never decided we're migrating to Gitter. Sure. What I meant was that we are *de facto* done migrating to gitter. Not that we meant it, but almost everyone is there already and almost no one is on HipChat. I wouldn't expect important matters to be discussed on Gitter, but then again I seem to remember someone (who was that? ;) ) telling me to use the mailing list, and not HipChat, for important matters. So, you should be fine. That being said, even if the decision to migrate was not made, we will have to make it at some point. So if you want something else, I'd be happy to hear about that :) Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Thu, 6 Dec 2018 at 16:16, Steve Ebersole wrote: > I am never on HipChat at this point. So don't expect any important > matters to be discussed there ;) > > > On Thu, Dec 6, 2018 at 9:08 AM Sanne Grinovero > wrote: > >> On Thu, 6 Dec 2018 at 10:25, Yoann Rodiere wrote: >> > >> > > You also need to use ctrl+enter to send a message, the default enter >> is a >> > new line in your message >> > >> > There's a checkbox to change that, and its value is persisted, so you >> only >> > have to tick it once. It's located just beside the "Send" button, I'm >> sure >> > you saw it :) >> > But apart from that, yes, I agree it's not very user-friendly. It's more >> > about the user getting used to the tool than the tool being made obvious >> > from the start. >> > >> > I'm also unsure how long Gitter will continue to be maintained, and how >> > well it will be. But we're mostly done migrating to Gitter; I don't see >> > much activity on HipChat anymore. >> >> Hey wait a second :) You invited us to try Gitter. That's fine but we >> never decided we're migrating to Gitter. >> >> I'm certainly not on Gitter regularly nor right now, so I'm expecting >> any important matter to be discussed on mailing lists or HipChat. >> >> > >> > Objectively, and regardless of my preferred tool, the main drawback I >> can >> > see about not moving to Zulip (or another tool) now, but only later, is >> the >> > confusion it will potentially create for users: we were on HipChat, >> > announced we were moving to Gitter and changed the links on our website, >> > and a few months later we move again. That is, I think, something we >> want >> > to avoid. >> > >> > So the question really is: is Gitter the right tool for us, and do we >> trust >> > it to stay the right tool for us long enough (say, at least a couple of >> > years)? >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet >> > wrote: >> > >> > > So, I'm using Zulip right now on a daily basis. >> > > >> > > I maintain my first impression that it's really not user friendly. >> > > >> > > The fact that you are required to create topics for discussions (or >> find a >> > > suitable topic in a list of a gazillion topics previously created, >> > > obviously without a search engine where you need it - you have a >> global one >> > > at the top where you can find topics) is a pain. You also need to use >> > > ctrl+enter to send a message, the default enter is a new line in your >> > > message. The UI is not very good and I don't see any improvement >> since the >> > > last time I tested it so I'm wondering if they are investing in it. >> > > >> > > We could decide to use it as a dev team as I suppose we would get >> used to >> > > it, but I seriously don't think it's a good alternative for our users >> to >> > > occasionally come chat with us. >> > > >> > > As for Gitter, I agree with the notification issue, the web client is >> all >> > > buggy. Haven't tested the desktop client yet. >> > > >> > > I must admit that I prefer using Gitter. Probably until I get bitten >> by >> > > the 1-1 history issue :). >> > > >> > > From what I can see, GitLab doesn't invest much in Gitter either so I >> > > wonder if it's gonna be viable in the long term. >> > > >> > > I suppose we'll see. >> > > >> > > -- >> > > Guillaume >> > > >> > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere >> wrote: >> > > >> > >> The WildFly team is moving from Slack to Zulip, because Zulip seems >> to be >> > >> the only solution that is free, provides unlimited history, and >> allows >> > >> unlimited users even in private rooms (for OSS projects, at least). >> Gitter >> > >> has all that, except unlimited users, as we are limited to 25 people >> per >> > >> private room. >> > >> >> > >> You can join them here: https://wildfly.zulipchat.com/ >> > >> >> > >> Back to our solution... We are now 71 days away from the >> decommissioning >> > >> of >> > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason >> to >> > >> keep looking for another solution? >> > >> >> > >> For my part, I noticed problems with the web client, in particular >> with >> > >> notifications, which are sub-standard, but with the desktop client >> > >> everything seems to work fine. It's simple, but it does the job. >> > >> >> > >> Yoann Rodi?re >> > >> Hibernate NoORM Team >> > >> yoann at hibernate.org >> > >> >> > >> >> > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere >> wrote: >> > >> >> > >> > On top of not being able to add more than 25 people to a private >> room, >> > >> > there's another limitation of Gitter that Fabio just noticed: the >> chat >> > >> > history for 1-to-1 conversations is very limited. In our case, we >> can >> > >> only >> > >> > see 2 days back, and there's no concept of archives like there is >> in >> > >> rooms. >> > >> > >> > >> > Meanwhile, the WildFly team is giving up on Slack because of the >> very >> > >> > limited size of history in free plans. They are investigating >> Zulip, >> > >> > RocketChat and MatterMost in particular. Maybe let's see what they >> end >> > >> up >> > >> > choosing and why? >> > >> > >> > >> > Yoann Rodi?re >> > >> > Hibernate NoORM Team >> > >> > yoann at hibernate.org >> > >> > >> > >> > >> > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere >> > >> wrote: >> > >> > >> > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere >> > >> wrote: >> > >> >> >> > >> >>> > Assuming the new chat platform takes off, there's a risk it >> might be >> > >> >>> too successful as well >> > >> >>> >> > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think >> > >> forcing >> > >> >>> people to have a GitHub account will be very effective, but I >> can't >> > >> suggest >> > >> >>> a perfect solution either. Bots answering with a few links >> > >> (documentation, >> > >> >>> etc.) to the first message of each user come to mind, but that >> could >> > >> be >> > >> >>> considered rude, so I wouldn't do that unless the traffic becomes >> > >> >>> unmanageable. Other solutions include kicking out "spammers" >> (but that >> > >> >>> doesn't work if it's many users asking a single question), or >> making >> > >> the >> > >> >>> -dev rooms invite-only and only checking the user rooms once in a >> > >> while >> > >> >>> (might work if Gitter sends emails when your are mentioned while >> > >> offline). >> > >> >>> So, yeah, in short: I don't really know. >> > >> >>> >> > >> >>> > More just accountability. But if some form of login in needed >> to >> > >> use >> > >> >>> Gitter, that's enough for me. Sounded like the other option was >> > >> "allow >> > >> >>> anonymous", which I wanted to avoid. >> > >> >>> >> > >> >>> Then it should be fine: anonymous access apparently only allows >> to >> > >> read >> > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in >> > >> order to >> > >> >>> start posting new messages. >> > >> >>> >> > >> >>> Yoann Rodi?re >> > >> >>> Hibernate NoORM Team >> > >> >>> yoann at hibernate.org >> > >> >>> >> > >> >>> >> > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole < >> steve at hibernate.org> >> > >> >>> wrote: >> > >> >>> >> > >> >>>> For me its not so much about "the right kind of people". More >> just >> > >> >>>> accountability. But if some form of login in needed to use >> Gitter, >> > >> that's >> > >> >>>> enough for me. Sounded like the other option was "allow >> anonymous", >> > >> which >> > >> >>>> I wanted to avoid. >> > >> >>>> >> > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < >> > >> sanne at hibernate.org> >> > >> >>>> wrote: >> > >> >>>> >> > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere < >> yoann at hibernate.org> >> > >> >>>>> wrote: >> > >> >>>>> > >> > >> >>>>> > I don't see why we should force people to have a GitHub >> account, >> > >> >>>>> considering there are other means of logging into Gitter. >> > >> >>>>> >> > >> >>>>> Ok. >> > >> >>>>> >> > >> >>>>> > >> > >> >>>>> > As to getting the right type of people, I'm not sure it's >> > >> relevant. >> > >> >>>>> Most people are likely to have one, and those who don't are >> likely >> > >> to not >> > >> >>>>> have one for political reasons (think free software extremists) >> > >> rather than >> > >> >>>>> because they aren't tech savvy enough: while the "hibernate" >> naming >> > >> might >> > >> >>>>> confuse users looking for information about grizzly bears, I >> doubt >> > >> my >> > >> >>>>> grandmother, my 7-year-old nephew or even my >> non-software-engineer >> > >> of a >> > >> >>>>> wife would end up on Gitter by mistake. >> > >> >>>>> >> > >> >>>>> Well since that's obvious, clearly I was referring to a >> different >> > >> way >> > >> >>>>> of cathegorizing people joining@ not by age or expertise in >> > >> technology >> > >> >>>>> but in having reasonable expectations and willing to do some >> > >> research >> > >> >>>>> before bothering us all. >> > >> >>>>> >> > >> >>>>> You probably weren't around yet, but Hibernate has had hard >> times in >> > >> >>>>> which it was "victim of its own success": just too many >> > >> >>>>> kinda-interested people making a ton of basic questions that >> could >> > >> be >> > >> >>>>> easily solved otherwise. >> > >> >>>>> >> > >> >>>>> Some "barriers" we have in place have made it manageable; of >> course >> > >> I >> > >> >>>>> can't tell if it's all merit of the barriers of entry or just >> people >> > >> >>>>> coming in lower volumes with better intentions, but I'm >> confident >> > >> that >> > >> >>>>> some of the barriers we have have helped to keep some sanity >> (e.g. >> > >> >>>>> login on #hibernate-dev on IRC requiring an account). >> > >> >>>>> >> > >> >>>>> Assuming the new chat platform takes off, there's a risk it >> might be >> > >> >>>>> too successful as well. But I guess we'll see, or let's use a >> very >> > >> >>>>> bad chat platform so to keep people from coming :P >> > >> >>>>> >> > >> >>>>> > >> > >> >>>>> > >> > >> >>>>> > Yoann Rodi?re >> > >> >>>>> > Hibernate NoORM Team >> > >> >>>>> > yoann at hibernate.org >> > >> >>>>> > >> > >> >>>>> > >> > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < >> > >> sanne at hibernate.org> >> > >> >>>>> wrote: >> > >> >>>>> >> >> > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < >> > >> steve at hibernate.org> >> > >> >>>>> wrote: >> > >> >>>>> >> > >> > >> >>>>> >> > What is it a conscious decision to not require a GitHub >> account >> > >> >>>>> to join these rooms? I just noticed that is a toggle-option >> in the >> > >> room's >> > >> >>>>> settings also. >> > >> >>>>> >> >> > >> >>>>> >> I don't remember. We created these rooms as an experiment in >> > >> 2014.. >> > >> >>>>> >> Yoann created some more rooms recently. >> > >> >>>>> >> >> > >> >>>>> >> Should we enforce people to have a Github account? I'd like >> > >> that, I >> > >> >>>>> >> think it would better nudge towards getting the right type >> of >> > >> people >> > >> >>>>> >> to join. >> > >> >>>>> >> >> > >> >>>>> >> Thanks, >> > >> >>>>> >> Sanne >> > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> > >> > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < >> > >> >>>>> guillaume.smet at gmail.com> wrote: >> > >> >>>>> >> >> >> > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < >> > >> >>>>> sanne at hibernate.org> >> > >> >>>>> >> >> wrote: >> > >> >>>>> >> >> >> > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack >> is >> > >> the >> > >> >>>>> way to >> > >> >>>>> >> >> > go. Not saying we should go with Slack, just that >> we'll need >> > >> >>>>> to be >> > >> >>>>> >> >> > patient and we'll always be short of some features - if >> > >> that's >> > >> >>>>> not >> > >> >>>>> >> >> > acceptable then only Slack will make you happy. >> > >> >>>>> >> >> > >> > >> >>>>> >> >> >> > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for >> me >> > >> but >> > >> >>>>> yeah not >> > >> >>>>> >> >> having sound is really annoying. >> > >> >>>>> >> >> >> > >> >>>>> >> >> I might miss notifications from time to time. >> > >> >>>>> >> >> >> > >> >>>>> >> >> In any case, it will mostly be a problem for you all if >> you >> > >> ping >> > >> >>>>> me :). >> > >> >>>>> >> >> >> > >> >>>>> >> >> >> > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients >> > >> don't >> > >> >>>>> have >> > >> >>>>> >> >> > this specific problem.. might want to try that? >> > >> >>>>> >> >> > >> > >> >>>>> >> >> >> > >> >>>>> >> >> I prefer to have it in the browser where I do most of my >> > >> >>>>> interactions with >> > >> >>>>> >> >> people. >> > >> >>>>> >> >> >> > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb >> (and not >> > >> >>>>> very excited >> > >> >>>>> >> >> about compiling it). >> > >> >>>>> >> >> >> > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on >> it if >> > >> >>>>> they want to >> > >> >>>>> >> >> become a player in this area. They certainly have some >> work to >> > >> >>>>> do to catch >> > >> >>>>> >> >> up with others. >> > >> >>>>> >> >> >> > >> >>>>> >> >> -- >> > >> >>>>> >> >> Guillaume >> > >> >>>>> >> >> _______________________________________________ >> > >> >>>>> >> >> hibernate-dev mailing list >> > >> >>>>> >> >> hibernate-dev at lists.jboss.org >> > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >>>>> >> _______________________________________________ >> > >> >>>>> >> hibernate-dev mailing list >> > >> >>>>> >> hibernate-dev at lists.jboss.org >> > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >>>>> >> > >> >>>> >> > >> _______________________________________________ >> > >> hibernate-dev mailing list >> > >> hibernate-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From guillaume.smet at gmail.com Thu Dec 6 12:11:25 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 6 Dec 2018 18:11:25 +0100 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: Message-ID: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> > 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. We already reduced to the bare minimum the effort spent on 5.x. But answering users, reproducing their bugs and fixing them is not a waste of time. Even for 6 as that means we have a test case of something that?s validated as supposed to work. And it can also nourish the 6 design. > As you said in the previous paragraph, we're a small team and we can't > keep developing 2 branches of the same project. > > 5.x needs to be moved into strictly maintenance only, so please stop > pushing big changes to 5.x unless there's a very important reason You say that as if we pushed big changes to 5.x lately. That?s not the case. Now if you ask me if we should have a more strict bug fix only policy on 5.x, I couldn?t agree more. That?s what I asked for the CR. I wanted it to be even more strict for CR = only regressions from 5.3. Couldn?t get it to be respected though. ? Guillaume From guillaume.smet at gmail.com Thu Dec 6 13:36:51 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 6 Dec 2018 19:36:51 +0100 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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 of the others. That means: - asking for test cases if there is not - check the test case and validate it's a bug, it's not always obvious - decide if we want to fix it == What to do then There are a couple of options: 1/ no workaround, then we should consider it for 5.x 2/ there is a viable workaround, we can postpone it to 6, but we definitely would need to have something to mark them as we need to fix them (a version, maybe, or a tag?) - one thing is that it would probably be a good idea to categorize things a bit because when you revisit something for 6, it would be a good idea to have the existing bugs in mind as it could influence the design. * if it's something we want to fix in 6, there might be several options: 2.1/ we can already fix it in 6 because the features are already implemented 2.2/ we can't fix it right now IMHO, we should start considering taking into account 2.1/ into the daily work for 6 if we want to make this work as otherwise we will end up with a very big pile of bugs when 6 finally gets finalized. As for 2.2/, we should really have a way to keep track of them and push them to case 2.1/ when we can. Note that it's the same case if it's more an improvement but we consider it as something we want: if we want it, we should find a way to keep track of it somehow. That also means that we would need someone familiar with 6 to help triaging the issues. IMHO, this can be done once a week, if done regularly and steadily. If we continue fixing bugs, even in 6 only, that still says to the contributor "we hear you, we are improving". If we just stop fixing bugs until 6 is more or less feature-complete, then we send a very bad message IMHO. And we will end up with a pile of unfixed issues in the bugtracker that we won't really be able to deal with. And less users. The very important thing IMHO is "taking into account 2.1/ into the daily work for 6". That means 6 development should also include bug fixing of incoming bugs, not only implement missing features. -- Guillaume On Thu, Dec 6, 2018 at 6:11 PM Guillaume Smet wrote: > > > > 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. > > We already reduced to the bare minimum the effort spent on 5.x. > > But answering users, reproducing their bugs and fixing them is not a waste > of time. > > Even for 6 as that means we have a test case of something that?s validated > as supposed to work. > > And it can also nourish the 6 design. > > > As you said in the previous paragraph, we're a small team and we can't > > keep developing 2 branches of the same project. > > > > 5.x needs to be moved into strictly maintenance only, so please stop > > pushing big changes to 5.x unless there's a very important reason > > You say that as if we pushed big changes to 5.x lately. > > That?s not the case. > > Now if you ask me if we should have a more strict bug fix only policy on > 5.x, I couldn?t agree more. > > That?s what I asked for the CR. I wanted it to be even more strict for CR > = only regressions from 5.3. > > Couldn?t get it to be respected though. > > ? > Guillaume > > > From steve at hibernate.org Thu Dec 6 14:56:27 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Dec 2018 13:56:27 -0600 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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. Either it is no longer a problem or because we port the fix from 5 to 6. Not saying exactly how that happens - just that that needs to be the end result. > 2/ there is a viable workaround, we can postpone it to 6, but we > definitely would need to have something to mark them as we need to fix them > (a version, maybe, or a tag?) - one thing is that it would probably be a > good idea to categorize things a bit because when you revisit something for > 6, it would be a good idea to have the existing bugs in mind as it could > influence the design. > Using a tag seems enticing, but experience tells me that won't really have the effect I think you want. > * if it's something we want to fix in 6, there might be several options: > 2.1/ we can already fix it in 6 because the features are already > implemented > 2.2/ we can't fix it right now > > IMHO, we should start considering taking into account 2.1/ into the daily > work for 6 if we want to make this work as otherwise we will end up with a > very big pile of bugs when 6 finally gets finalized. > > > As for 2.2/, we should really have a way to keep track of them and push > them to case 2.1/ when we can. Note that it's the same case if it's more an > improvement but we consider it as something we want: if we want it, we > should find a way to keep track of it somehow. > > That also means that we would need someone familiar with 6 to help > triaging the issues. IMHO, this can be done once a week, if done regularly > and steadily. > > If we continue fixing bugs, even in 6 only, that still says to the > contributor "we hear you, we are improving". If we just stop fixing bugs > until 6 is more or less feature-complete, then we send a very bad message > IMHO. And we will end up with a pile of unfixed issues in the bugtracker > that we won't really be able to deal with. And less users. > Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the 37th issue ever since we moved to Jira. We *do* keep improving ;) And that's just one of the many. But yes your point is valid. It is very important to keep fixing bugs. From steve at hibernate.org Fri Dec 7 07:15:30 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 7 Dec 2018 06:15:30 -0600 Subject: [hibernate-dev] Hibernate ORM 6.0.0.Alpha1 Message-ID: We have released the first Alpha for ORM version 6.0 - http://in.relation.to/2018/12/06/hibernate-orm-600-alpha1-out/ From sanne at hibernate.org Fri Dec 7 08:04:35 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 7 Dec 2018 13:04:35 +0000 Subject: [hibernate-dev] [hibernate-announce] Hibernate ORM 6.0.0.Alpha1 In-Reply-To: References: Message-ID: Congratulations !! On Fri, 7 Dec 2018 at 12:31, Steve Ebersole wrote: > > We have released the first Alpha for ORM version 6.0 - > http://in.relation.to/2018/12/06/hibernate-orm-600-alpha1-out/ > _______________________________________________ > hibernate-announce mailing list > hibernate-announce at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-announce From gbadner at redhat.com Mon Dec 10 18:12:27 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 10 Dec 2018 15:12:27 -0800 Subject: [hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level? In-Reply-To: <8422282b-befe-63e8-13a0-8afc185a88ab@redhat.com> References: <8422282b-befe-63e8-13a0-8afc185a88ab@redhat.com> Message-ID: Hi Scott, I see that the issue is resolved and your commit is merged. Is this no longer an issue? Thanks, Gail On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow wrote: > Hi, > > I started working on a WildFly change WFLY-11243 [1] to cache the > TransactionSynchronizationRegistry inside of the WildFly JtaPlatform > instance. The purpose of caching the TransactionSynchronizationRegistry > is to avoid repeated JndiService.locate() calls, like during entity > manager creation time [2] and other uses as well. > > My question is whether the idea of caching the > TransactionSynchronizationRegistry instance is already handled at the > session factory level? If not, would that make sense? > > [3] is the WildFly pr to cache the TransactionSynchronizationRegistry > instance, to avoid repeatedly looking it up (since it rarely ever > changes). If there is a way to instead have the > TransactionSynchronizationRegistry cached at the SF level, that might be > better. > > Scott > > [1] https://issues.jboss.org/browse/WFLY-11243 > [2] https://paste.fedoraproject.org/paste/kXHq27RpSSs8GS8v0S8Dog > [3] https://github.com/wildfly/wildfly/pull/11784 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Tue Dec 11 02:43:52 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 11 Dec 2018 08:43:52 +0100 Subject: [hibernate-dev] Created a Jenkins job to publish Snapshot artifacts for ORM 6.0 Message-ID: Hello, Last time we discussed it, it seemed there wasn't any automatic job regularly publishing ORM 6.0 snapshot artifacts; right now I can see that the latest snapshot was published on December 5th by Steve himself (not Jenkins); probably while performing tests for the 6.0.0.Alpha1 release? So I just created a Jenkins job to publish Snapshot artifacts for ORM 6.0: http://ci.hibernate.org/view/ORM/job/hibernate-orm-6.0-h2-main/ It's just a copy of hibernate-orm-master-h2-main with the branch changed to wip/6.0 and a one-build-per-hour throttle added (we may remove that if you want). For now the job is disabled. Steve, do you agree with publishing snapshot artifacts? Can I enable this job? Do I have to add specific options (ignore some tests, some modules, ...) to the gradle command in order for the build to pass? Do you want me to disable build failure notifications? Snapshots would come in handy to test Hibernate Search 6.0 against ORM 6.0. For now Search 6 is still using ORM 5.4, because a lot of Search's tests need association types that are not yet supported in 6, but I'd like to keep track of progress made on ORM 6 so I can react if further incompatibilities arise. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From smarlow at redhat.com Tue Dec 11 08:21:24 2018 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 11 Dec 2018 08:21:24 -0500 Subject: [hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level? In-Reply-To: References: <8422282b-befe-63e8-13a0-8afc185a88ab@redhat.com> Message-ID: Hi Gail, Yes, WFLY-11243 [1] is caching TransactionSynchronizationRegistry at the WildFly level, which is great for WildFly applications but other platforms might benefit from one of the following: A. Reducing the number of Hibernate ORM calls to JndiService#locate (the TransactionSynchronizationRegistry). In a WildFly 15 container managed persistence context/EntityManager, I saw that every call to EntityManager.find() in a new JTA transaction, required a call to JndiService#locate (from pulse()). This will be worked around in WildFly 16, via [1], to avoid the call to JndiService#locate. B. Or could/should we cache the TransactionSynchronizationRegistry in the SessionFactory? Which is my open question still. Apologies for the bad [2] link, I'm not sure why that is now invalid, next time I will use a gist link. Scott On 12/10/18 6:12 PM, Gail Badner wrote: > Hi Scott, > > I see that the issue is resolved and your commit is merged. Is this no > longer an issue? > > Thanks, > Gail > > On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow > wrote: > > Hi, > > I started working on a WildFly change WFLY-11243 [1] to cache the > TransactionSynchronizationRegistry inside of the WildFly JtaPlatform > instance.? The purpose of caching the > TransactionSynchronizationRegistry > is to avoid repeated JndiService.locate() calls, like during entity > manager creation time [2] and other uses as well. > > My question is whether the idea of caching the > TransactionSynchronizationRegistry instance is already handled at the > session factory level?? If not, would that make sense? > > [3] is the WildFly pr to cache the TransactionSynchronizationRegistry > instance, to avoid repeatedly looking it up (since it rarely ever > changes).? If there is a way to instead have the > TransactionSynchronizationRegistry cached at the SF level, that > might be > better. > > Scott > > [1] https://issues.jboss.org/browse/WFLY-11243 > [2] https://paste.fedoraproject.org/paste/kXHq27RpSSs8GS8v0S8Dog > [3] https://github.com/wildfly/wildfly/pull/11784 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Dec 11 16:28:38 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 11 Dec 2018 22:28:38 +0100 Subject: [hibernate-dev] Releasing ORM 5.4.0.Final tomorrow Message-ID: Hi, FYI, I will release ORM 5.4.0.Final tomorrow afternoon my time. Please don't merge any last minute changes as I won't have the time to deal with potential issues. Thanks. -- Guillaume From steve at hibernate.org Tue Dec 11 21:38:29 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Dec 2018 20:38:29 -0600 Subject: [hibernate-dev] Created a Jenkins job to publish Snapshot artifacts for ORM 6.0 In-Reply-To: References: Message-ID: It is definitely time to do this, so thanks for taking the initiative. The build scripts themselves already manage enabling/disabling everything that needs to be. I took a quick look at the job earlier and it looked great. Personally I would enable notifications. Tomorrow I can go through the job config and tweak all of this if you want. On Tue, Dec 11, 2018, 1:44 AM Yoann Rodiere wrote: > Hello, > > Last time we discussed it, it seemed there wasn't any automatic job > regularly publishing ORM 6.0 snapshot artifacts; right now I can see that > the latest snapshot was published on December 5th by Steve himself (not > Jenkins); probably while performing tests for the 6.0.0.Alpha1 release? > > So I just created a Jenkins job to publish Snapshot artifacts for ORM 6.0: > > http://ci.hibernate.org/view/ORM/job/hibernate-orm-6.0-h2-main/ > > It's just a copy of hibernate-orm-master-h2-main with the branch changed to > wip/6.0 and a one-build-per-hour throttle added (we may remove that if you > want). > > For now the job is disabled. Steve, do you agree with publishing snapshot > artifacts? Can I enable this job? Do I have to add specific options (ignore > some tests, some modules, ...) to the gradle command in order for the build > to pass? Do you want me to disable build failure notifications? > > Snapshots would come in handy to test Hibernate Search 6.0 against ORM 6.0. > For now Search 6 is still using ORM 5.4, because a lot of Search's tests > need association types that are not yet supported in 6, but I'd like to > keep track of progress made on ORM 6 so I can react if further > incompatibilities arise. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Wed Dec 12 03:17:35 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 12 Dec 2018 09:17:35 +0100 Subject: [hibernate-dev] Created a Jenkins job to publish Snapshot artifacts for ORM 6.0 In-Reply-To: References: Message-ID: Ok, I enabled the job and started a build. It passed and the snapshots were deployed as expected. Feel free to change the details of the job configuration whenever you want :) Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Wed, 12 Dec 2018 at 03:38, Steve Ebersole wrote: > It is definitely time to do this, so thanks for taking the initiative. > The build scripts themselves already manage enabling/disabling everything > that needs to be. I took a quick look at the job earlier and it looked > great. > > Personally I would enable notifications. Tomorrow I can go through the > job config and tweak all of this if you want. > > > On Tue, Dec 11, 2018, 1:44 AM Yoann Rodiere wrote: > >> Hello, >> >> Last time we discussed it, it seemed there wasn't any automatic job >> regularly publishing ORM 6.0 snapshot artifacts; right now I can see that >> the latest snapshot was published on December 5th by Steve himself (not >> Jenkins); probably while performing tests for the 6.0.0.Alpha1 release? >> >> So I just created a Jenkins job to publish Snapshot artifacts for ORM 6.0: >> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-6.0-h2-main/ >> >> It's just a copy of hibernate-orm-master-h2-main with the branch changed >> to >> wip/6.0 and a one-build-per-hour throttle added (we may remove that if you >> want). >> >> For now the job is disabled. Steve, do you agree with publishing snapshot >> artifacts? Can I enable this job? Do I have to add specific options >> (ignore >> some tests, some modules, ...) to the gradle command in order for the >> build >> to pass? Do you want me to disable build failure notifications? >> >> Snapshots would come in handy to test Hibernate Search 6.0 against ORM >> 6.0. >> For now Search 6 is still using ORM 5.4, because a lot of Search's tests >> need association types that are not yet supported in 6, but I'd like to >> keep track of progress made on ORM 6 so I can react if further >> incompatibilities arise. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Wed Dec 12 07:45:51 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 12 Dec 2018 06:45:51 -0600 Subject: [hibernate-dev] Created a Jenkins job to publish Snapshot artifacts for ORM 6.0 In-Reply-To: References: Message-ID: Awesome, thanks! On Wed, Dec 12, 2018, 2:17 AM Yoann Rodiere wrote: > Ok, I enabled the job and started a build. It passed and the snapshots > were deployed as expected. Feel free to change the details of the job > configuration whenever you want :) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Wed, 12 Dec 2018 at 03:38, Steve Ebersole wrote: > >> It is definitely time to do this, so thanks for taking the initiative. >> The build scripts themselves already manage enabling/disabling everything >> that needs to be. I took a quick look at the job earlier and it looked >> great. >> >> Personally I would enable notifications. Tomorrow I can go through the >> job config and tweak all of this if you want. >> >> >> On Tue, Dec 11, 2018, 1:44 AM Yoann Rodiere wrote: >> >>> Hello, >>> >>> Last time we discussed it, it seemed there wasn't any automatic job >>> regularly publishing ORM 6.0 snapshot artifacts; right now I can see >>> that >>> the latest snapshot was published on December 5th by Steve himself (not >>> Jenkins); probably while performing tests for the 6.0.0.Alpha1 release? >>> >>> So I just created a Jenkins job to publish Snapshot artifacts for ORM >>> 6.0: >>> >>> http://ci.hibernate.org/view/ORM/job/hibernate-orm-6.0-h2-main/ >>> >>> It's just a copy of hibernate-orm-master-h2-main with the branch changed >>> to >>> wip/6.0 and a one-build-per-hour throttle added (we may remove that if >>> you >>> want). >>> >>> For now the job is disabled. Steve, do you agree with publishing snapshot >>> artifacts? Can I enable this job? Do I have to add specific options >>> (ignore >>> some tests, some modules, ...) to the gradle command in order for the >>> build >>> to pass? Do you want me to disable build failure notifications? >>> >>> Snapshots would come in handy to test Hibernate Search 6.0 against ORM >>> 6.0. >>> For now Search 6 is still using ORM 5.4, because a lot of Search's tests >>> need association types that are not yet supported in 6, but I'd like to >>> keep track of progress made on ORM 6 so I can react if further >>> incompatibilities arise. >>> >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> From guillaume.smet at gmail.com Wed Dec 12 10:46:58 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 12 Dec 2018 16:46:58 +0100 Subject: [hibernate-dev] Releasing ORM 5.4.0.Final tomorrow In-Reply-To: References: Message-ID: Got sidetracked by other things. Will push the release tonight and announce tomorrow. -- Guillaume On Tue, Dec 11, 2018 at 10:28 PM Guillaume Smet wrote: > Hi, > > FYI, I will release ORM 5.4.0.Final tomorrow afternoon my time. > > Please don't merge any last minute changes as I won't have the time to > deal with potential issues. > > Thanks. > > -- > Guillaume > From steve at hibernate.org Wed Dec 12 11:15:55 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 12 Dec 2018 10:15:55 -0600 Subject: [hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level? In-Reply-To: References: <8422282b-befe-63e8-13a0-8afc185a88ab@redhat.com> Message-ID: Scott, if you take a look at the JtaPlatform impls they do in fact cache (configurable) either the TM or UT. I am like 90% sure I did not cache the TSR because you told me not to (you are the one who asked for JTA integration via TSR). If it is no longer the case that that should not be cached, then feel free to cache it. On Tue, Dec 11, 2018 at 7:23 AM Scott Marlow wrote: > Hi Gail, > > Yes, WFLY-11243 [1] is caching TransactionSynchronizationRegistry at the > WildFly level, which is great for WildFly applications but other > platforms might benefit from one of the following: > > A. Reducing the number of Hibernate ORM calls to JndiService#locate > (the TransactionSynchronizationRegistry). In a WildFly 15 container > managed persistence context/EntityManager, I saw that every call to > EntityManager.find() in a new JTA transaction, required a call to > JndiService#locate (from pulse()). This will be worked around in > WildFly 16, via [1], to avoid the call to JndiService#locate. > > B. Or could/should we cache the TransactionSynchronizationRegistry in > the SessionFactory? Which is my open question still. > > Apologies for the bad [2] link, I'm not sure why that is now invalid, > next time I will use a gist link. > > Scott > > On 12/10/18 6:12 PM, Gail Badner wrote: > > Hi Scott, > > > > I see that the issue is resolved and your commit is merged. Is this no > > longer an issue? > > > > Thanks, > > Gail > > > > On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow > > wrote: > > > > Hi, > > > > I started working on a WildFly change WFLY-11243 [1] to cache the > > TransactionSynchronizationRegistry inside of the WildFly JtaPlatform > > instance. The purpose of caching the > > TransactionSynchronizationRegistry > > is to avoid repeated JndiService.locate() calls, like during entity > > manager creation time [2] and other uses as well. > > > > My question is whether the idea of caching the > > TransactionSynchronizationRegistry instance is already handled at the > > session factory level? If not, would that make sense? > > > > [3] is the WildFly pr to cache the TransactionSynchronizationRegistry > > instance, to avoid repeatedly looking it up (since it rarely ever > > changes). If there is a way to instead have the > > TransactionSynchronizationRegistry cached at the SF level, that > > might be > > better. > > > > Scott > > > > [1] https://issues.jboss.org/browse/WFLY-11243 > > [2] https://paste.fedoraproject.org/paste/kXHq27RpSSs8GS8v0S8Dog > > [3] https://github.com/wildfly/wildfly/pull/11784 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Dec 12 16:52:07 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 12 Dec 2018 22:52:07 +0100 Subject: [hibernate-dev] Releasing ORM 5.4.0.Final tomorrow In-Reply-To: References: Message-ID: I started the release process 30 minutes ago but the bintrayPublish task is taking far longer than usual. Please do not push anything to master until I confirm the release is complete. Thanks. -- Guillaume On Wed, Dec 12, 2018 at 4:46 PM Guillaume Smet wrote: > Got sidetracked by other things. > > Will push the release tonight and announce tomorrow. > > -- > Guillaume > > On Tue, Dec 11, 2018 at 10:28 PM Guillaume Smet > wrote: > >> Hi, >> >> FYI, I will release ORM 5.4.0.Final tomorrow afternoon my time. >> >> Please don't merge any last minute changes as I won't have the time to >> deal with potential issues. >> >> Thanks. >> >> -- >> Guillaume >> > From steve at hibernate.org Wed Dec 12 17:09:24 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 12 Dec 2018 16:09:24 -0600 Subject: [hibernate-dev] Releasing ORM 5.4.0.Final tomorrow In-Reply-To: References: Message-ID: The same happened to me releasing the 6.0 Alpha. If I had to guess it's related to the attempt to auto-publish to Central. That was my first thought anyway. We should maybe disable that since it does not work anyway. On Wed, Dec 12, 2018, 4:01 PM Guillaume Smet wrote: > I started the release process 30 minutes ago but the bintrayPublish task is > taking far longer than usual. > > Please do not push anything to master until I confirm the release is > complete. > > Thanks. > > -- > Guillaume > > > On Wed, Dec 12, 2018 at 4:46 PM Guillaume Smet > wrote: > > > Got sidetracked by other things. > > > > Will push the release tonight and announce tomorrow. > > > > -- > > Guillaume > > > > On Tue, Dec 11, 2018 at 10:28 PM Guillaume Smet < > guillaume.smet at gmail.com> > > wrote: > > > >> Hi, > >> > >> FYI, I will release ORM 5.4.0.Final tomorrow afternoon my time. > >> > >> Please don't merge any last minute changes as I won't have the time to > >> deal with potential issues. > >> > >> Thanks. > >> > >> -- > >> Guillaume > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Dec 12 17:23:21 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 12 Dec 2018 23:23:21 +0100 Subject: [hibernate-dev] Releasing ORM 5.4.0.Final tomorrow In-Reply-To: References: Message-ID: Yeah it would be a good idea to remove it. Anyway, it finally got unstuck and I pushed the commits and the tag. Master is open again. The upload to SF.net is still in progress though. On Wed, Dec 12, 2018 at 11:09 PM Steve Ebersole wrote: > The same happened to me releasing the 6.0 Alpha. If I had to guess it's > related to the attempt to auto-publish to Central. That was my first > thought anyway. We should maybe disable that since it does not work anyway. > > > On Wed, Dec 12, 2018, 4:01 PM Guillaume Smet > wrote: > >> I started the release process 30 minutes ago but the bintrayPublish task >> is >> taking far longer than usual. >> >> Please do not push anything to master until I confirm the release is >> complete. >> >> Thanks. >> >> -- >> Guillaume >> >> >> On Wed, Dec 12, 2018 at 4:46 PM Guillaume Smet >> wrote: >> >> > Got sidetracked by other things. >> > >> > Will push the release tonight and announce tomorrow. >> > >> > -- >> > Guillaume >> > >> > On Tue, Dec 11, 2018 at 10:28 PM Guillaume Smet < >> guillaume.smet at gmail.com> >> > wrote: >> > >> >> Hi, >> >> >> >> FYI, I will release ORM 5.4.0.Final tomorrow afternoon my time. >> >> >> >> Please don't merge any last minute changes as I won't have the time to >> >> deal with potential issues. >> >> >> >> Thanks. >> >> >> >> -- >> >> Guillaume >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at hibernate.org Thu Dec 13 06:56:28 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 13 Dec 2018 12:56:28 +0100 Subject: [hibernate-dev] Hibernate ORM 5.4.0.Final released Message-ID: Hi, We just released Hibernate ORM 5.4.0.Final after two candidate releases. Thanks to everyone involved in testing the CRs, that was very helpful. The idea behind 5.4 is to be a drop-in replacement of 5.3.x so please consider moving to this version as 5.3.x will only receive critical bugfixes. You can find the full announcement on our blog: http://in.relation.to/2018/12/12/hibernate-orm-540-final-out/ . Have a nice day! -- Guillaume From guillaume.smet at gmail.com Thu Dec 13 11:08:46 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 13 Dec 2018 17:08:46 +0100 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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 should be Gail for 5.x + whoever volunteers for the 6 part. On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole wrote: > 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. Either it is no > longer a problem or because we port the fix from 5 to 6. Not saying > exactly how that happens - just that that needs to be the end result. > > > >> 2/ there is a viable workaround, we can postpone it to 6, but we >> definitely would need to have something to mark them as we need to fix them >> (a version, maybe, or a tag?) - one thing is that it would probably be a >> good idea to categorize things a bit because when you revisit something for >> 6, it would be a good idea to have the existing bugs in mind as it could >> influence the design. >> > > Using a tag seems enticing, but experience tells me that won't really have > the effect I think you want. > > > >> * if it's something we want to fix in 6, there might be several options: >> 2.1/ we can already fix it in 6 because the features are already >> implemented >> 2.2/ we can't fix it right now >> >> IMHO, we should start considering taking into account 2.1/ into the daily >> work for 6 if we want to make this work as otherwise we will end up with a >> very big pile of bugs when 6 finally gets finalized. >> > > >> >> As for 2.2/, we should really have a way to keep track of them and push >> them to case 2.1/ when we can. Note that it's the same case if it's more an >> improvement but we consider it as something we want: if we want it, we >> should find a way to keep track of it somehow. >> >> That also means that we would need someone familiar with 6 to help >> triaging the issues. IMHO, this can be done once a week, if done regularly >> and steadily. >> >> If we continue fixing bugs, even in 6 only, that still says to the >> contributor "we hear you, we are improving". If we just stop fixing bugs >> until 6 is more or less feature-complete, then we send a very bad message >> IMHO. And we will end up with a pile of unfixed issues in the bugtracker >> that we won't really be able to deal with. And less users. >> > > Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the 37th > issue ever since we moved to Jira. We *do* keep improving ;) And that's > just one of the many. > > But yes your point is valid. It is very important to keep fixing bugs. > From steve at hibernate.org Thu Dec 13 11:52:41 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 13 Dec 2018 10:52:41 -0600 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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 to 6 - most of the time, I'd expect to just apply those changes myself (or Andrea or Chris). I think a meeting is a good idea On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet wrote: > 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 > should be Gail for 5.x + whoever volunteers for the 6 part. > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole wrote: > >> 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. Either it is >> no longer a problem or because we port the fix from 5 to 6. Not saying >> exactly how that happens - just that that needs to be the end result. >> >> >> >>> 2/ there is a viable workaround, we can postpone it to 6, but we >>> definitely would need to have something to mark them as we need to fix them >>> (a version, maybe, or a tag?) - one thing is that it would probably be a >>> good idea to categorize things a bit because when you revisit something for >>> 6, it would be a good idea to have the existing bugs in mind as it could >>> influence the design. >>> >> >> Using a tag seems enticing, but experience tells me that won't really >> have the effect I think you want. >> >> >> >>> * if it's something we want to fix in 6, there might be several options: >>> 2.1/ we can already fix it in 6 because the features are already >>> implemented >>> 2.2/ we can't fix it right now >>> >>> IMHO, we should start considering taking into account 2.1/ into the >>> daily work for 6 if we want to make this work as otherwise we will end up >>> with a very big pile of bugs when 6 finally gets finalized. >>> >> >> >>> >>> As for 2.2/, we should really have a way to keep track of them and push >>> them to case 2.1/ when we can. Note that it's the same case if it's more an >>> improvement but we consider it as something we want: if we want it, we >>> should find a way to keep track of it somehow. >>> >>> That also means that we would need someone familiar with 6 to help >>> triaging the issues. IMHO, this can be done once a week, if done regularly >>> and steadily. >>> >>> If we continue fixing bugs, even in 6 only, that still says to the >>> contributor "we hear you, we are improving". If we just stop fixing bugs >>> until 6 is more or less feature-complete, then we send a very bad message >>> IMHO. And we will end up with a pile of unfixed issues in the bugtracker >>> that we won't really be able to deal with. And less users. >>> >> >> Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the 37th >> issue ever since we moved to Jira. We *do* keep improving ;) And that's >> just one of the many. >> >> But yes your point is valid. It is very important to keep fixing bugs. >> > From andrea at hibernate.org Fri Dec 14 03:26:55 2018 From: andrea at hibernate.org (andrea boriero) Date: Fri, 14 Dec 2018 08:26:55 +0000 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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 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 to 6 - most of the time, I'd expect to just apply those changes > myself (or Andrea or Chris). > > I think a meeting is a good idea > > On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet > wrote: > > > 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 > > should be Gail for 5.x + whoever volunteers for the 6 part. > > > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole > wrote: > > > >> I completely agree with everything you say. A few thoughts in-line... > >> > >> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet < > guillaume.smet at gmail.com> > >> 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. Either it is > >> no longer a problem or because we port the fix from 5 to 6. Not saying > >> exactly how that happens - just that that needs to be the end result. > >> > >> > >> > >>> 2/ there is a viable workaround, we can postpone it to 6, but we > >>> definitely would need to have something to mark them as we need to fix > them > >>> (a version, maybe, or a tag?) - one thing is that it would probably be > a > >>> good idea to categorize things a bit because when you revisit > something for > >>> 6, it would be a good idea to have the existing bugs in mind as it > could > >>> influence the design. > >>> > >> > >> Using a tag seems enticing, but experience tells me that won't really > >> have the effect I think you want. > >> > >> > >> > >>> * if it's something we want to fix in 6, there might be several > options: > >>> 2.1/ we can already fix it in 6 because the features are already > >>> implemented > >>> 2.2/ we can't fix it right now > >>> > >>> IMHO, we should start considering taking into account 2.1/ into the > >>> daily work for 6 if we want to make this work as otherwise we will end > up > >>> with a very big pile of bugs when 6 finally gets finalized. > >>> > >> > >> > >>> > >>> As for 2.2/, we should really have a way to keep track of them and push > >>> them to case 2.1/ when we can. Note that it's the same case if it's > more an > >>> improvement but we consider it as something we want: if we want it, we > >>> should find a way to keep track of it somehow. > >>> > >>> That also means that we would need someone familiar with 6 to help > >>> triaging the issues. IMHO, this can be done once a week, if done > regularly > >>> and steadily. > >>> > >>> If we continue fixing bugs, even in 6 only, that still says to the > >>> contributor "we hear you, we are improving". If we just stop fixing > bugs > >>> until 6 is more or less feature-complete, then we send a very bad > message > >>> IMHO. And we will end up with a pile of unfixed issues in the > bugtracker > >>> that we won't really be able to deal with. And less users. > >>> > >> > >> Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the > 37th > >> issue ever since we moved to Jira. We *do* keep improving ;) And > that's > >> just one of the many. > >> > >> But yes your point is valid. It is very important to keep fixing bugs. > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rory.odonnell at oracle.com Fri Dec 14 05:36:45 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 14 Dec 2018 10:36:45 +0000 Subject: [hibernate-dev] JDK 12 enters Rampdown Phase One Message-ID: Hi Sanne, *JDK 12 Early Access build **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o We?ve forked the main-line source repository, jdk/jdk, to the JDK 12 stabilization repository. Changes since the last availability email * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) ?moved to *Targeted*. * JEP 334: JVM Constants API ?moved to *Targeted*. * JEP 344: Abortable Mixed Collections for G1 ?moved? to *Targeted*. * JEP 346: Promptly Return Unused Committed Memory from G1 to *Targeted*. * JEP 326: Raw String Literals (Preview) *Proposed to drop from JDK 12* o link to proposal on jdk-dev Bug fixes reported by Open Source Projects? : o JDK-8211051 - fixed in b22 - reported by JUnit5 o JDK-8211422 - fixed in b23 - reported by Apache Batik The Java Crypto Roadmap ?has been updated with the following target: * With the 2019-04-16 CPU, o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7 o Distrust TLS server certificates anchored by Symantec Root CAs. Oracle Java SE 8 Release Updates [3] * Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license. Rgds, Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html [3] https://java.com/en/download/release_notice.jsp -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From daltodavide at gmail.com Fri Dec 14 06:02:01 2018 From: daltodavide at gmail.com (Davide D'Alto) Date: Fri, 14 Dec 2018 11:02:01 +0000 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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 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 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 to 6 - most of the time, I'd expect to just apply those changes > > myself (or Andrea or Chris). > > > > I think a meeting is a good idea > > > > On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet > > wrote: > > > > > 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 > > > should be Gail for 5.x + whoever volunteers for the 6 part. > > > > > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole > > wrote: > > > > > >> I completely agree with everything you say. A few thoughts in-line... > > >> > > >> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet < > > guillaume.smet at gmail.com> > > >> 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. Either it is > > >> no longer a problem or because we port the fix from 5 to 6. Not saying > > >> exactly how that happens - just that that needs to be the end result. > > >> > > >> > > >> > > >>> 2/ there is a viable workaround, we can postpone it to 6, but we > > >>> definitely would need to have something to mark them as we need to fix > > them > > >>> (a version, maybe, or a tag?) - one thing is that it would probably be > > a > > >>> good idea to categorize things a bit because when you revisit > > something for > > >>> 6, it would be a good idea to have the existing bugs in mind as it > > could > > >>> influence the design. > > >>> > > >> > > >> Using a tag seems enticing, but experience tells me that won't really > > >> have the effect I think you want. > > >> > > >> > > >> > > >>> * if it's something we want to fix in 6, there might be several > > options: > > >>> 2.1/ we can already fix it in 6 because the features are already > > >>> implemented > > >>> 2.2/ we can't fix it right now > > >>> > > >>> IMHO, we should start considering taking into account 2.1/ into the > > >>> daily work for 6 if we want to make this work as otherwise we will end > > up > > >>> with a very big pile of bugs when 6 finally gets finalized. > > >>> > > >> > > >> > > >>> > > >>> As for 2.2/, we should really have a way to keep track of them and push > > >>> them to case 2.1/ when we can. Note that it's the same case if it's > > more an > > >>> improvement but we consider it as something we want: if we want it, we > > >>> should find a way to keep track of it somehow. > > >>> > > >>> That also means that we would need someone familiar with 6 to help > > >>> triaging the issues. IMHO, this can be done once a week, if done > > regularly > > >>> and steadily. > > >>> > > >>> If we continue fixing bugs, even in 6 only, that still says to the > > >>> contributor "we hear you, we are improving". If we just stop fixing > > bugs > > >>> until 6 is more or less feature-complete, then we send a very bad > > message > > >>> IMHO. And we will end up with a pile of unfixed issues in the > > bugtracker > > >>> that we won't really be able to deal with. And less users. > > >>> > > >> > > >> Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the > > 37th > > >> issue ever since we moved to Jira. We *do* keep improving ;) And > > that's > > >> just one of the many. > > >> > > >> But yes your point is valid. It is very important to keep fixing bugs. > > >> > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Fri Dec 14 06:04:13 2018 From: davide at hibernate.org (Davide D'Alto) Date: Fri, 14 Dec 2018 11:04:13 +0000 Subject: [hibernate-dev] master and 6.0 branch In-Reply-To: References: <615CCB6B-57D2-4179-8200-4394773E58B9@gmail.com> Message-ID: 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, 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 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 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 to 6 - most of the time, I'd expect to just apply those changes > > > myself (or Andrea or Chris). > > > > > > I think a meeting is a good idea > > > > > > On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet > > > wrote: > > > > > > > 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 > > > > should be Gail for 5.x + whoever volunteers for the 6 part. > > > > > > > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole > > > wrote: > > > > > > > >> I completely agree with everything you say. A few thoughts in-line... > > > >> > > > >> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet < > > > guillaume.smet at gmail.com> > > > >> 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. Either it is > > > >> no longer a problem or because we port the fix from 5 to 6. Not saying > > > >> exactly how that happens - just that that needs to be the end result. > > > >> > > > >> > > > >> > > > >>> 2/ there is a viable workaround, we can postpone it to 6, but we > > > >>> definitely would need to have something to mark them as we need to fix > > > them > > > >>> (a version, maybe, or a tag?) - one thing is that it would probably be > > > a > > > >>> good idea to categorize things a bit because when you revisit > > > something for > > > >>> 6, it would be a good idea to have the existing bugs in mind as it > > > could > > > >>> influence the design. > > > >>> > > > >> > > > >> Using a tag seems enticing, but experience tells me that won't really > > > >> have the effect I think you want. > > > >> > > > >> > > > >> > > > >>> * if it's something we want to fix in 6, there might be several > > > options: > > > >>> 2.1/ we can already fix it in 6 because the features are already > > > >>> implemented > > > >>> 2.2/ we can't fix it right now > > > >>> > > > >>> IMHO, we should start considering taking into account 2.1/ into the > > > >>> daily work for 6 if we want to make this work as otherwise we will end > > > up > > > >>> with a very big pile of bugs when 6 finally gets finalized. > > > >>> > > > >> > > > >> > > > >>> > > > >>> As for 2.2/, we should really have a way to keep track of them and push > > > >>> them to case 2.1/ when we can. Note that it's the same case if it's > > > more an > > > >>> improvement but we consider it as something we want: if we want it, we > > > >>> should find a way to keep track of it somehow. > > > >>> > > > >>> That also means that we would need someone familiar with 6 to help > > > >>> triaging the issues. IMHO, this can be done once a week, if done > > > regularly > > > >>> and steadily. > > > >>> > > > >>> If we continue fixing bugs, even in 6 only, that still says to the > > > >>> contributor "we hear you, we are improving". If we just stop fixing > > > bugs > > > >>> until 6 is more or less feature-complete, then we send a very bad > > > message > > > >>> IMHO. And we will end up with a pile of unfixed issues in the > > > bugtracker > > > >>> that we won't really be able to deal with. And less users. > > > >>> > > > >> > > > >> Alpha1 just released the fix for HHH-37. Yep, that's right 37 - the > > > 37th > > > >> issue ever since we moved to Jira. We *do* keep improving ;) And > > > that's > > > >> just one of the many. > > > >> > > > >> But yes your point is valid. It is very important to keep fixing bugs. > > > >> > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Tue Dec 18 11:45:28 2018 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 18 Dec 2018 16:45:28 +0000 Subject: [hibernate-dev] Hibernate OGM 5.4.1.Final released! Message-ID: Hibernate OGM 5.4.1.Final has been released! The feature packs included in this release are now compatible with WildFly 14 and we added support for the @OrderBy annotation. All the details are in the blog post: http://in.relation.to/2018/12/18/hibernate-ogm-5-4-1-Final-released/ Thanks, Davide From guillaume.smet at gmail.com Wed Dec 19 08:36:37 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 19 Dec 2018 14:36:37 +0100 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting Message-ID: Hi, We had the first 5 -> 6 merge meeting with Chris yesterday. We cherry-picked all the simple things but there were a few more problematic things: - things that needs to be ported soon but weren't a simple cherry-pick - things that cannot be ported right now because not yet available in 6 We decided to push a document in the 6 tree containing the status so that we have proper versioning: https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc Andrea, Chris and Vlad each have one issue affected. Maybe let's try to target the next meeting as the limit for merging them (or push them to kept for later), probably January 8th-9th. When you're done with a merge, please remove the related content from the document so that we can keep track of things. Thanks. -- Guillaume From guillaume.smet at gmail.com Wed Dec 19 12:39:56 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 19 Dec 2018 18:39:56 +0100 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting In-Reply-To: References: Message-ID: Hi Vlad, Not sure if it's better to partially push the commits or to have them in a list to deal with later (tests + commit). What do the others think about it? On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea wrote: > I have merged some PRs and have some commits still left to integrate into > 6. Indeed that some if them cannot be fully integrated because they rely on > non-implemented functionality. But I'll add the tests in the pending tests > folder. > > Vlad > > On Wed, 19 Dec 2018, 18:19 Guillaume Smet >> Hi, >> >> We had the first 5 -> 6 merge meeting with Chris yesterday. We >> cherry-picked all the simple things but there were a few more problematic >> things: >> - things that needs to be ported soon but weren't a simple cherry-pick >> - things that cannot be ported right now because not yet available in 6 >> >> We decided to push a document in the 6 tree containing the status so that >> we have proper versioning: >> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc >> >> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to >> target the next meeting as the limit for merging them (or push them to >> kept >> for later), probably January 8th-9th. >> >> When you're done with a merge, please remove the related content from the >> document so that we can keep track of things. >> >> Thanks. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at gmail.com Wed Dec 19 17:27:55 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 19 Dec 2018 23:27:55 +0100 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting In-Reply-To: References: Message-ID: Well, I don't think adding the test without the fix is the right thing to do. When we will try to make this test work, we will have totally forgotten that there's a fix needed for that. That's why I listed the commits we couldn't merge for now as we will have to merge them later, once the feature has been implemented. And if you merge the tests and the fix at once, at least you know what you're doing. On Wed, Dec 19, 2018 at 7:21 PM Vlad Mihalcea wrote: > We need the tests to be available to know whether 6.0 has regressions than > 5.x. Therefore, all the pending tests become the list of tasks to be > integrated. > > Vlad > > On Wed, 19 Dec 2018, 19:40 Guillaume Smet >> Hi Vlad, >> >> Not sure if it's better to partially push the commits or to have them in >> a list to deal with later (tests + commit). >> >> What do the others think about it? >> >> On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea >> wrote: >> >>> I have merged some PRs and have some commits still left to integrate >>> into 6. Indeed that some if them cannot be fully integrated because they >>> rely on non-implemented functionality. But I'll add the tests in the >>> pending tests folder. >>> >>> Vlad >>> >>> On Wed, 19 Dec 2018, 18:19 Guillaume Smet >> wrote: >>> >>>> Hi, >>>> >>>> We had the first 5 -> 6 merge meeting with Chris yesterday. We >>>> cherry-picked all the simple things but there were a few more >>>> problematic >>>> things: >>>> - things that needs to be ported soon but weren't a simple cherry-pick >>>> - things that cannot be ported right now because not yet available in 6 >>>> >>>> We decided to push a document in the 6 tree containing the status so >>>> that >>>> we have proper versioning: >>>> >>>> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc >>>> >>>> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to >>>> target the next meeting as the limit for merging them (or push them to >>>> kept >>>> for later), probably January 8th-9th. >>>> >>>> When you're done with a merge, please remove the related content from >>>> the >>>> document so that we can keep track of things. >>>> >>>> Thanks. >>>> >>>> -- >>>> Guillaume >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> From steve at hibernate.org Thu Dec 20 00:31:04 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 19 Dec 2018 23:31:04 -0600 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting In-Reply-To: References: Message-ID: Seems to me it would be better to wait until the whole commit can be integrated. Just seems like it would be easier to keep track of On Wed, Dec 19, 2018, 3:25 PM Guillaume Smet wrote: > Hi Vlad, > > Not sure if it's better to partially push the commits or to have them in a > list to deal with later (tests + commit). > > What do the others think about it? > > On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea > wrote: > > > I have merged some PRs and have some commits still left to integrate into > > 6. Indeed that some if them cannot be fully integrated because they rely > on > > non-implemented functionality. But I'll add the tests in the pending > tests > > folder. > > > > Vlad > > > > On Wed, 19 Dec 2018, 18:19 Guillaume Smet wrote: > > > >> Hi, > >> > >> We had the first 5 -> 6 merge meeting with Chris yesterday. We > >> cherry-picked all the simple things but there were a few more > problematic > >> things: > >> - things that needs to be ported soon but weren't a simple cherry-pick > >> - things that cannot be ported right now because not yet available in 6 > >> > >> We decided to push a document in the 6 tree containing the status so > that > >> we have proper versioning: > >> > https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc > >> > >> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to > >> target the next meeting as the limit for merging them (or push them to > >> kept > >> for later), probably January 8th-9th. > >> > >> When you're done with a merge, please remove the related content from > the > >> document so that we can keep track of things. > >> > >> Thanks. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Thu Dec 20 02:59:16 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 20 Dec 2018 09:59:16 +0200 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting In-Reply-To: References: Message-ID: Ok, I'll add the commits that cannot be integrated to the Google Docs list then. Vlad On Thu, Dec 20, 2018 at 7:30 AM Steve Ebersole wrote: > Seems to me it would be better to wait until the whole commit can be > integrated. Just seems like it would be easier to keep track of > > > On Wed, Dec 19, 2018, 3:25 PM Guillaume Smet > wrote: > >> Hi Vlad, >> >> Not sure if it's better to partially push the commits or to have them in a >> list to deal with later (tests + commit). >> >> What do the others think about it? >> >> On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea >> wrote: >> >> > I have merged some PRs and have some commits still left to integrate >> into >> > 6. Indeed that some if them cannot be fully integrated because they >> rely on >> > non-implemented functionality. But I'll add the tests in the pending >> tests >> > folder. >> > >> > Vlad >> > >> > On Wed, 19 Dec 2018, 18:19 Guillaume Smet > wrote: >> > >> >> Hi, >> >> >> >> We had the first 5 -> 6 merge meeting with Chris yesterday. We >> >> cherry-picked all the simple things but there were a few more >> problematic >> >> things: >> >> - things that needs to be ported soon but weren't a simple cherry-pick >> >> - things that cannot be ported right now because not yet available in 6 >> >> >> >> We decided to push a document in the 6 tree containing the status so >> that >> >> we have proper versioning: >> >> >> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc >> >> >> >> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to >> >> target the next meeting as the limit for merging them (or push them to >> >> kept >> >> for later), probably January 8th-9th. >> >> >> >> When you're done with a merge, please remove the related content from >> the >> >> document so that we can keep track of things. >> >> >> >> Thanks. >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at gmail.com Thu Dec 20 05:32:45 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 20 Dec 2018 11:32:45 +0100 Subject: [hibernate-dev] ORM 5 -> 6 first merge meeting In-Reply-To: References: Message-ID: Don't know which Google docs you are talking about but they should be referenced here: https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc . Thanks. On Thu, Dec 20, 2018 at 8:59 AM Vlad Mihalcea wrote: > Ok, I'll add the commits that cannot be integrated to the Google Docs list > then. > > Vlad > > On Thu, Dec 20, 2018 at 7:30 AM Steve Ebersole > wrote: > >> Seems to me it would be better to wait until the whole commit can be >> integrated. Just seems like it would be easier to keep track of >> >> >> On Wed, Dec 19, 2018, 3:25 PM Guillaume Smet >> wrote: >> >>> Hi Vlad, >>> >>> Not sure if it's better to partially push the commits or to have them in >>> a >>> list to deal with later (tests + commit). >>> >>> What do the others think about it? >>> >>> On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea >>> wrote: >>> >>> > I have merged some PRs and have some commits still left to integrate >>> into >>> > 6. Indeed that some if them cannot be fully integrated because they >>> rely on >>> > non-implemented functionality. But I'll add the tests in the pending >>> tests >>> > folder. >>> > >>> > Vlad >>> > >>> > On Wed, 19 Dec 2018, 18:19 Guillaume Smet >> wrote: >>> > >>> >> Hi, >>> >> >>> >> We had the first 5 -> 6 merge meeting with Chris yesterday. We >>> >> cherry-picked all the simple things but there were a few more >>> problematic >>> >> things: >>> >> - things that needs to be ported soon but weren't a simple cherry-pick >>> >> - things that cannot be ported right now because not yet available in >>> 6 >>> >> >>> >> We decided to push a document in the 6 tree containing the status so >>> that >>> >> we have proper versioning: >>> >> >>> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc >>> >> >>> >> Andrea, Chris and Vlad each have one issue affected. Maybe let's try >>> to >>> >> target the next meeting as the limit for merging them (or push them to >>> >> kept >>> >> for later), probably January 8th-9th. >>> >> >>> >> When you're done with a merge, please remove the related content from >>> the >>> >> document so that we can keep track of things. >>> >> >>> >> Thanks. >>> >> >>> >> -- >>> >> Guillaume >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From yoann at hibernate.org Thu Dec 20 05:55:42 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 20 Dec 2018 11:55:42 +0100 Subject: [hibernate-dev] Hibernate Search 5.11.0.Final released Message-ID: Hello, We just published Hibernate Search 5.11.0.Final. This release mainly includes an upgrade to Hibernate ORM 5.4.0.Final. More info: http://in.relation.to/2018/12/20/hibernate-search-5-11-0-Final/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From steve at hibernate.org Thu Dec 20 10:14:41 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 20 Dec 2018 09:14:41 -0600 Subject: [hibernate-dev] inSession / inTransaction Message-ID: In tests we find our `#inSession` and `#inTransaction` methods very useful. Which got me thinking that maybe we should support these on SessionFactory directly: public interface SessionFactory ... { ... void inSession(Consumer action); void inTransaction(Consumer action); void inTransaction(Session session, Consumer action); } and maybe even: public interface Session ... { void inTransaction(Consumer action); } Objections? From gunnar at hibernate.org Thu Dec 20 14:33:27 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 20 Dec 2018 20:33:27 +0100 Subject: [hibernate-dev] inSession / inTransaction In-Reply-To: References: Message-ID: Hey, When discussing this before, there were some doubts about its actual usefulness in non-testing, real-world code. E.g. you'd typically interact with multiple DAOs/repositories etc. and would have to somehow pass the session to each of them. One other thought is that inTransaction() should allow to return a result value. --Gunnar Am Do., 20. Dez. 2018 um 17:02 Uhr schrieb Steve Ebersole : > > In tests we find our `#inSession` and `#inTransaction` methods very > useful. Which got me thinking that maybe we should support these on > SessionFactory directly: > > public interface SessionFactory ... { > ... > void inSession(Consumer action); > void inTransaction(Consumer action); > void inTransaction(Session session, Consumer action); > } > > and maybe even: > > public interface Session ... { > void inTransaction(Consumer action); > } > > > Objections? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Dec 20 17:16:09 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 20 Dec 2018 16:16:09 -0600 Subject: [hibernate-dev] inSession / inTransaction In-Reply-To: References: Message-ID: On Thu, Dec 20, 2018 at 1:33 PM Gunnar Morling wrote: > Hey, > > When discussing this before, there were some doubts about its actual > usefulness in non-testing, real-world code. E.g. you'd typically > interact with multiple DAOs/repositories etc. and would have to > somehow pass the session to each of them. > I've written many non-trivial apps in my past that did not use "DAO/repositories" etc. Not sure why we'd choose to not implement something that is useful just because not everyone would use it. To me, if something is repeatedly useful in writing tests... it tends to be more-or-less generally useful. One other thought is that inTransaction() should allow to return a result > value. > An over-loaded form perhaps, yes I can see that - but non-returning is valid as well. So maybe: public interface SessionFactory ... { ... void inSession(Consumer action); void inTransaction(Consumer action); void inTransaction(Session session, Consumer action); T inSession(Function action); T inTransaction(Function action); T inTransaction(Session session, Function action); } and public interface Session ... { void inTransaction(Consumer action); T inTransaction(Function action); } From guillaume.smet at gmail.com Thu Dec 27 07:14:33 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 27 Dec 2018 13:14:33 +0100 Subject: [hibernate-dev] Possible regression due to the new entity graph code Message-ID: Hi, Looks like we have a regression due to the new entity graph code in 5.4. * https://hibernate.atlassian.net/browse/HHH-13175 for the test case and explanation; * https://github.com/hibernate/hibernate-orm/pull/2709 for a fix proposal but I don't think we really want to go that way. Steve, could you take a look at it? I'm pretty sure it's also in 6 as you backported things from 6 to 5.4 for this feature. I plan to release a 5.4.1 probably mid-January to hopefully fix this one and the other regressions spotted by our users. Thanks. -- Guillaume From steve at hibernate.org Sun Dec 30 10:08:17 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 30 Dec 2018 09:08:17 -0600 Subject: [hibernate-dev] Possible regression due to the new entity graph code In-Reply-To: References: Message-ID: Commented on the Jira. It is a regression, though it is not caused specifically by the graph changes. It is caused more by a change in how subsequent selects are fired. If it was an intentional change, it would be good to understand why it was changed so we can make an informed decision about how to best resolve this - whether the subsequent-select changes ought to reverted or if we should adjust the graph handling to account for that change. My concern is that the subsequent-select changes might lead to other such hard-to-diagnose problems. FWIW, changing graph handling wrt `#find` *should be* trivial. I'll work on a PR using this approach to verify it is indeed trivial (after I'm actually back from vacation). P.S. Note that this only affects `#find` operations. Graphs applied to HQL or criteria queries do not have this issue. So that is a viable workaround. On Thu, Dec 27, 2018 at 6:49 AM Guillaume Smet wrote: > Hi, > > Looks like we have a regression due to the new entity graph code in 5.4. > > * https://hibernate.atlassian.net/browse/HHH-13175 for the test case and > explanation; > * https://github.com/hibernate/hibernate-orm/pull/2709 for a fix proposal > but I don't think we really want to go that way. > > Steve, could you take a look at it? I'm pretty sure it's also in 6 as you > backported things from 6 to 5.4 for this feature. > > I plan to release a 5.4.1 probably mid-January to hopefully fix this one > and the other regressions spotted by our users. > > Thanks. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Sun Dec 30 11:59:38 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 30 Dec 2018 17:59:38 +0100 Subject: [hibernate-dev] Possible regression due to the new entity graph code In-Reply-To: References: Message-ID: I'll check with Gail when she's back. The behavior change is probably caused by some of the fixes that were made during the 5.4 cycle. We'll get back to you on this. Thanks for checking.