Re: [cross-project-issues-dev] Must all changes be tracked by a bug?

[Mickael Istria <mistria@xxxxxxxxxx>]

On 09/02/2016 09:20 AM, Wim Jongman wrote:

Hi All,

In another thread I asked how I could enforce a bug number in the commit message.
Mickael replied:
,
"I'm curious: what is the value of enforcing the creation of a bugzilla for every change. Let's assume a user finds a better label and wants to contribute it, do you really want to bother them creating a Bugzilla? Wasn't creating a Gerrit patch not enough difficulty yet?"
Since our project has graduated I want to make sure that all changes are known. Since the release infrastructure is connected to bugzilla I assumed this is the correct process. But your questions tell me this is not what everyone thinks.

I'm taking the risk of being convicted here, but for SWTBot, we don't enforce a Bugzilla.

So, for SWT, here is how we allow things to happen

* First, all our changes go through Gerrit, also the ones that our committers make. Do you think it is mandatory for them to include a bug number in the first line of the commit?

If a bugzilla is already existing for the project, we ask the contributor to link to bug in commit message, usually on first line. If this is someone "new" to us, we try to explain how to amend and push again the commit, or to use Gerrit online edition for that (pretty useful), or we edit the message and comment explaining that we added a reference to the bug (so contributor understands what we edit and why, as it's not obvious).

* If a bugnumber in the commit is optional, how can I track changes?

If there is a bug existing, we usually ask to provide the Bugzilla in commit message.
If there is a Gerrit which is not linked to a bugzilla automatically, then we add the Gerrit URL to the "See also" of the bug.

* Bugzilla is connected with Gerrit. Why is the change not rejected if a link cannot be made?

Because AFAIK, people are not forced to create a bug for each code change. At least, committers don't have too IIRC.

* How can EF approve a release if not all changes are documented.

The changelog from Git is a decent documentation if commit messages are well written. With the rise of code-review, there are less "noisy" commits, so reading the changelog just seems like a better documentation than sorting out the right Bugzilla request.

HTH,

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets