Github offering new options about how the big "green button" to merge Pull Requests
by Sanne Grinovero
Github now offers an option to not create the "merge commit" when you
want to merge a PR from the web ui.
It comes at a significant cost though: it will merge the PR but squash
all commits in one.
While initially thinking that doesn't help us at all, at second
thought: we really want any non-trivial code change to be checked out
locally, run the testsuite, and only then push.
But let's say there's a trivial PR fixing some typos in documentation!
You look at it, looks good and then you really just want to say "go
ahead" and get back to more important matters. Besides, we have
Jenkins carefully testing these too and it will grey out the button if
the build fails, so there's some kind of last defence in case you
didn't notice that the "docs typo" PR actually sneaks in some real
problem.
So I'd say we could enable this option with the "squashing" ?
We would still refrain from using the green button for most patches,
but it could save some "boring process" minutes for those simpler
patches.
I've enabled this option for Hibernate Search. We can seek team
consensus before actually using it (you're not supposed to use the
"green button" at all currently), I might at least have it default to
the less annoying option: if you do use it by mistake, it will squash
it all.
The open question remains if we're ok to use it regularly for trivial
PRs, and if you want this switched on all Hibernate repositories.
Thanks,
Sanne
9 years, 8 months
A warmup task: HSEARCH-2207
by Sanne Grinovero
Hi Mincong,
Gunnar suggested that I find a first task for you to familiarize with
the project, and to have you practice the process of creating patches
and proposing them for integration over GitHub.
I think this issue could be suited:
- https://hibernate.atlassian.net/browse/HSEARCH-2207
I hope it's not too boring! It's not just an exercise, we need that
done so it would be a valuable contribution already.
Do you have an account on our JIRA server? If not create one, then let
me know your user id so I can assign the issue to you.
Thanks,
Sanne
9 years, 8 months
OGM: convergence for a 5.0.0.Final ?
by Sanne Grinovero
Hi,
I was hoping that even w/o a specific OGM sprint we would soon (next
week?) be able to re-spin the CR1 with minor effort as the
5.0.0.Final.
Among tasks scheduled for 5.0.0.Final:
- https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20f...
I'm assigned two documentation related issues; these seem important
enough to stay flagged for 5.0.0.Final and should be doable. OGM-888
also relates documentation and should be doable.
Could we agree on moving out the other open issues?
Personally I think the only one needing some attention still is:
- OGM-817 Adapt to changes around auto-quoting
Thanks,
Sanne
9 years, 8 months
ReadWrite 2LC "read uncommitted" data anomaly
by Vlad Mihalcea
Hi,
While reviewing the PR for this issue:
https://hibernate.atlassian.net/browse/HHH-10649
I realized that the ReadWrite cache concurrency strategy has a flaw that
permits "read uncommitted" anomalies.
The RW cache concurrency strategy guards any modifications with Lock
entries, as explained in this post that I wrote some time ago:
http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cachecon...
Every time we update/delete an entry, a Lock is put in the cache under the
entity key, and, this way, "read uncommitted" anomalies should be prevented.
The problem comes when entries are evicted either explicitly:
session.getSessionFactory().getCache().evictEntity( CacheableItem.class,
item1.getId() );
or implicitly:
session.refresh( item1 );
During eviction, the 2PL will remove the Lock entry, and if the user
attempts to load the entity anew (in the same transaction that has modified
the entity but which is not committed yet), an uncommitted change could be
propagated to the 2PL.
This issue is replicated by the PR associated to this Jira issue, and I
also replicated it with manual eviction and entity loading.
To fix it, the RW cache concurrency strategy should not delete entries from
2PL upon eviction, but instead it should turn them in Lock entries.
For the evict method, this is not really a problem, but evictAll would
imply taking all entries and replacing them with Locks, and that might not
perform very well in a distributed-cache scenario.
Ideally, lock entries would be stored separately than actual cached value
entries, and this problem would be fixed in a much cleaner fashion.
Let me know what you think about this.
Vlad
9 years, 8 months
Returned mail: Data format error
by The Post Office
��{U�����`EiQ�K��R
o~�2�B��]�U�eb��
1���[�U��Tp{0:�z�,�b�mf��Q ]�E
3��4������Y,O��b[��������d:�jK���6�lDh;)��N?�D>E��U
CU���e����`�K91��
DU�r����L�6{O���2���1D�%��3>�H(z�i
�E^�O�a�
O�h����Z���' Ydq�0��D��U�������t
:�G��(��$��]�6�j
�����wK����R���TQ"v���rV{i��-$��X�H{��H���Q���ID��>}q����7|�7�?�Py��B�"�����"�}b�W{(��&\j_x0��>w�i�B����v���V�;i?w��%�n�h�znq�F���Z��V�����s��n�Pb���Tn6~KJ�Q��[��t������1C�?��������������������?�Q�?��.�z��� �U�N���Z�Mt�&cO��
��]A�$d��B�{�w��V6���V^�v��TG~� )bh}
�����E��B"����Hv�d�2�������f�~T��R4n�������pJ���uN����s�����E`�����x�]R�]��u�<����PF��\Y�
��B
�a����f���y���S��-aQ�Z���<�2�;�No��KY����$�����~R��fn��I�~a��8[l�z���l��������0:Tq�M^��Pt�9�5�"��p���~z{�k�U���46n�67�������&Zm�������1��7*��e�R�J�mF����&^qx��T��c��������Q}6��L7mR�E�����7A-GE.������NO��*��A�c�9��I�G��U���M|����<�^q�c��J�.�
�J��bsB���j�����Dmu�$�s���v��D��f8��A%����
a�rb�Nh�C�x>���$�95�Z�i)*��!�9m2����*��|;���}Q�oM#
n�I7�5$��_�
�N���b.l�V}p�������9�ft�1��,�
�m�o$R������N���4Z�k�{���Gb&�H�v�gS��2�2��kz��0w#!���f�!T�5�xaI�L�>F6�������#8��r�[�3�\�ZF��`��QKi��L��r�������{��W?�_��i]G���D�����9�����CN���"j��7`�����G��*������pK4��7���
���Y��&��^!��*/���U��GF5�R��\�����&�(�FA��_p^���&L.p���p�Z��CJ,A�
O�,U�������'����gMg�]kR�
�x<�-���o�o��x��6�v\�F�EoY&�����c�0;��.)XtI��,�� f�O�0��-z
����������R����|:���3��C�~o5���Z�[X�5Ky�������?�{�_Ta�����]����7�d*%g�a>0��O��{Z��z�x�&c:��v/�n��M��`�9������/px�/yXi����&�;Q��8c�����S�����.�
�E��0C��x���J�:?�!�W�%I�
��8��mt�O���k�t!U�O�X����EF�du�����>�L����L"���%"�<�~[w�����-^��4AR�"�T��S^�y�$��/�$Rn��j�5P��u�
���\�p|~�$���
wNB�������/JsY����p��CQ�!~d������s�iSe��gTXC����x�cW�8����4��30�'�uX/�:'7����6������{�R�����R!��#��q�B�B�^���]�����/s�0Zu��(��Hh������/��uaL��G��,��g����t����
�v���oQ�V������h\��S!��4R57
��s�]`���^�O���:����e���C�
��sV�
�$$��I����u/7�������|�4�Y������R���M�vIP�Ob����S�?Fy6����/��)u��B��\��<�q~��0#�K�Bm�����z7?��4V6�h���x
�>d:_���}>i��NND�*�b��7����p^�t�^�E6�}r�E������1i�)��WX;vT����kq�W�Yh�X��gz����w�C}��{7J�O��?���vazY���U5��
2��g{����������.
� �}S?���USV�����!����A��Ri�~e�ztV�����u���/���Z��.�������"P�ld[�<J0B�5�T_����x��q7,F5J��;8����
U&��\�����p
��8��B��f�4��;P�A2����AUVx�j��^b�I.n|�d�*[%q}�����8�}Q��v*}��&pW^�9�l#Kx�����(�~
��]vT�����A.A���B��FI��Ppb�C���
9 years, 8 months
Search: Lucene 6 is coming
by Sanne Grinovero
The Apache Lucene team is voting on candidate releases for Lucene 6.0.0.
As usual we'll refrain from making API changes in a minor release, but
we should start to sometimes try building against Lucene 6 to make
sure to use APIs which will live longer, if there's choice.
The most notable change is an entirely new strategy to handle numeric
fields; including overhauled APIs.
I guess Hibernate Search 6 will probably want to align with Lucene 6
and Hibernate ORM 6; only problem I see with that is I hope people
won't get used to these all being nicely aligned as it's probably not
sustainable as a rule.. just luck so far (although we managed that
with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!).
Both Lucene 6 and ORM 6 will require Java 8.
I'll update the Search roadmap to reflect this aim, as I assume there
won't be concerns?
Thanks,
Sanne
9 years, 8 months
README.adoc of hibernate.org
by Guillaume Smet
Hi,
While setting up my environment for hibernate.org and in.relation.to, I
noticed that there are broken links in the README... when we read it on
GitHub (the .adoc extension is missing). It works OK when we read it from
the website using http://hibernate.org/README/.
I expect most people to use GitHub to read this document and the other ones
related (docker/README.adoc, survival-guide.adoc).
I was thinking about adding these files to .awestruct_ignore so that we
don't generate website pages for them and fix them for GitHub browsing.
Anyone against it?
--
Guillaume
9 years, 8 months