couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [PROPOSAL] tag our commits
Date Mon, 28 Oct 2013 15:22:48 GMT

On 28 Oct 2013, at 16:07 , Alexander Shorin <> wrote:

> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <> wrote:
>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <> wrote:
>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <> 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.


View raw message