On 28 Oct 2013, at 5:22 PM, Jan Lehnardt <[email protected]> wrote: > > On 28 Oct 2013, at 16:07 , Alexander Shorin <[email protected]> wrote: > >> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <[email protected]> wrote: >>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <[email protected]> wrote: >>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <[email protected]> >>>> wrote: >>>>> There is no worry about since it's standard feature for git and >>>>> supported by gitweb and github[1] as well. >>>> >>>> How about the IRC bots? And the email messages (both commit >>>> notifications and PR notifications)? >>> >>> Hm..let's try to figure their support status(: I suppose nobody mind >>> if I push one commit with notes? >> >> Ok, there are three problems with notes: >> 1. Additional commit event without explicit association with related commit >> 2. GitWeb and GitHub doesn't[1][2] show any notices. However, if you >> push notes to GitHub repo - it will >> 3. You should fetch notices in additional to regular clone/pull command >> >> They are looks fine for automatic assignment build status, bug-id, >> making notes on commit like postfactum review, forward references or >> something else, but probably not for our case: tagging each commit >> with affected component(s). >> >> On other hand, tags inside commit message looks more weird[3] since >> not everyone may follow this convention. These tags couldn't be >> changed without editing commit message, so it will be easy to create >> duplicate tags like [doc], [docs], [man], [manual] or [futon], >> [fauxton], [webui], [ui]. Also, >> the perfect spherical commit in a vacuum should contains multiple >> tags: docs, tests, affected component - with limitation of 54 chars >> for first commit line tags would eat a lot of space, making left short >> description useless. >> >> The solution I see quite simple: commit as we doing now. Additionally, >> setup some bot that will "tag" our commits with notes (hi, ASFBot!) - >> it should be easy since each component has his own path prefix (docs >> is in share/docs, tests are in tests/, replicator is in >> src/couch_replicator etc.) so we'll be free from this manual work. The >> only things we need to do, is update .git/config file with fetch = >> +refs/notes/*:refs/notes/* to getting notes from server without >> execution of additional git command. >> >> Thoughts? > > I like Dirkjan’s idea of using `tag:` instead of `[tag]` even more. > I don’t think it is very bad if get multiple tags for the same thing. > `doc: foo` and `manual: foo` is equally easy to skip over and grep > out. But of course we should try to set a standard set and maintain > that on the wiki or in the docs. > > To help with this, we could have pre-commit hooks locally that ensures > we use one of the defined tags. > > Best > Jan > --
I thought we decided to do the tag in the commit a while ago. I try and remember to tag all the Fauxton commits with `Faxuton: ....`
