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 <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
