couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fedor Indutny <fe...@indutny.com>
Subject Re: git commit: Automate maintenance of the THANKS file
Date Thu, 21 Jun 2012 14:40:14 GMT
Done ;)

Cheers,
Fedor.



On Thu, Jun 21, 2012 at 6:37 PM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Jun 18, 2012, at 12:29 , Fedor Indutny wrote:
>
> > Speaking of that, can I ask to add me to THANKS file? ;)
>
> Done, can you in turn close your PR on GitHub? :)
>
> Cheers
> Jan
> --
>
>
> >
> > Cheers,
> > Fedor.
> >
> >
> >
> > On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <jan@apache.org> wrote:
> >
> >>
> >> On Jun 17, 2012, at 22:05 , Paul Davis wrote:
> >>
> >>> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <jan@apache.org> wrote:
> >>>>
> >>>> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
> >>>>
> >>>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <jan@apache.org>
> wrote:
> >>>>>>
> >>>>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
> >>>>>>
> >>>>>>> I'm not sure I like this so much. Playing around with it,
its a bit
> >>>>>>> prone to screw ups.
> >>>>>>
> >>>>>> I just don't want to maintain this file manually any more. It
is
> >>>>>> error-prone and makes merging user-contributions a pain. I'm
happy
> >>>>>> to have this implemented in any other way, but I think we should
> >>>>>> try to remove any mechanical steps from maintaining our source
if
> >>>>>> we can. I hope you agree! :)
> >>>>>>
> >>>>>
> >>>>> Its an extra step but not one that I find to be particularly onerous.
> >>>>> Given that we're already working on codifying merge practices I
don't
> >>>>> see why we don't just add a check box for "includes commit adding
> >>>>> yourself to the THANKS file if this is your first contribution"
that
> >>>>> we look for.
> >>>>
> >>>> That's a fair point, but this has annoyed me forever.
> >>>>
> >>>>>>> It also breaks if AUTHORS.gz exists before you
> >>>>>>> pull in new commits. We could solve that by forcing it to
build
> every
> >>>>>>> time but that's a bit of a hack for not much gain.
> >>>>>>
> >>>>>> Can you explain how it breaks if AUTHORS.gz exists before the
merge?
> >>>>>> If you mean THANKS.gz, my idea was that this is only relevant
on
> >>>>>> packaging time (make distcheck) where THANKS.gz by definition
does
> >>>>>> not exist.
> >>>>>>
> >>>>>
> >>>>> I'm not sure its a good idea to have a file that is only built
> >>>>> correctly in special circumstances.
> >>>>
> >>>> I'm happy to add an rm -f $< to the target.
> >>>>
> >>>>
> >>>>>>> Its also got Benoit in there twice since he made commits
with
> >> slightly
> >>>>>>> different author/committer names which also seems awkward.
> >>>>>>
> >>>>>> The subsequent .mailmap commit fixes the dupes. The push emails
seem
> >>>>>> to be delayed atm, I reported this to danielsh on #asfinfra.
> >>>>>>
> >>>>>
> >>>>> I'm confused. You've removed one manually curated file only to add
a
> >>>>> new one that just modifies the build of the first? Seems like a
lot
> of
> >>>>> gymnastics.
> >>>>
> >>>> .mailmap solves more than just this.
> >>>>
> >>>>
> >>>>> In a perfect world I would be all in with you on this but
> >>>>> unfortunately a large number of people don't spend time checking
> their
> >>>>> user settings before pushing commits around. Instead of just adding
> >>>>> people to a file the first time they make a commit this means I
have
> >>>>> to go and check that the THANKS file is generated properly and then
> >>>>> maybe update .mailmap if not and recheck that I got it correct.
> >>>>
> >>>> Fair enough, wanna revert?
> >>>>
> >>>> Cheers
> >>>> Jan
> >>>> --
> >>>>
> >>>>
> >>>
> >>> Playing with it a bit to see if I can make it build correctly and also
> >>> just build the AUTHORS file. I'll leave it around for a bit but won't
> >>> promise that the first time I spend more than 30s screwing with
> >>> mailmap that I revert it.
> >>
> >> Heh, that took me a while to get right :)
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >>
>
>

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