On Fri, Sep 2, 2016 at 9:20 AM, Wim Jongman <[email protected]> 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. > > * 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? > no, we consider the history tracked in git as the primary source of truth and ensure through the review process that this history is well written so that it can be understood later. We use bugs in Bugzilla mainly for tracking bugs before someone starts fixing them and for lengthy discussions on new features where we first want to agree on how the feature should look like before an actual implementation is started. So commits which are related to a bug should link to the related bug but still we try to ensure that each commit message explains what was changed and why so that the Git history is self-contained even if Bugzilla isn't reachable. > * If a bugnumber in the commit is optional, how can I track changes? > using Git history > * Bugzilla is connected with Gerrit. Why is the change not rejected if a > link cannot be made? > * How can EF approve a release if not all changes are documented. > the changes are primarily documented in the Git history, I think that's the main purpose of a versioning system. That's why a project's IP log is generated from the git history of a project. -Matthias
_______________________________________________ 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
