On 10 February 2017 at 20:58, J William Piggott <elseifthen@xxxxxxx> wrote: > This branch adds the parse_datetime module from the gnu > portability library. Assuming gnulib integration is wanted then replacing bootstrap process, deduplicating pieces of code in include/ with gnulib versions would be in todo list. For example why one would keep util-linux xmalloc() when gnulib provides the same. Same is true for close_stdout(), and many other functions. While code reuse is good idea I have doubts if this really is direction where to go to. It feels like gnulib integration is a big change, and easy only when done incomplete or inadequate way. Choosing the former is a bit risky - I assume it is really difficult to know how much coding resource will stick around doing the needed, how long it might take when reviews and testing is included to a timeline. Poor intergration has it's obvious problems. Duplication of 'same' code, leading to confusion which code paths are used where. This can result bugs that are easy to miss, e.g., end up being part of releases. If the integration is kept minimal then we might result in adding 25k lines of code to replace one exec() that has worked fairly OK for years. That in inself feels awkward. If asked would I be interested of gnulib challenge I would say yes, with a catch, there is only so few hours per week I have time for this so without a lot of people saying 'yes, lets do this' timeline getting integration completed becomes unacceptably long. -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
