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 --
signature.asc
Description: Message signed with OpenPGP using GPGMail
