[tz] TZDB patches, UTF-8, and Microsoft Exchange

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sun Dec 4 21:55:05 UTC 2022

On 2022-12-04 12:48, Fred Gleason via tz wrote:
> On Dec 2, 2022, at 17:21, Derick Rethans via tz <tz at iana.org 
> <mailto:tz at iana.org>> wrote:
>> This problem would go away if you'd except change requests through GitHub's 
>> pull request feature.
> I for one heartily second this suggestion. While I understand that this can be a 
> sensitive issue for some long-time contributors here, given the composition of 
> TZDB’s audience (veteran coders plus the occasional technically 
> non-sophisticated user), I think anything that simplifies the overall workflow 
> while making the process more transparent to non-coders would be a net win.
>> It's quite a common and modern method to propose changes to open source 
>> software, that I'd expect many would already be familiar with.
> I agree. The GitHub pull request process has become a sort of _lingua franca_ in 
> the code development realm, arguably more so than any other single methodology 
> for managing distributed open source development. In that context, the current 
> _status quo_ is rather *anti*-user friendly in the sense that many coders, when 
> first encountering the TZDB GitHub repo think that they already know how to 
> generate and submit patches; only later discovering that they in fact don’t, 
> since what is arguably the central workflow metaphor of what makes GitHub useful 
> has (seemingly inexplicably) been switched off.
> On the basis of the patches I’ve seen go by on this listserv over the past few 
> years, it would also seem that “easing/reducing maintenance burden” has become a 
> major goal for TZDB. Given that, I would respectfully argue that moving to a 
> PR-based workflow would do more towards that end than any number of minor code 
> polishing changes.
> On Dec 2, 2022, at 17:43, Paul Eggert via tz <tz at iana.org <mailto:tz at iana.org>> 
> wrote:
>> Yes, but GitHub has its own problems. I'd rather stick with email, just as 
>> many other projects use email for this sort of thing. 
> Well, this one at least does. FWIW, none of the other FOSS projects whose dev 
> lists I follow use the traditional patches-via-email workflow any more. While by 
> no means all of them use GitHub, what they all do use is some sort of system 
> that provides automated patch generation/testing/merging along with a GUI option 
> that allows non-coder types some level of visibility into the process.
>> Also, I've been thinking of moving the development repository off GitHub for 
>> other reasons, and I don't want to rely on GitHub-specific features.
> Would you care to share with us what some of those “other reasons” might be?

At a guess, I'd imagine for a multi-GNU project contributor, even using a 
proprietary vendor locked-in (and potentially future deprecated or locked-out) 
platform might be an issue (possibly queried only in person or private DM), as 
it is for many other open source contributors, where even mentioning GitHub 
evokes a spit-blah *NEVER* response, and moving to GH would result in losing 
some contributions.

For some open-source projects, GH is used only as a public and backup repo for 
their primary dev workflows, as are sv.gnu.org and sv.non-gnu.org in some cases.
A number are using in-house and/or public GitLab instances, and others have 
surfaced their email with public-inbox like


where issues and patches can be handled using workflow tools like


It would be good if the IETF, IANA, and/or ICANN made their email available in 
such searchable archives, an area where tz is currently lacking.

Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

More information about the tz mailing list