couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [PROPOSAL] tag our commits
Date Tue, 29 Oct 2013 08:29:53 GMT
On Mon, Oct 28, 2013 at 4: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.
>
>
>
My only objection to the `tag:` fomat is that this is not the way you tag
an email generally. Since the first line of the commit is generally the
subject of the message and the patch you get with format-patch, I think
that using a common way to tag the subject may be better.

I really don't think that's weird for those who are mainly using the mail
to handle the git commits and some are.

Maybe that worth to take it in consideration?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message