couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: [PROPOSAL] tag our commits
Date Mon, 28 Oct 2013 16:12:06 GMT

On 28 Oct 2013, at 5:22 PM, Jan Lehnardt <jan@apache.org> wrote:

> 
> On 28 Oct 2013, at 16:07 , Alexander Shorin <kxepal@gmail.com> wrote:
> 
>> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <kxepal@gmail.com> wrote:
>>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
>>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kxepal@gmail.com>
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: ....`
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message