Chat migration - D minus 115 until the death of HipChat
by Yoann Rodiere
Hi,
TL;DR: please vote here if you don't want to end up having to use a chat
tool you don't like: https://doodle.com/poll/h6scc9bsh6a4ymre
HipChat Cloud will stop working on February 15th, 2019 [1]. We need to
choose an alternative before we have our back against the wall, so I'll try
to resurrect the conversation.
As a reminder, Stride is no longer an option: Atlassian cancelled the
project, and encourages users to migrate to Slack.
The discussed options so far were:
- *Moving back to IRC*. Aye: ?; nay: ?
Pros: simple as hell.
Cons: basic as hell; we won't keep the chat history.
- *Migrating to Slack* [6], as suggested by Atlassian [2]. Aye:
Christian B; Nay: ?
Pros: we will keep the chat history (I think).
Cons: not open-source; desktop client consumes a lot of resources.
- *Migrating to Zulip* [3]. Aye: Emmanuel, Yoann. Nay: Guillaume (kind
of).
Pros: Advanced conversation management thanks to the "topics" feature.
Cons: Complex to use because of the "topics" feature; we won't keep the
chat history (1).
- *Migrating to Gitter* [5] (we'll create different rooms, probably).
Aye: ?, Nay: ?
Pros: Users seem to actually go there, so we could have our "live
support" rooms next to our "internal discussion" rooms.
Cons: not open-source; we won't keep the chat history (1).
I created a poll based on the discussion we had on the thread
"[hibernate-dev] Stride". I think everyone had the time to suggest another
option.
Please vote here and now, or remain silent forever ;):
https://doodle.com/poll/h6scc9bsh6a4ymre
I'd suggest the following rules: if there's a single clear winner (a
platform that everyone would be happy with), we'll pick that one. If there
are multiple clear winners, whoever does the migration work will pick
what's easier to set up (taking into account the various integrations).
Otherwise, back to discussing it on this thread...
(1) There seems to be some work in progress on a migration tool from
HipChat to Zulip, but it doesn't seem to be ready yet [4]
[1]
https://www.atlassian.com/partnerships/slack/faq#faq-da2b66a1-53d3-4c4e-a...
[2] https://www.atlassian.com/partnerships/slack/migration
[3] https://hibernate.zulipchat.com/
[4] https://github.com/zulip/zulip/issues/10647
[5] https://gitter.im/hibernate/hibernate-orm
[6] https://slackdemo.com/
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
5 years, 10 months
Loggers
by Steve Ebersole
Yes, I know no one likes talking about logging. "Its not important", until
it is ;)
TLDR I am considering moving to using "module names" for logger names
instead of Class names even for DEBUG/TRACE logging and see if anyone had
strong arguments to not do this..
Full version---
For some time I have been moving to an approach of defining message
loggers[1] using a single contract per function or "module" - e.g.:
1. the second level caching module uses the dedicated message logger
`ConnectionPoolingLogger`
2. the ManagedBeanRegistry module uses the dedicated message logger
`BeansMessageLogger`
3. etc
Each of these define a dedicate instance instance they can use. E.g.
ConnectionPoolingLogger is defined as:
````
@MessageLogger( projectCode = "HHH" )
@ValidIdRange( min = 10001001, max = 10001500 )
public interface ConnectionPoolingLogger extends BasicLogger {
ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger(
ConnectionPoolingLogger.class,
"org.hibernate.orm.connections.pooling"
);
...
}
````
I won't get into all the whys I do this unless someone cares ;)
But I am contemplating doing the same for basic loggers so I wanted to ask
everyone else's opinion since this means a change in how you'd have to
configure logging for DEBUG/TRACE output. Usually you'd use the Class name
as the logger name and use that to control logging in the back-end (log4j,
etc). If I do this, you'd have to instead use the module name.
There are quite a few reasons I am considering this, including all of the
reasons I did it for message loggers in the first place. If I am
debugging the loading of a collection or an entity, today I'd have to know
all the packages involved (there is no common root name) and list them in
my log4j.properties; that is because the process is ultimately handled by
delegates or helpers in many different packages (`org.hibernate.loader`,
`org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be
nice to just be able to say `org.hibernate.loading` or
`org.hibernate.loading.entity` or `org.hibernate.loading.collection` or ...
for a number of reasons:
1. When we need to see logging from someone it is a lot easier to tell
the module name(s) you need enabled as opposed a list of package and class
names.
2. When running JPA TCK it is essentially impossible to attach debugger
to step through code when debugging a failure - you have to rely on
debugging through output. *Well that used to be the case, but the
latest TCK broke logging to STDOUT somehow so we ended up having to try and
reproduce the failure in our testsuite - so then it does not matter either
way ;)*
3. Easier to document -
http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Loggi...
Thoughts?
[1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which
we use for user-focused log messages. Should always be logged at >= INFO
[2]
[3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for
developer-focused log messages (for debugging). Should always be logged at
DEBUG or TRACE
5 years, 10 months
Can't build Hibernate ORM 5.1 documentation
by Gail Badner
I'm getting ready to release 5.1.17, but I'm having trouble building the
documentation.
I can't even build the documentation using 5.1.16 tag. It worked fine when
I released 5.1.16.Final in August.
A new property was added for HHH-13011, and I need to get that documented
in the user guide for 5.1.17.
Here is what I'm seeing when I execute `./gradlew buildDocs`:
:documentation:renderDocBook_mappingGuide_en-US_html
rendering Book(mappingGuide) en-US/html
Extending script classloader with the jdocbookXsl dependencies
redirecting console output to file
[/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log]
Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
Error reported by XML parser: The markup declarations contained or pointed
to by the document type declaration must be well-formed.
Resetting console output
:documentation:renderDocBook_mappingGuide_en-US_html FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task
':documentation:renderDocBook_mappingGuide_en-US_html'.
> error rendering [org.xml.sax.SAXParseException; systemId:
http://docbook.org/xml/5.0/dtd/docbook.dtd; lineNumber: 1; columnNumber: 1;
The markup decl
arations contained or pointed to by the document type declaration must be
well-formed.] on Hibernate_Mapping_Guide.xml
The log file (/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log)
was empty.
I'm attaching the console log from executing `./gradlew buildDocs --debug
--info`.
Any ideas???
Thanks,
Gail
5 years, 11 months
Re: [hibernate-dev] ORM 6 branch
by Davide D'Alto
+1 for the creation of the branch upstream and everything Yoann said.
One curiosity, once there is an alpha, why would you delete the whole branch?
Couldn't you change everything on the existing branch without deleting it?
It's unusual to rewrite the history of upstream branches but we have
done it before.
PS: Sorry if you received this email twice, I made a mistake
On Tue, Nov 27, 2018 at 1:20 PM Davide D'Alto <daltodavide(a)gmail.com> wrote:
>
> +1 for creating the branch upstream and everything Yoann said.
>
> One curiosity, once there is an alpha, why would you delete the whole branch?
> Couldn't you change everything on the existing branch without deleting it?
> While it's unusual to rewrite the history of upstream branches, we
> have done it before.
>
>
>
> On Tue, Nov 27, 2018 at 12:50 PM Steve Ebersole <steve(a)hibernate.org> wrote:
> >
> > I'd also be fine with moving to upstream as wip/6.0 with the understanding
> > that this branch can be re-written and will eventually be deleted.
> >
> >
> >
> > On Tue, Nov 27, 2018, 1:13 AM Yoann Rodiere <yoann(a)hibernate.org> wrote:
> >
> > > I think it would be better to at least move the code to a 6.0 branch on
> > > the main repository, just so that the code is a little easier to find for
> > > external contributors/users. Even if it's named "6.0-wip" to mention that
> > > you may end up rewriting history on that branch. If we release binaries,
> > > then the code is official and should be in plain sight.
> > >
> > > But if it's not an option, just pushing the 6.0.0.Alpha1 tag to the main
> > > repository would be a step in the right direction.
> > >
> > > Yoann Rodière
> > > Hibernate NoORM Team
> > > yoann(a)hibernate.org
> > >
> > >
> > > On Tue, 27 Nov 2018 at 00:25, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> > >
> > >> On Mon, 26 Nov 2018, 23:39 Gail Badner <gbadner(a)redhat.com wrote:
> > >>
> > >> > That's fine with me.
> > >> >
> > >>
> > >> +1 But could you push the release tag to the reference repo? Just to make
> > >> sure we have it for future reference.
> > >>
> > >> Thanks
> > >>
> > >>
> > >> > On Mon, Nov 26, 2018 at 11:29 AM Steve Ebersole <steve(a)hibernate.org>
> > >> > wrote:
> > >> >
> > >> > > This Wednesday we plan to release 6.0 Alpha1 and I thought it best to
> > >> > start
> > >> > > discussing how to best handle the 6.0 and master branches.
> > >> > >
> > >> > > I think we should keep 6.0 a little while longer in my fork and 5.4 as
> > >> > > master until 6.0 becomes more stabilized to make it easier for 5.4
> > >> > > maintenance. And reconsider as we approach Beta1.
> > >> > >
> > >> > > But this affects everyone, so wanted to see what others thought...
> > >> > > _______________________________________________
> > >> > > hibernate-dev mailing list
> > >> > > hibernate-dev(a)lists.jboss.org
> > >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> > >
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
5 years, 12 months
ORM 6 branch
by Steve Ebersole
This Wednesday we plan to release 6.0 Alpha1 and I thought it best to start
discussing how to best handle the 6.0 and master branches.
I think we should keep 6.0 a little while longer in my fork and 5.4 as
master until 6.0 becomes more stabilized to make it easier for 5.4
maintenance. And reconsider as we approach Beta1.
But this affects everyone, so wanted to see what others thought...
5 years, 12 months
