Thanks. a) Comments on the patch:
1. Essentially the current version of configure.ac was written by me: $ git shortlog -- configure.ac configure.in | grep '^[^ ]' Benedikt Morbach (1): Bernhard Voelker (2): Eric Blake (4): James Youngman (197): Jim Meyering (1): Kevin Dalley (12): Stefano Lattarini (1): 2. I don't think editing the .po file copyright headers is really a solution here, since they will just be over-written the next time the relevant translation team provides an update. You're welcome to apply the patch (despite item 2 because even in the worst case it's harmless). b) Sure, go ahead and push patches to the 4.6 branch. Generally yes, for low-risk patches. c) I'd like input from the other committers and from the principal downstream consumers (e.g. Andreas, Kamil) before making a choice, since it's the committers who would need to maintain the parallel branches and the downstream maintainers who (allegedly) benefit. Let's have a data-based discussion about what works for everyone - in a separate thread, I'd suggest. c, part 2) Happy to change the naming scheme, I'm not especially attached to the current one. d) We could populate the .x file for files which will be persistently problematic (such as regexprops.texi). I think fixing the translations will require coordination with the Translation Project. Or hacking the bootstrap script or the update-copyright script. On Mon, Jan 4, 2016 at 8:11 AM, Bernhard Voelker <m...@bernhard-voelker.de> wrote: > On 01/04/2016 01:37 AM, James Youngman wrote: >> Thanks for doing this. >> >> Sorry about the mid-air collision on the copyright updates. All the >> other patches look good to me, please apply! > > Thanks for the review - I pushed at the master branch. > > 4 questions: > > a) There are some parts left from my PATCH 5/8. I've updated > the patch (see attached). Shall I push it? > > b) Do you want me to push to the 4.6 branch, too? (see c)). > > c) Will we maintain a 4.6 and a 4.7 line in parallel (although > we don't have anything big for master)? I must confess that > I'm a bit confused with this model. Other projects just leave > bug fixing up to downstream distributions which can pick commits > as they like. > Furthermore, it is common to have a 2-block release version string > only; by this, they can use gnulib's "build-aux/git-version-gen", > and have a proper distribution tarball name matching the Git > revision (e.g. "grep-2.22.15-40ed.tar.xz") at any time instead of > a static name "...-4.7.0-git". > Would you consider this a good thing for findutils, too? > > d) Another 'make update-copyright' would complain - (how) can we > fix this, too? > > po/findutils.pot: warning: copyright statement not found > > Thanks & have a nice day, > Berny -- -- This email is intended solely for the use of its addressee, sender, and any readers of a mailing list archive in which it happens to appear. If you have received this email in error, please say or type three times, "I believe in the utility of email disclaimers," and then reply to the author correcting any spellings (and, optionally, any incorrect spellings), accompanying these with humorous jests about the author's parentage. If you are not the addressee, you are nevertheless permitted to both copy and forward this email since without such permissions email systems are unable to transmit email to anybody, intended recipient or not. To those still reading by this point, the author would like to apologise for being unable to maintain a consistent level of humour throughout this disclaimer. Contents may settle during transit. Do not feed the animals.
