On Tue, 29 Sep 2020 at 12:34, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: thanks! I was just reading about such options right now, and your example is really handy! Do you think it would be possible to evolve such a rule to check that it's not a closed JIRA ? (I'm sure it is, but I mean to ask if it's simple enough to be worth exploring) > > --Gunnar > > > > Am Di., 29. Sept. 2020 um 13:15 Uhr schrieb Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >> 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(a)lists.jboss.org >> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s