Thanks! :-) -Marshall
On 11/1/2019 10:50 AM, Richard Eckart de Castilho wrote: > 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. OK, I'm going to go slow on making this change, though... Might be a good choice for new projects, though. >> 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. Good point! >> 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. Right - good suggestion. > >> 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
