On Fri, Sep 1, 2017 at 12:54 PM, Michael O'Brien <[email protected]> wrote:
> Thanh, > > Hi, I agree with most of what you describe but I personally benefit > from JIRA tracking/linking/history/testing/reopen/cross-repo issues. > > Perhaps you commit your fix - you may later need another fix, or > another JIRA may need to reference/test your fix. > > There is also a small chance that the fix propagates a new issue – it > would be nice to get historical info on the change. > > A smaller detail may be that your fix is part of a change that spans > multiple repos – in this case a jira would be required. > > The JIRA acts a container for related commits. > > Also the bidirectional linking between the link in the commit message > and the jira – are essential. There are orphaned jiras that don’t have the > benefit of a link to their fixes in git. > > Thank you > > /michael > Hi Michael, This makes sense for things that actually fix code or introduces new features etc... in which case please do create a jira and link things to it. I think the specific project committers should be enforcing this at the project level when it makes sense. I feel a blanket statement that every contribution must have a Jira associated pushes away drive by contributors like myself. My issue is for example fixing code style, or making small tweaks to a project shouldn't require a contributor to open a Jira and introduces a barrier to contributing. A potential contributor might not have the time or interest in spending that much time to create a ticket just for a small contribution. If the project REALLY wants to enforce a ticket for every patch then my suggestion is to still accept the patch, introduce a Jenkins job that checks the commit message and fails the build if it's missing the ticket ID. This will prevent committers from merging the patch but still accept the contributor's contribution. In this case the contributor can now decide if they want to spend additional time investigating the build failure and fix it. or leave it up to the project committers. I feel this is a more friendly approach and leaves the task of maintaining a ticket in the hands of the project that wants to enforce such a rule. Regards, Thanh
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
