Re: [PATCH 1/7] compat/regex: add a README with a maintenance guide

> Hi Arnold,
>
> On Sun, 14 May 2017, arnold@skeeve.com wrote:
>
> > With respect to bug fixes that may have happened downstream, please do
> > let me know of any.  But I do request it as a bug report to
> > bug-gawk@gnu.org and not just a pull request with no commentary.
>
> I dabbled with updating our compat/regex/ myself, a while ago, and just
> found my notes. Note: at least some of these notes should help with the
> next iteration of Ævar's patch series.
>
> First of all, our original import could have been accompanied by better
> documentation what was done. Granted, back then gawk was still maintained
> in CVS, so things would have been a little tougher with regard to, say,
> specifying which gawk revision was imported. In the meantime, gawk uses a
> Git repository, though: http://git.savannah.gnu.org/r/gawk.git. Therefore,
> we can say pretty precisely that gawk's 40b3741f (Bring in development
> gawk changes., 2010-11-12)) was imported into Git as per d18f76dccf
> (compat/regex: use the regex engine from gawk for compat, 2010-08-17).
>
> My approach of updating compat/regex/ differed from Ævar's in that I
> checked out that Git commit, applied the interdiff to gawk's newest
> commit, and rebased that onto the current commit of Git. But I think Ævar
> & Junio's approach (replace compat/regex/ wholesale by the newest gawk
> revision's files, then re-apply clean patches of our `git log 40b3741f..
> -- compat/regex/` on top, as individual commits) is saner, as it will make
> future updates substantially easier.
>
> With my approach, I still had 16 merge conflicts, pointing in large part
> to changes we do *not* want to contribute back: gawk's code style differs
> from ours, and we adjusted the files in compat/regex/ to ours (which I
> think was a mistake).
>
> I also reinstated support for compiling with NO_MBSUPPORT, which included
> a new guard of the btowc() definition.
>
> I also had to reintroduce explicit #defines of bool, true and false, as
> gawk's source code split those out into their own header file.
>
> I apparently also "skipped a guarded #include <stddef.h> that was not
> actually necessary, but simply a late fixup to a997bf423d (compat/regex:
> get the gawk regex engine to compile within git, 2010-08-17)", but I do
> not remember what that was about.
>
> In summary, I do not think that any of our patches should go "upstream"
> into gawk's source code, as they are pretty specific to Git's needs.
>
> Ciao,
> Johannes