On 1. Nov 2019, at 15:29, Marshall Schor <[email protected]> wrote: > > Re: git-conventions: thanks for the pointers. This page does need updating > :-). > One thing I've also seen (and like) are Jira issue conventions done with > templates, but it seems our Jira doesn't have the templating feature . Github > "issues" has this, though. I wonder if we can switch issue tracking to Jira?
You mean switch issues to GitHub? I think that is possible, e.g. MxNET is using GitHub for issues. > Re: commit message format, conventions. > For the trivial ones, I'd like to continue using a lighter weight process > (e.g. > no Jira, and a simple one-line commit message). Sure. But since the documentation (probably) meant for new contributors, focussing on the "proper way" of doing it might be good. One can still deviate from the proper way for good and practical reasons. > For commit messages, in general, I'd like the first line (which appears in log > messages with the --oneline option) to be as meaningful as reasonable. It > seems > good to start with the Jira issue (if it exists - or "no jira"), and then > with a > short description if one is possible, about the changes, that would be helpful > in the git log one-line message. I personally like having the issue number and title in the first line because the number doesn't help me get the topic unless I look it up in the tracker. Also, the details of the individual commit often don't help me figuring out the topic - so again I'd have to resort to Jira. > My personal feeling (not too strong) is that including feature/ or bug/ is not > worth it, that can be kept for the Jira. (it also misses things like "task" - > which are neither features or bugs, but usually trivial things...) I like the feature/bug thing. It is not really meant to mirror all issue types from Jira. But it gives some basic organization. Probably I just got used to it and somehow feel kind of lost it if it is not there. Anyway, one could also use additional prefixes. E.g. for changes that are not bugs but also do not introduce new features, I'm considering using "refactoring". I'm already using that as an issue type in some projects. > Re: make a Jira as a "requirement" - I'd like an exception for trivial > changes, > where more tracking (beyond just the git logs) wouldn't be justified. Sure. > Re: roll back a release attempt - If you just re-run the release process, > won't > it "up the new tag" again to the next snapshot, or do you just override those > settings and that works? e.g. if the previous release attempt changed > 3.1.1-SNAPSHOT to 3.1.2-SNAPSHOT, and the retry suggests 3.1.3-SNAPSHOT, you > just override that to 3.1.2-SNAPSHOT? Actually, I often just manually adjust the version when the Maven release plugin asks for it without bothering to roll back the history or rolling back the changes to the POMs. -- Richard [1] https://github.com/apache/incubator-mxnet
