Hi
Your checker could allow some reserved non Bug id prefixes such
as:
[typo]
[releng]
[unrelated]
...
Regards
Ed Willink
On 02/09/2016 08:39, Daniel Megert
wrote:
Having a bug for
trivial things, like e.g.
fixing a typo, is just overkill. I would rather not fix it than
waste my
time with creating a bugzilla entry.
Dani
From:
Mickael Istria
<mistria@xxxxxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx
Date:
02.09.2016 09:35
Subject:
Re:
[cross-project-issues-dev]
Must all changes be tracked by a bug?
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|