[tz] An alternate framing of timezone maintenance

[Matthew Donadio]

I was in the process of starting another thread, but will add onto this as
it is similar in spirit.

Is this an opportunity to take advantage of some GitHub features to
differentiate the type of work being done? Off the bat, I am *not*
suggesting a pull-request model, but  think that there is an opportunity to
use branches in a strategic manner to differentiate the type of work.

Currently, the public repository at https://github.com/eggert/tz has a
single branch where work is done. Patches either applied/committed or
proposed are posted here for comment. When a release is made, a git tag is
created on main to represent that point in time.

Could a next step be splitting out the work into separate branches by type
of work? This isn't fully baked (and the names are more descriptive rather
than prosed one), but it could looks like

main - no work is directly done of this branch, only tagged for releases
post-1970 - use this branch for changes for future changes or corrections
to 1970+ timestamps ; ie normal data maintenance
pre-1970 - use this branch for adding or correcting historical data ; ie
normal historical updates
maintenance - use this branch for code updates and bugfixes ; no data
changes
proposed - use this branch for potentially disruptive changes

And then, instead of rolling commits to main, we define a pre-release
window and then agreed upon changes are merged into main, tagged, and a
proper release is cut, built, and formally announced.

There are likely nuances that I am not thinking about, but this is a
thought starter, and I think could allow necessary release to happen as
needed (like the short notice data changes) while not holding up other work.

--Matthew Donadio (matt at mxd120.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210922/bf5a0fc4/attachment-0001.html>