gitlint.ini improvements #3509
gitlint.ini improvements #3509
Conversation
in the spirit of OpenStack's 4 opens https://www.openstack.org/four-opens/
This allows for easier trivial fixes. Also, not every dev has a bugzilla account.
| @@ -7,14 +7,8 @@ line-length=80 | |||
| [title-must-not-contain-word] | |||
| words=wip,WIP | |||
|
|
|||
| [title-match-regex] | |||
| regex=^(?!SOC).*\(((bsc#|SOC-)[0-9]+(,\s)?)+\)$ | |||
There was a problem hiding this comment.
Instead of removing it we should improve this:
- not reference for simple commits e.g. via a keyword?
- if there is a reference then it should be formatted correctly
- this should be required for Ardana and Crowbar
- do we want to keep/extend the subject category's .e.g "mkcloud: Add SLES 12 ... support"
There was a problem hiding this comment.
So we could allow for a "trivial" prefix, but what about the non-trivial ones? What is the advantage of making people open a bug for these?
If there is already a related bug, it probably is a good idea to reference it.
There was a problem hiding this comment.
I would tend to say non-trivial are tacking longer and therefore have to be planned as part of the agile team setup. In such a case we will automatically have a Jira ticked.
+1 for the Trivial prefix
There was a problem hiding this comment.
@rsalevsky Do you think there is room between trivial (e.g. a typo) and the smallest thing that needs to be planned?
As you mentioned agile, I think requiring tickets for everything is the opposite of 2 of the value trade-offs from the http://agilemanifesto.org/ :
Individuals and interactions over processes and tools
Responding to change over following a plan
There was a problem hiding this comment.
@rsalevsky By the time there is a review the work has already been done, so no more planning is needed.
I understand the concern that if there is a jira ticket for some change then it should be referenced. but enforcing to create a jira ticket just in order to fix something or cleanup the code makes not a lot of sense to me. We shouldn't bog down in process but make it easy to fix the code. If I need to first wait two weeks for the next sprint planning in order to fix something then that feels very cumbersome.
Given that we're currently not delivering this repository as mainteannce update, what is the value of enforcing bug and jira references? I see some value when we're enforcing bug references for customer visible changes, but this isn't of that kind.
There was a problem hiding this comment.
@rsalevsky I'm not against adding refences to jira/bugzillas when they exist, they totally should be included. Tracking the QA state is done for that purpuse in ardana via the separate "QE-Review" workflow.
Regarding your first work, just tracking that there was one pr merged does not mean the jira has made "significant progress", it really depends. There could be more than one review need to be merged for a particular user story to be compled, so just because there was a PR merged does not indicate where the story is done or not.
IMHO the story is done when the acceptance criteria is fulfilled, and the acceptance criteria should specify what needs to be done. I actually don't see value in people moving tickets in their state just because they saw some PR being merged somewhere - only the "worker" (assignee) should be in charge of doing so, and its the scrum master's responsibility to remind the worker to proprely track the status.
There could be e.g. upstream reviews needed for a particular user story. are also going to ask u pstream to accept our internal jira ticket references in the commit messages? Certainly not. So why here?
There was a problem hiding this comment.
@rsalevsky I'm not against adding refences to jira/bugzillas when they exist, they totally should be included. Tracking the QA state is done for that purpuse in ardana via the separate "QE-Review" workflow.
And this works right? ;)
Regarding your first work, just tracking that there was one pr merged does not mean the jira has made "significant progress", it really depends. There could be more than one review need to be merged for a particular user story to be compled, so just because there was a PR merged does not indicate where the story is done or not.
Agreed but I never said the opposite. It's really depends case by case. But it prevents that I have to ask where the code is (even we the story is done) as it is linked automatically. Plus if the code is merged since weeks and the card did not move it's a indicator that something is not correct about the status.
IMHO the story is done when the acceptance criteria is fulfilled, and the acceptance criteria should specify what needs to be done. I actually don't see value in people moving tickets in their state just because they saw some PR being merged somewhere - only the "worker" (assignee) should be in charge of doing so, and its the scrum master's responsibility to remind the worker to proprely track the status.
Agreed but what is if this doesn't happen? Knowing as much as possible about a story helps Project Management to determine the health of it.
There could be e.g. upstream reviews needed for a particular user story. are also going to ask u pstream to accept our internal jira ticket references in the commit messages? Certainly not. So why here?
What has upstream to do with Crowbar and Ardana? I'm not getting this point.
There was a problem hiding this comment.
Once you revisit a ticket you will find your PR and can add it as a comment to the ticket. You'd need to do the same thing for upstream PRs that don't accept our internal ticket references. If you like those also in git you could use git notes for that. Yes that is more work than not forgetting it, but so is amending the PR.
However if nobody ever revisits the ticket e.g. because the product is now out of support and has no new version, then it ceased to matter anyway. Having the ticket linked to the PR doesn't help with that either way. If you have something else with "what if this doesn't happen" in mind, maybe we can chat about it with some concrete examples.
There was a problem hiding this comment.
@JanZerebecki Let's forget upstream as this is handled different in the MU process. For each Crowbar update I spend 3 hours to try to match Jira and Crowbar Commit messages each week. This are minimum 20 commits. So I have to revisit every ticked and every commit. ;) I don't think it is fair that $someone has to do this stupid works just because we are not enforcing our own policy?
There was a problem hiding this comment.
Do you ever do that for automation.git?
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. See SUSE-Cloud#3509 (comment) for more details.
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. See SUSE-Cloud#3509 (comment) for more details.
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. trivial -> simple unplanned changes noref -> more compley unplanned changes typo -> typo fixes only See SUSE-Cloud#3509 (comment) for more details.
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. trivial -> simple unplanned changes noref -> more compley unplanned changes typo -> typo fixes only See SUSE-Cloud#3509 (comment) for more details.
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. trivial -> simple unplanned changes noref -> more complex unplanned changes typo -> typo fixes only See SUSE-Cloud#3509 (comment) for more details.
The author of a commit should make a conscious decision to either add a reference or not. Adding trivial instead of bsc or SOC enables this. This change prevents that adding a refernce is forgotten as the syntax requires to think about it. trivial -> simple unplanned changes noref -> more complex unplanned changes typo -> typo fixes only See SUSE-Cloud#3509 (comment) for more details.
to make it more suitable for automation repo (PR #3504)