Commit messages, and keeping JIRA in synch
by Sanne Grinovero
Hi all,
looks like it's a good time for me to remind how we need commits
managed, and their relation to JIRA tickets.
When reviewing pull requests, and before merging them, please pay
attention to these simple rules as it's important for long term
maintenance.
We need to be able to query JIRA to figure out which branches and
versions contain a specific patch; it's also useful for people to know
if they might be affected by a specific bug.
# Commit format
ALL commits need to start with the JIRA code which relates to the change.
This implies that any little improvement needs a JIRA ticket created
before being integrated; this is sometimes a little inconvenient, but
please stick to it the same.
The exception to this rule is the release process itself; it's ok for
scripts to push placeholder commits to help identify just-before and
just-after tags.
# Closed JIRA tickets
One should never have a new commit which is recycling a JIRA ticket
which is closed already.
A closed ticket for us means "sealed and archived".
This means that if you discover a better way to fix an issue which is
already closed, you will need to open a new JIRA.
Even if technically the old issue had not been fixed properly, we
don't re-open it as it represents a specific changeset which was
already included in a published release: a published release either
contains a changeset (a patch) or it doesn't - we can't manage
situations well such as "it had half a fix".
# Keep unrelated commits separated
For as much as possible, when fixing an issue try to focus on the
individual issue exclusively.
If you notice an opportunity for refactoring related code, it's ok to
include it. But if you notice such opportunities, typos, or have a
general urge to rewrite code which isn't necessarily useful to touch
during the main patch you're working on - then please make this a
separate JIRA and a separate set of commits.
--
That said, we're very reasonable. Including two kinda related
changesets in a same PR is ok, especially if one depends on the other.
Including a single typo fix is ok. Sending a "follow-up" PR for a fix
which was just merged is fine to reuse the same JIRA - as long as it
wasn't released yet (and closed).
Also, opening a JIRA doesn't have to take much of your time. We don't
require many fields to be filled, and for simple issues it's totally
ok to have a short description. You can also learn its shortcuts, or
use scripts / command line tools to interact with it, integrate it
with your IDE.
I'll update the CONTRIBUTING.md as I see we could clarify some of
these points there.
Many thanks,
Sanne
4 years, 2 months
Release Announcement: General Availability of Java 15 / JDK 15
by Rory O'Donnell
Hi Sanne & Yoann,
**Release Announcement: General Availability of Java 15 / JDK 15 [1]
**
* JDK 15, the reference implementation of Java 15, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
http://jdk.java.net/15/
* JDK 15 Release notes
<https://www.oracle.com/java/technologies/javase/15-relnote-issues.html>
JDK 15 includes fourteen features [2]:
* JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
<http://openjdk.java.net/jeps/339>
* JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360>
* JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371>
* JEP 372: Remove the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/372>
* JEP 373: Reimplement the Legacy DatagramSocket API
<https://openjdk.java.net/jeps/373>
* JEP 374: Disable and Deprecate Biased Locking
<http://openjdk.java.net/jeps/374>
* JEP 375: Pattern Matching for instanceof (Second Preview)
<https://openjdk.java.net/jeps/375>
* JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
<http://openjdk.java.net/jeps/377>
* JEP 378: Text Blocks <http://openjdk.java.net/jeps/378>
* JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
<https://openjdk.java.net/jeps/379>
* JEP 381: Remove the Solaris and SPARC Ports
<https://openjdk.java.net/jeps/381>
* JEP 383: Foreign-Memory Access API (Second Incubator)
<https://openjdk.java.net/jeps/383>
* JEP 384: Records (Second Preview) <https://openjdk.java.net/jeps/384>
* JEP 385: Deprecate RMI Activation for Removal
<https://openjdk.java.net/jeps/385>
Thanks to everyone who contributed to JDK 15, whether by creating
features or enhancements, logging bugs, or downloading and testing the
early-access builds.
OpenJDK 16 Early Access build 15**is now available at http://jdk.java.net/16
* JEPs integrated to JDK 16:
o JEP 347: Enable C++14 Language Features
<https://openjdk.java.net/jeps/347>
o JEP 357: Migrate from Mercurial to Git
<https://openjdk.java.net/jeps/357>
o JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369>
* Release Notes are available at http://jdk.java.net/16/release-notes
**
* Significant changes since the last availability email:
o Build 15
+ JDK-8244090: public lookup should find public members of
public exported types (Reported by Eclipse Jetty)
+ JDK-8250968: Symlinks attributes not preserved when using
jarsigner on zip files
o Build 14
+ JDK-8189744: Deprecate the JDK-specific API for setting
socket options, jdk.net.Sockets
+ JDK-8241003: Deprecate "denigrated" java.security.cert APIs
that represent DNs as Principal or String objects
+ JDK-8245462: The default HttpClient implementation returns
cancelable futures
*__*
Rgds,Rory
[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004733.html
[2] https://openjdk.java.net/projects/jdk/15/
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 3 months
Long live "metamodelgen"
by Sanne Grinovero
The metamodelgen project has since many years been incorporated in
ORM, so we archived the old repository; the idea was triggered by
contributors sending patches to the wrong codebase.
FYI I've also deleted the maintenance team from Github :
metamodelgen-dev ; it had only Gunnar and Emmanuel in it.
Thanks
4 years, 3 months
