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 _______________________________________________ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
