I was in a meeting with Damon today and he brought up something that might be interesting for us as a team to try out. He suggested that all gerrit commits should be traceable to a phabricator ticket.
This is something that I have actually done at other companies to the point of having it be required for git to accept the patch. The point wouldn't be to have a direct one-to-one correlation between phab tickets and each commit, but to have some traceability about the larger goals that each unit of work is intended to serve. Obviously when we are fixing things in response to open issues this is easy. It takes a bit more practice to make sure that the spontaneous "I have to clean this up because my eyes are bleeding" commits have something in phab to associate the commit to.
Thoughts?
Bryan
On Mon, Feb 2, 2015 at 8:56 PM, Bryan Davis bd808@wikimedia.org wrote:
The point wouldn't be to have a direct one-to-one correlation between phab tickets and each commit,
That's good, because I find I often fix multiple related bugs with a large commit. https://gerrit.wikimedia.org/r/#/c/187840/ would take care of three, if the other two ("change password" and "change email") were to be filed. Maybe 4 if you count working on the "refactor 'business logic' out of special pages" technical debt bug we might have floating around somewhere.
And in the other direction there would be stuff like https://gerrit.wikimedia.org/r/#/q/branch:master+topic:api-cleanup-results,n..., 37 "update $extension for core change" tasks and then customizing the commit summaries for each would probably be a big waste of time.
but to have some traceability about the larger goals that each unit of work
is intended to serve.
I don't think filing phab tasks for "I have to clean this up because my eyes are bleeding" would necessarily be better than a good commit summary as far as indicating what goal the patch is supposed to be solving. As in "when I've felt the need to do this in the past, I often used basically the same text for the task and the commit summary". On the other hand, I tend to be more verbose in my commit summaries.
And in some cases (e.g. https://gerrit.wikimedia.org/r/#/c/187150/), filing a task could take longer than it did to make the commit in the first place.
mediawiki-core@lists.wikimedia.org