Matt Johnson <mj1856@hotmail.com> wrote:
I think that we should all make better use of forking and pull-requests for submitting proposed changes. Instead of submitting a patch file to the mailing list, one should fork the GitHub repo, make their changes, then create a pull request.
No, I think all patches should be reviewed and discussed on the mailing list, since it is archived by IANA, and it is where RFC 6557 says discussion should occur.
It also ensures that the author of each and every change is tracked in the commit log.
This is also true for patches posted to the mailing list. Pull requests have the disadvantage that they can make revising proposals harder, and they can make it more inconvenient for a maintainer to do small fix-ups when required. http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/
We should decide how the GitHub issue tracker fits in to the ecosystem. I see that there have been a few issues reported to via the issue tracker in the past, but most things have come through the mailing list.
The mailing list is the correct place to report problems.
Also, consider also that perhaps there are too many merged projects just within the code. For example, tzselect, zic, zdump, etc. might be broken out for better visibility of changes and for clarity of dependent files.
I think this would create more work than it saves. The tz repo is pretty small. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fisher, North German Bight: Northerly or northwesterly 3 increasing 4 or 5. Slight, becoming slight or moderate. Fair. Moderate or good.