Am Di., 29. Sept. 2020 um 13:38 Uhr schrieb Sanne Grinovero <
sanne(a)hibernate.org>:
On Tue, 29 Sep 2020 at 12:34, Gunnar Morling
<gunnar(a)hibernate.org> wrote:
>
> 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...
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)
Yes, that'd mean some rather simple interaction with the Jira REST API to
obtain the status of issues referenced in a PR's commit messages. We don't
have this check exactly, but here's some examples of similar API calls from
our release job, where we e.g. make sure all issues to be released have set
a component, transition them to "Closed", and more:
https://github.com/debezium/debezium/blob/master/jenkins-jobs/scripts/rel...
One thing I'd recommend is to not go overboard with too strict checks; e.g.
you might want to quickly attribute a typo fix to an already closed issue
after a release (maybe you *really* don't want this, but perhaps there are
similar situations where you might want to deviate from the general
process). That's why we let the build fail if there's a commit without Jira
issue, but the PR still isn't blocked from being merged. So we can overrule
the check sensibly, if need be.
Hth,
--Gunnar
>
> --Gunnar
>
>
>
> Am Di., 29. Sept. 2020 um 13:15 Uhr schrieb Sanne Grinovero <
sanne(a)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(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