Hey Sanne, > ALL commits need to start with the JIRA code which relates to the change.
Perhaps you're doing this already, so just in case: for Debezium we have a simple check of that as a GH action, failing PR builds if they contain commits whose message does not begin with "DBZ-": https://github.com/debezium/debezium/blob/master/.github/workflows/sanity-check.yml --Gunnar Am Di., 29. Sept. 2020 um 13:15 Uhr schrieb Sanne Grinovero < sa...@hibernate.org>: > 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 _______________________________________________ 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
