Thanks for the comments! 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?
Re: commit message format, conventions. I see we have multiple categories of things we do as modifications. Many of them are trivial (e.g. fixing a misspelling, changing a field that needs updating for each release - like the pointer to the Jira release for the ISSUES-FIXED report.) 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). 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. 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...) 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. Re: tagging during a release: I think it's fine to have the release:prepare tag a release as uimaj-3.1.1 (without an -rcXXX). I'll figure out some better way to say the suggested message for the retagging... to avoid unintended implications. Re: doing release stuff on a release-branch - yes I'll make that clearer, and say the merge back is via a pull request. Re: release:perform not creating a new branch - yeah - I was guessing a bit, and the log had rolled-off of my terminal history, so I couldn't look... Will fix. 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? (Always learning something new!) -Marshall On 11/1/2019 6:33 AM, Richard Eckart de Castilho wrote: > Hi, > > - Using multiple git identities (https://uima.apache.org/git-svn-notes.html) > - Having had the conversation with you on this, I kind of get what you > mean, but I think for any other reader, > it may be quite cryptic what you mean by "use the local git configuration > for the repo to specify this". > > - https://uima.apache.org/git-conventions.html > - The page gives high level information, but doesn't really say what OUR > conventions are; > having common conventions across all UIMA subproject would seem > reasonable to me > - Here is an (certainly also imperfect) example providing a bit more info > on actual conventions > for another project I work on [1] > > - https://uima.apache.org/git-work-process.html > - Nice :) > - I think it would be good to mention here the format for commit messages > we expect > - Also, adding the requirement to open a Jira issue would be useful, maybe > in "make a branch" or even before > > - https://uima.apache.org/git-release-notes.html > - Once the vote passes, retag the last rc with the rel/tag-name (see below). > -> so what do you enter during the release when Maven asks for the tag? I > would leave the default > (i.e. not add "-rc-X") as we eventually started doing with subversion. > But the text "retag last rc" > might be read to imply that RCs should have "rc" in the tag... > - If branched, merge the release branch back into the master > - Master is protected, we cannot directly commit/merge to it; but the > text doesn't mention that all of the > release stuff essentially needs to happen in a PR (unless we change the > protection scheme) > - (needs confirmation) the tag is checked out into a new branch, ... > - I have not seen an actual new branch being created. What actually seems > to happen is that the Maven release > plugin clones the tag to "target/checkout" - no branches being created > or deleted > - How to roll back a release attempt > - I usually just delete the tag and re-run the release process without > resetting the branch/PR. I don't think your > "git push" after the reset would work since you have rewritten history. > I'm pretty sure it'd need to be a "force" push. > > Cheers, > > -- Richard > > > [1] > https://inception-project.github.io//releases/0.12.2/docs/developer-guide.html#_source_code_management > >> On 30. Oct 2019, at 15:59, Marshall Schor <[email protected]> wrote: >> >> The GIT ref on the left hand nav bar points to some new topics around >> projects >> in GIT. >> >> Please review, and fix, or discuss :-) >> >> -Marshall >> >
