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

[Brian Inglis]

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

	https://lore.kernel.org/

where issues and patches can be handled using workflow tools like

	https://git.kernel.org/pub/scm/utils/b4/b4.git

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