[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Here are the minutes of our NoORM IRC meeting:

15:38 < jbott> Meeting ended Tue May 22 13:37:54 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:38 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.html
15:38 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.txt
15:38 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.log.html

Have a nice day.

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

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

[Scott Marlow]

On 05/20/2018 08:48 AM, Sanne Grinovero wrote:
> Hi Scott,
> 
> could you explain what you mean by "tradeoff" in this context?  

Hi Sanne,

Sure, see below for more details.

> 
> Thanks!
> 
> 
> On 20 May 2018 at 12:06, Scott Marlow  wrote:
>> There is a tradeoff in WF deployment, between Hibernate bytecode (runtime)
>> enhancing class transformers, being registered before CDI deployment, reads
>> the entity classes.

To explain what I mean by the "tradeoff", I will first explain some 
ordering rules based on the current WildFly/Hibernate deployment scheme.

1. The first "must happen before" rule is that the Hibernate ORM 
bytecode enhancer must register via 
PersistenceUnitInfo.addTransformer(ClassTransformer) [1], before any 
application classes are loaded/defined by the application classloader.

2. Another "must happen before" rule is that the DataSource [2] must be 
available before the first Hibernate ORM (persistence unit) bootstrap 
phase (in the case of applications using the two-phase bootstrap). For 
applications using the single phase PU bootstrap, the DataSource must be 
available before the call to Persistence.createEntityManagerFactory().

3. Another "must happen before" rule, is that CDI handling (WF) deployer 
unit processing code must read the application classes and transform 
application classes as part of CDI deployment, in order to meet the CDI 
requirements.  The first Hibernate ORM pu bootstrap phrase, must 
currently register its class transformer [1] before CDI reads/transforms 
application classes, or the Hibernate entity class transformer, will be 
ignored (note, there is no deployment failure for this, nor can there be 
currently).

4.  Another "must happen before" rule, is that WildFly 
@DataSourceDefinitions, do not become available until very late 
deployment phases, when application classes, will already have been 
read.  Hibernate can also start its first Hibernate ORM pu bootstrap 
phrase, very late as well but again, the Hibernate entity class will be 
ignored (since application classes are already defined before Hibernate 
starts deployment).

If applications want entity classes to be enhanced, the first Hibernate 
ORM pu bootstrap phrase, must run early enough but that cannot happen if 
the pu depends on a @DataSourceDefinition.

There are some WildFly pu hints that influence the ordering but 
currently, apps have to decide what they really want to work:

jboss.as.jpa.classtransformer - defaults to true but if false, WildFly 
does not try to register the entity class transformers early.

wildfly.jpa.twophasebootstrap - defaults to true but if false, WildFly 
does not try to use two phase persistence unit bootstrap (currently only 
supported for Hibernate).

Steve Ebersole and I have talked about adding additional phases to the 
PU bootstrap, but that was so long ago, I forget if it was about 
registering the ORM class transformer [1] earlier.  If ORM 5.3 or 6.0, 
is depending on [1] to work correctly in order to implement the ORM 
features, we need to take some action.

In the past, I recall someone mentioning that lazy loading or dirty flag 
handling, would depend on bytecode enhancing.  If that happened or will 
happen, we should discuss what the fallback solution is for when 
bytecode enhancing is not working.

Another subject, is how should a user find out that bytecode enhancing 
is actually updating application entity classes.  Should that operation 
have trace logging and should that be at the WF or ORM level?

Scott

[1] 
https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-

[2] https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

>>
>> There is also the tradeoff between Hibernate bytecode (runtime) enhancing
>> class transformers being registered too late because the persistent unit
>> uses a datasourcedefinition.
>>
>> I asked Gail's question for 5.1.x and the answer was no.
>>
>> Now, for 5.3, I don't understand the answers yet.
>>
>> Anyway, wanted to mention the above, to share more info with all, as to why
>> we are asking.
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] WildFly 14 requirements for Hibernate libraries

[Sanne Grinovero]

Hi all,

good news first: WildFly 13 will include our latest Hibernate
libraries, in addition to the existing ones.

When booting WildFly 13 with the "-Dee8.preview.mode=true" property
set, it will use:
 - Hibernate ORM 5.3
 - Hibernate Search 5.10
 - Hibernate Validator 6.0

(Validator 6 was available also in WildFly 12)

