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,
|