By default, for users not setting this preview mode, it will use the
older versions which were included in previous WildFly releases -
providing JPA 2.1 and EE7 compatibility only.

We're getting some requirements for WildFly 14 though, which needs to
be ready within 3 months.

In particular:

 A] EE8 will be the only mode

So while today users have the ability to opt-in or ORM 5.3 and
companions, this will be enforced as the older libraries are removed.

Not much we need to do, other than further ensuring that people will
not have trouble. It's also an opportunity to get rid of unnecessary
dependencies.

 B] we need to finish some backward compatibility work.

We did quite some work to ensure ORM 5.3 would be great at backward
compatibility but we left some pending work, e.g. the Compatibility
Transformer that David proposed is not available yet and it needs some
more details from us, such as a definitive list of the transformations
it will need to perform.

Also, the QE team didn't have a chance to review the work in detail
yet; I'm confident we did most of the work already but they might
raise the bar further or just have some questions, we will need to
work with them. I also hope we'll get more familiar with them and
their processes as clearly this isn't a one-off, we can all benefit
from working more closely with them for all future releases.

 C] WildFly 14 is expected to work on both JDK8 and JDK11

Most work to support new JDKs has been done but we need to finish the
last details.
 - CI jobs still not entirely working on JDK11
 - Javassist might stay as an option but we need to make sure no
feature relies on it, as I don't think Javassist will be supportable
on JDK11
 - consequentially, the Byte Buddy based alternative needs to be great
(some issues have been raised)
 - some code to work on JDK11 will need to invoke APIs which were not
available in JDK8: are we going to release "multi-release jars"?
 - resume the work on modernizing the XML parsers?

In particular, Byte Buddy on JDK11 will need access to the classloader
via VarHandles to enhance entities; I didn't investigate this
thoroughly yet but I believe I won't be able to give these references
to BB while relying exclusively on JDK8 APIs.

If we manage to improve anything by the 28th we can still include
micro-fixes in WildFly 13; in particular, if you are aware of any
blocker let's fix them now so that people can give us more detailed
feedback by actually using the EE8 preview mode.

(This includes possibly planning for some micro releases within a week)

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

Re: [hibernate-dev] Disallow uncategorized topics

[Yoann Rodiere]

Done: users must now choose a category, and may use "Miscellaneous" if
their topic really doesn't fit any category.

On Tue, 22 May 2018 at 11:48 Sanne Grinovero  wrote:

> On 22 May 2018 at 10:30, Yoann Rodiere  wrote:
> > I can create a category named " " and force users to pick something
> > explicitly, but it will render poorly, especially on the home page.
>
> Just a joke. More seriously I was wondering if there was some way.
>
> > What's wrong with "Miscellaneous"? I can use another name if you want.
> > "Cannot categorize" or something like that. I can even try naming it
> > "Uncategorized", but there's already a "system" category with this name
> > (only enabled if we don't enforce categories), so I'm not sure if
> Discourse
> > will allow that.
>
> Nothing decidedly wrong with it. Just my last preference; IMO I'd
> prefer keeping things as they are, but no strong feeling.
>
> Thanks
>
> >
> > On Tue, 22 May 2018 at 11:22 Sanne Grinovero 
> wrote:
> >>
> >> On 22 May 2018 at 10:15, Yoann Rodiere  wrote:
> >> > I counted at least 3 mis-categorized topics just this weekend, and
> >> > beyond
> >> > the notification we also have to categorize them ourselves.
> >> >
> >> > Unfortunately I can't "encourage" without enforcing a strict rule.
> >> > Discourse
> >> > only has an option to force people to chose a category, not an option
> to
> >> > make it more obvious that people should chose a category.
> >> > That's why I suggested the "Miscellaneous" category: they will be
> forced
> >> > to
> >> > pick a category, but if nothing fits they can always pick
> >> > "Miscellaneous".
> >> > Obviously I don't imagine that people will think "Miscellaneous" will
> >> > fit
> >> > their needs exactly, that's a last resort.
> >>
> >> Ah. What about a "" category ? Maybe that will encourage people to
> >> stop a second and think about it, yet have the option to go ahead?
> >>
> >> >
> >> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero 
> >> > wrote:
> >> >>
> >> >> +1 to encourage people to set a category
> >> >>
> >> >> but I wouldn't require strict rules, it's not like we're flooded with
> >> >> notifications?
> >> >>
> >> >> In particular, I see no value in a "Miscellaneous" category; it's not
> >> >> like people are going to think "cool, Miscellaneous is exactly what I
> >> >> was looking for".
> >> >>
> >> >> On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We've seen a few posts on discourse lately without any category.
> More
> >> >> > often
> >> >> > than not, these are about ORM (which makes sense since most posts
> are
> >> >> > about
> >> >> > ORM).
> >> >> >
> >> >> > This is a bit annoying since it makes it hard to configure
> Discourse
> >> >> > to
> >> >> > only receive notifications about topics we want to actively
> monitor.
> >> >> >
> >> >> > Would anyone object to disallowing uncategorized topics? I can
> create
> >> >> > a
> >> >> > "Miscellaneous" category if you want, but I'd really like people to
> >> >> > pick
> >> >> > a
> >> >> > category when they create a topic.
> >> >> > --
> >> >> > Yoann Rodiere
> >> >> > yo...@hibernate.org / yrodi...@redhat.com
> >> >> > Software Engineer
> >> >> > Hibernate NoORM team
> >> >> > ___
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev@lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> > --
> >> > Yoann Rodiere
> >> > yo...@hibernate.org / yrodi...@redhat.com
> >> > Software Engineer
> >> > Hibernate NoORM team
> >
> > --
> > Yoann Rodiere
> > yo...@hibernate.org / yrodi...@redhat.com
> > Software Engineer
> > Hibernate NoORM team
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Disallow uncategorized topics

[Sanne Grinovero]

On 22 May 2018 at 10:30, Yoann Rodiere  wrote:
> I can create a category named " " and force users to pick something
> explicitly, but it will render poorly, especially on the home page.

Just a joke. More seriously I was wondering if there was some way.

> What's wrong with "Miscellaneous"? I can use another name if you want.
> "Cannot categorize" or something like that. I can even try naming it
> "Uncategorized", but there's already a "system" category with this name
> (only enabled if we don't enforce categories), so I'm not sure if Discourse
> will allow that.

Nothing decidedly wrong with it. Just my last preference; IMO I'd
prefer keeping things as they are, but no strong feeling.

Thanks

>
> On Tue, 22 May 2018 at 11:22 Sanne Grinovero  wrote:
>>
>> On 22 May 2018 at 10:15, Yoann Rodiere  wrote:
>> > I counted at least 3 mis-categorized topics just this weekend, and
>> > beyond
>> > the notification we also have to categorize them ourselves.
>> >
>> > Unfortunately I can't "encourage" without enforcing a strict rule.
>> > Discourse
>> > only has an option to force people to chose a category, not an option to
>> > make it more obvious that people should chose a category.
>> > That's why I suggested the "Miscellaneous" category: they will be forced
>> > to
>> > pick a category, but if nothing fits they can always pick
>> > "Miscellaneous".
>> > Obviously I don't imagine that people will think "Miscellaneous" will
>> > fit
>> > their needs exactly, that's a last resort.
>>
>> Ah. What about a "" category ? Maybe that will encourage people to
>> stop a second and think about it, yet have the option to go ahead?
>>
>> >
>> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero 
>> > wrote:
>> >>
>> >> +1 to encourage people to set a category
>> >>
>> >> but I wouldn't require strict rules, it's not like we're flooded with
>> >> notifications?
>> >>
>> >> In particular, I see no value in a "Miscellaneous" category; it's not
>> >> like people are going to think "cool, Miscellaneous is exactly what I
>> >> was looking for".
>> >>
>> >> On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
>> >> > Hi,
>> >> >
>> >> > We've seen a few posts on discourse lately without any category. More
>> >> > often
>> >> > than not, these are about ORM (which makes sense since most posts are
>> >> > about
>> >> > ORM).
>> >> >
>> >> > This is a bit annoying since it makes it hard to configure Discourse
>> >> > to
>> >> > only receive notifications about topics we want to actively monitor.
>> >> >
>> >> > Would anyone object to disallowing uncategorized topics? I can create
>> >> > a
>> >> > "Miscellaneous" category if you want, but I'd really like people to
>> >> > pick
>> >> > a
>> >> > category when they create a topic.
>> >> > --
>> >> > Yoann Rodiere
>> >> > yo...@hibernate.org / yrodi...@redhat.com
>> >> > Software Engineer
>> >> > Hibernate NoORM team
>> >> > ___
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev@lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> > --
>> > Yoann Rodiere
>> > yo...@hibernate.org / yrodi...@redhat.com
>> > Software Engineer
>> > Hibernate NoORM team
>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Disallow uncategorized topics

[Sanne Grinovero]

On 22 May 2018 at 10:15, Yoann Rodiere  wrote:
> I counted at least 3 mis-categorized topics just this weekend, and beyond
> the notification we also have to categorize them ourselves.
>
> Unfortunately I can't "encourage" without enforcing a strict rule. Discourse
> only has an option to force people to chose a category, not an option to
> make it more obvious that people should chose a category.
> That's why I suggested the "Miscellaneous" category: they will be forced to
> pick a category, but if nothing fits they can always pick "Miscellaneous".
> Obviously I don't imagine that people will think "Miscellaneous" will fit
> their needs exactly, that's a last resort.

Ah. What about a "" category ? Maybe that will encourage people to
stop a second and think about it, yet have the option to go ahead?

>
> On Tue, 22 May 2018 at 11:06 Sanne Grinovero  wrote:
>>
>> +1 to encourage people to set a category
>>
>> but I wouldn't require strict rules, it's not like we're flooded with
>> notifications?
>>
>> In particular, I see no value in a "Miscellaneous" category; it's not
>> like people are going to think "cool, Miscellaneous is exactly what I
>> was looking for".
>>
>> On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
>> > Hi,
>> >
>> > We've seen a few posts on discourse lately without any category. More
>> > often
>> > than not, these are about ORM (which makes sense since most posts are
>> > about
>> > ORM).
>> >
>> > This is a bit annoying since it makes it hard to configure Discourse to
>> > only receive notifications about topics we want to actively monitor.
>> >
>> > Would anyone object to disallowing uncategorized topics? I can create a
>> > "Miscellaneous" category if you want, but I'd really like people to pick
>> > a
>> > category when they create a topic.
>> > --
>> > Yoann Rodiere
>> > yo...@hibernate.org / yrodi...@redhat.com
>> > Software Engineer
>> > Hibernate NoORM team
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Disallow uncategorized topics

[Yoann Rodiere]

I can create a category named " " and force users to pick something
explicitly, but it will render poorly, especially on the home page.

What's wrong with "Miscellaneous"? I can use another name if you want.
"Cannot categorize" or something like that. I can even try naming it
"Uncategorized", but there's already a "system" category with this name
(only enabled if we don't enforce categories), so I'm not sure if Discourse
will allow that.

On Tue, 22 May 2018 at 11:22 Sanne Grinovero  wrote:

> On 22 May 2018 at 10:15, Yoann Rodiere  wrote:
> > I counted at least 3 mis-categorized topics just this weekend, and beyond
> > the notification we also have to categorize them ourselves.
> >
> > Unfortunately I can't "encourage" without enforcing a strict rule.
> Discourse
> > only has an option to force people to chose a category, not an option to
> > make it more obvious that people should chose a category.
> > That's why I suggested the "Miscellaneous" category: they will be forced
> to
> > pick a category, but if nothing fits they can always pick
> "Miscellaneous".
> > Obviously I don't imagine that people will think "Miscellaneous" will fit
> > their needs exactly, that's a last resort.
>
> Ah. What about a "" category ? Maybe that will encourage people to
> stop a second and think about it, yet have the option to go ahead?
>
> >
> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero 
> wrote:
> >>
> >> +1 to encourage people to set a category
> >>
> >> but I wouldn't require strict rules, it's not like we're flooded with
> >> notifications?
> >>
> >> In particular, I see no value in a "Miscellaneous" category; it's not
> >> like people are going to think "cool, Miscellaneous is exactly what I
> >> was looking for".
> >>
> >> On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
> >> > Hi,
> >> >
> >> > We've seen a few posts on discourse lately without any category. More
> >> > often
> >> > than not, these are about ORM (which makes sense since most posts are
> >> > about
> >> > ORM).
> >> >
> >> > This is a bit annoying since it makes it hard to configure Discourse
> to
> >> > only receive notifications about topics we want to actively monitor.
> >> >
> >> > Would anyone object to disallowing uncategorized topics? I can create
> a
> >> > "Miscellaneous" category if you want, but I'd really like people to
> pick
> >> > a
> >> > category when they create a topic.
> >> > --
> >> > Yoann Rodiere
> >> > yo...@hibernate.org / yrodi...@redhat.com
> >> > Software Engineer
> >> > Hibernate NoORM team
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > --
> > Yoann Rodiere
> > yo...@hibernate.org / yrodi...@redhat.com
> > Software Engineer
> > Hibernate NoORM team
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Disallow uncategorized topics

[Guillaume Smet]

Hi,

On Tue, May 22, 2018 at 10:43 AM, Yoann Rodiere  wrote:

> Would anyone object to disallowing uncategorized topics? I can create a
> "Miscellaneous" category if you want, but I'd really like people to pick a
> category when they create a topic.


Sure, let's do it if we can.

I don't think we need a Misc. category. I just categorized all the
uncategorized posts and they all fit somewhere.

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

Re: [hibernate-dev] Disallow uncategorized topics

[Yoann Rodiere]

I counted at least 3 mis-categorized topics just this weekend, and beyond
the notification we also have to categorize them ourselves.

Unfortunately I can't "encourage" without enforcing a strict rule.
Discourse only has an option to force people to chose a category, not an
option to make it more obvious that people should chose a category.
That's why I suggested the "Miscellaneous" category: they will be forced to
pick a category, but if nothing fits they can always pick "Miscellaneous".
Obviously I don't imagine that people will think "Miscellaneous" will fit
their needs exactly, that's a last resort.

On Tue, 22 May 2018 at 11:06 Sanne Grinovero  wrote:

> +1 to encourage people to set a category
>
> but I wouldn't require strict rules, it's not like we're flooded with
> notifications?
>
> In particular, I see no value in a "Miscellaneous" category; it's not
> like people are going to think "cool, Miscellaneous is exactly what I
> was looking for".
>
> On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
> > Hi,
> >
> > We've seen a few posts on discourse lately without any category. More
> often
> > than not, these are about ORM (which makes sense since most posts are
> about
> > ORM).
> >
> > This is a bit annoying since it makes it hard to configure Discourse to
> > only receive notifications about topics we want to actively monitor.
> >
> > Would anyone object to disallowing uncategorized topics? I can create a
> > "Miscellaneous" category if you want, but I'd really like people to pick
> a
> > category when they create a topic.
> > --
> > Yoann Rodiere
> > yo...@hibernate.org / yrodi...@redhat.com
> > Software Engineer
> > Hibernate NoORM team
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Disallow uncategorized topics

[Sanne Grinovero]

+1 to encourage people to set a category

but I wouldn't require strict rules, it's not like we're flooded with
notifications?

In particular, I see no value in a "Miscellaneous" category; it's not
like people are going to think "cool, Miscellaneous is exactly what I
was looking for".

On 22 May 2018 at 09:43, Yoann Rodiere  wrote:
> Hi,
>
> We've seen a few posts on discourse lately without any category. More often
> than not, these are about ORM (which makes sense since most posts are about
> ORM).
>
> This is a bit annoying since it makes it hard to configure Discourse to
> only receive notifications about topics we want to actively monitor.
>
> Would anyone object to disallowing uncategorized topics? I can create a
> "Miscellaneous" category if you want, but I'd really like people to pick a
> category when they create a topic.
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Stride

[Guillaume Smet]

On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere  wrote:

> ... But I think the one criteria that will make us pick Stride is free
> hosting. Most other platforms either do not have a free plan, or do not
> provide all of their features to free plan users. Zulip apparently removes
> OAuth authentication in its free plan, for instance. The Infinispan team
> has OAuth authentication enabled though... Do they pay for their Zulip
> instance?
>

Quote: "Zulip Cloud Premium is free for open source projects and a wide
variety of non-commercial entities"

What bugged me first was the capped archives of the free offer.

HipChat is doing a very similar thing.

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

[hibernate-dev] Disallow uncategorized topics

[Yoann Rodiere]

Hi,

We've seen a few posts on discourse lately without any category. More often
than not, these are about ORM (which makes sense since most posts are about
ORM).

This is a bit annoying since it makes it hard to configure Discourse to
only receive notifications about topics we want to actively monitor.

Would anyone object to disallowing uncategorized topics? I can create a
"Miscellaneous" category if you want, but I'd really like people to pick a
category when they create a topic.
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Stride

[Sanne Grinovero]

I see it much simpler.

We're moving to Stride because that's how HipChat evolved.


On Tue, 22 May 2018, 09:34 Yoann Rodiere,  wrote:

> I think the problem here is about how we're choosing to migrate to another
> tool. We are basically moving to Stride because Atlassian is being
> uncooperative with updating HipChat, even though Stride is still not fully
> functional.
> Atlassian made HipChat, and we're not happy with HipChat. Atlassian made
> Stride too, so let's not trust them blindly? Sure, we can always move to
> another platform after moving to Stride, but it'll be a waste of time for
> everyone. Let's see what our options really are, first!
>
> I don't think we have many needs, and frankly I don't care which tool we'll
> be using. I'd rather it be open source, but I'll just use whatever we pick
> in the end, as long as I can write messages and receive messages. But I
> want people to be on this platform: both the team, and ideally community
> members. So let's just make sure everyone is at least comfortable with our
> choice.
> Sure some features are not useful to everybody, but in the end it's a
> matter of taste and personal workflow, and we can't argue about that
> without enforcing a standardized workflow. I think it would be more useful
> to just list what we want, then see which platforms fit best, then pick
> one, compromising as needed.
>
> I started a document to compare various solutions, feel free to add
> anything you think is relevant:
>
> https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing
>
> ... But I think the one criteria that will make us pick Stride is free
> hosting. Most other platforms either do not have a free plan, or do not
> provide all of their features to free plan users. Zulip apparently removes
> OAuth authentication in its free plan, for instance. The Infinispan team
> has OAuth authentication enabled though... Do they pay for their Zulip
> instance?
>
> Of course if we could host it ourselves it would be another story, but I
> doubt anyone wants to add that to the list of tools we currently maintain.
>
>
> On Mon, 21 May 2018 at 14:02 Guillaume Smet 
> wrote:
>
> > Hi,
> >
> > On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole 
> > wrote:
> >
> > > You can't "do your job" without yet another way to get notified of CI
> job
> > > status?  I'm confused - did Jenkins remove all of its other forms of
> > > notification?  ;)  Seriously though,  I've never understood this desire
> > to
> > > have yet another communications "inbox" spammed by automated
> > notifications
> > > - and its even worse in Hip Cat because I can never hide them.  So it
> is
> > > hard for me to incorporate this into the argument against moving.
> > >
> >
> > Typically, for the websites builds, I like to have the notifications on
> > HipChat. Not vital but it's something I appreciate.
> >
> >
> > > Y'all really wanted to move to Hip Chat in the first place even though
> to
> > > me it always felt (and feels) half-baked itself.
> > >
> >
> > I wasn't part of the team at that point.
> >
> >
> > > And if the web client is as good as the native client, I assume you use
> > > the web client instead?
> > >
> >
> > Yes. I have a pinned tab for it. Desktop notifications from the browser
> are
> > well integrated now.
> >
> >
> > > So to me it really comes down to what are the blockers to not making
> this
> > > move now.  So far I hear:
> > >
> > >1. No Jenkins notifications - see above
> > >2. Guest access - meh - If having to have an account to join the
> > >discussion is bad then we should immediately make our forums
> > >guest-accessible again as well ;)
> > >
> > > As mentioned in my email, I don't mind not having guest access if we
> have
> > some sort of external auth integration (Github/Twitter/Google). This way,
> > it avoids creating yet another account. That's what we have on our new
> > forums.
> >
> > Maybe Stride has it, I don't know, but I would like our next chat system
> to
> > have that.
> >
> > I took a look at several accounts we have on our forums and most of them
> > are from GitHub or Google (I took seven randomly and 1 had an account
> > specific to our forums - no better statistics sorry).
> >
> > >
> > >1. There may be better options out there - at some point can we just
> > >pick one and use it?  Is one "inbox" really that much better than
> > another
> > >"inbox"?  And clearly I am not even tied to Hip Chat - I was one of
> > the
> > >people wanting to not move there.  Radim, what makes Zulip so
> amazing?
> > >2. "Coordination tool"?  Not really sure what this one is about.  Is
> > >this back to Jenkins notifications?  If you mean a communications
> > tool, of
> > >course it works.  They are largely the same.  Andrea, Sanne and I
> have
> > >played with it, so we in fact do have some idea if it will (spoiler:
> > it
> 

Re: [hibernate-dev] Stride

[Yoann Rodiere]

I think the problem here is about how we're choosing to migrate to another
tool. We are basically moving to Stride because Atlassian is being
uncooperative with updating HipChat, even though Stride is still not fully
functional.
Atlassian made HipChat, and we're not happy with HipChat. Atlassian made
Stride too, so let's not trust them blindly? Sure, we can always move to
another platform after moving to Stride, but it'll be a waste of time for
everyone. Let's see what our options really are, first!

I don't think we have many needs, and frankly I don't care which tool we'll
be using. I'd rather it be open source, but I'll just use whatever we pick
in the end, as long as I can write messages and receive messages. But I
want people to be on this platform: both the team, and ideally community
members. So let's just make sure everyone is at least comfortable with our
choice.
Sure some features are not useful to everybody, but in the end it's a
matter of taste and personal workflow, and we can't argue about that
without enforcing a standardized workflow. I think it would be more useful
to just list what we want, then see which platforms fit best, then pick
one, compromising as needed.

I started a document to compare various solutions, feel free to add
anything you think is relevant:
https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing

... But I think the one criteria that will make us pick Stride is free
hosting. Most other platforms either do not have a free plan, or do not
provide all of their features to free plan users. Zulip apparently removes
OAuth authentication in its free plan, for instance. The Infinispan team
has OAuth authentication enabled though... Do they pay for their Zulip
instance?

Of course if we could host it ourselves it would be another story, but I
doubt anyone wants to add that to the list of tools we currently maintain.


On Mon, 21 May 2018 at 14:02 Guillaume Smet 
wrote:

> Hi,
>
> On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole 
> wrote:
>
> > You can't "do your job" without yet another way to get notified of CI job
> > status?  I'm confused - did Jenkins remove all of its other forms of
> > notification?  ;)  Seriously though,  I've never understood this desire
> to
> > have yet another communications "inbox" spammed by automated
> notifications
> > - and its even worse in Hip Cat because I can never hide them.  So it is
> > hard for me to incorporate this into the argument against moving.
> >
>
> Typically, for the websites builds, I like to have the notifications on
> HipChat. Not vital but it's something I appreciate.
>
>
> > Y'all really wanted to move to Hip Chat in the first place even though to
> > me it always felt (and feels) half-baked itself.
> >
>
> I wasn't part of the team at that point.
>
>
> > And if the web client is as good as the native client, I assume you use
> > the web client instead?
> >
>
> Yes. I have a pinned tab for it. Desktop notifications from the browser are
> well integrated now.
>
>
> > So to me it really comes down to what are the blockers to not making this
> > move now.  So far I hear:
> >
> >1. No Jenkins notifications - see above
> >2. Guest access - meh - If having to have an account to join the
> >discussion is bad then we should immediately make our forums
> >guest-accessible again as well ;)
> >
> > As mentioned in my email, I don't mind not having guest access if we have
> some sort of external auth integration (Github/Twitter/Google). This way,
> it avoids creating yet another account. That's what we have on our new
> forums.
>
> Maybe Stride has it, I don't know, but I would like our next chat system to
> have that.
>
> I took a look at several accounts we have on our forums and most of them
> are from GitHub or Google (I took seven randomly and 1 had an account
> specific to our forums - no better statistics sorry).
>
> >
> >1. There may be better options out there - at some point can we just
> >pick one and use it?  Is one "inbox" really that much better than
> another
> >"inbox"?  And clearly I am not even tied to Hip Chat - I was one of
> the
> >people wanting to not move there.  Radim, what makes Zulip so amazing?
> >2. "Coordination tool"?  Not really sure what this one is about.  Is
> >this back to Jenkins notifications?  If you mean a communications
> tool, of
> >course it works.  They are largely the same.  Andrea, Sanne and I have
> >played with it, so we in fact do have some idea if it will (spoiler:
> it
> >does)
> >3. We should go where WildFly goes (?).
> >
> > My main point is that we have no idea if Stride is stable at the moment.
> They definitely don't want to massively migrate the HipChat users and I
> found at least one comment of a person who has migrated there and is not
> happy at all (not saying it makes all the migrated users unhappy, just
> saying that it