[tz] Proposal: Use Git and Github better

Sun Jul 27 23:30:55 UTC 2014

Thanks, Matt, for getting the ball rolling on this.  I had been wrestling
for a few days over how to write something similar, but you seem to have
touched on most of the major points.

No matter how much we say it is merely “experimental,” simply having a
public repository available to act as a central and timely source for
changes has apparently caused many to see it as “blessed.”  This is not
inherently a bad thing, but we need to adapt our behavior accordingly.

*With regard to Items 1 and 4,* we absolutely should be making use of
branches, for all the reasons you mentioned.  Currently, most patches are
submitted to the list, reviewed, and then applied to master; however,
patches authored by Paul are applied directly to master, and those changes
are reviewed and defended afterwards.  Clearly, this disparity has been an
issue recently, and I sense that it is the source of much of the shock some
are experiencing over the proposed major changes.  Though I personally
believe Paul has made his edits in good faith, I can also easily see how
the idea that the repository is simply “Paul’s playground” may have
developed amongst others.

I would add that if the master branch is always in a state of “positive
agreement,” as it should be, then it is also always “ready for release.”
Every push to master should effectively be a release candidate.  For us,
this may still mean that obvious and urgent hotfixes to data go straight to
master, but this should not be the norm, especially for maintenance tasks.
In particular, it means that the proposed zone-linking and introduction of
time.tab should be done on separate branches to allow for debate and
further refinement of those ideas before this project commits itself to
their use.

To this effect, I agree that it would be better that the repository not be
associated with Paul’s personal account; however, as long as the master
branch is given due deference, this concern becomes somewhat less pressing.

*With regard to Items 2 and 3,* while I’m all for using what Git has to
offer, I’m extremely wary of locking ourselves into Github or any other
similar service.  Others have written, far better than I could, about how
the Github pull request system subverts or otherwise “breaks”
<http://laurent.bachelier.name/2012/05/github-kinda-sucks/> the core
functionality of Git.  If it were up to me, I’d disable pull requests
entirely and exclusively use the mailing list, which keeps more complete
(albeit messier) archives.  Alas, Github does not allow pull requests to be
disabled.  This may mean that Github is not the right place for our
repository.

Further, Github’s communication tools on pull requests and issues are
simply far less flexible than email.  I’d also rather keep our barrier of
entry low, so that even someone who knows nothing about Git can still
submit well-thought changes to the list.  For the simplest patches we see,
a pull request is simply too much overhead.

Even without using pull requests, though, forks can be very useful for
sharing branches.  For all but the simplest patches, we can each alert the
list when we have a branch ready for consideration, copying the proposed
patches to the list for archival, while also providing a link to the branch
for easy review.  For large changes, one can use this method in conjunction
with the flexibility of email to get input from a few more people before
presenting a more refined set of changes to the full list.  We generally
have a low enough throughput that it may still be okay to copy commits over
into master once this process is complete, to avoid messy merges.

In any case, given how central this system has recently become to our
project, we should definitely add clear guidance to both our own
documentation and the IANA pages, conveying how we collectively choose to
use (or not use) the features of Github or any similar service.  Right now,
no such guidance exists.  Hopefully this discussion acts as a starting
point for that.

*With regard to Item 5,* I would point out that, often, code changes are
necessitated by corresponding changes in data.  Breaking apart into
separate projects would make these connections far less obvious, and so I
would prefer that our work remain unified under a single repository.

*I would also like to add Item 6:* Proper use of commits as individual
units for review.  For us, commits don’t necessarily need to be absolutely
minimal; my personal goal is merely that each contains only highly-related
changes and is understandable on its own.  I tried to obey this principle
while developing my recent contributions regarding Russia’s changes.
 (Believe me, I didn’t write them as four neat little patches from the
start!)  It is inappropriate to batch together several unrelated changes
and push them as a single commit, as this makes reviewing more difficult.

A recent example is commit f1ddf32f059c17fa5a1ec24f549d70db36dc5fa9
<https://github.com/eggert/tz/commit/f1ddf32f059c17fa5a1ec24f549d70db36dc5fa9>
of
2014-07-15, in which Paul partially reverts his earlier zone-to-link
changes, but also adds several fixes and bits of commentary which he
discovered while researching the changes.  In the case that further
reversions become necessary, this makes it very difficult to tease out the
“good” from the “bad.”  (This is only exacerbated by our non-use of
branches.)

I will try to model these best practices — especially with regard to Items
2, 3, and 6 — in a separate email I will send shortly, proposing reversions
to the current state of the repository so that we can hopefully adopt these
(or similar) best practices from there.

--
Tim Parenti

On 26 July 2014 14:38, Matt Johnson <mj1856 at hotmail.com> wrote:

> I think it's great that we're using Git and Github as the experimental /
> unofficial repository at https://github.com/eggert/tz.  It's much easier
> to
> track change history looking through the commit log and see the changes
> than
> by reading through emails with patch attachments.  However, we're not
> currently taking advantage of all that this environment has to offer.
>
> -- Item 1 --
> We should be making better use of branches.  We currently have a single
> "master" branch that everything gets committed to.  This is problematic,
> because it doesn't separate things that are certain to be released from
> things that are proposed changes.  For example, the recent time.tab file,
> and the other large-scale proposed changes that are currently being
> debated,
> could have been created on feature branches.  This would have given the tz
> list members a place to look at the proposed changes and make additional
> suggestions (via pull requests) before things are finalized.
>
> As it sits today, since everything is in master, if the proposal is
> ultimately defeated then new commits will have to be made to master to
> revert these changes.  The danger comes if, say we needed to issue an
> emergency release sometime in between.  Since master isn't in a state of
> positive agreement, then one would have to branch from an earlier point in
> history to build a hotfix release, then merge that hotfix back to master
> later.   It's much easier if we can just trust that master always consists
> of things that are certain to be released.
>
> See also:
> https://www.atlassian.com/git/workflows#!workflow-feature-branch
> http://www.git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
>
> -- Item 2 --
> 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.  This allows for place for discussion on proposals
> where the code can be referenced much easier.  It also ensures that the
> author of each and every change is tracked in the commit log.  And finally,
> it makes it much clearer which proposals were adopted and which were not.
> Presently, looking through the mailing list archives, it's quite difficult
> to tell if any given patch was actually applied or not.
>
> -- Item 3 --
> 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.  If we adopt
> the conventions used by other modern projects, then we should be reporting
> bugs through the issue tracker so their history can be more easily found.
> Another benefit is that you can reference issue numbers in commits, and you
> can reference commits in the comments of an issue.  This linking makes it
> quite easy to find the code or data that was changed in response to an
> issue.   The mailing list should probably be used for extended discussion,
> rather than as a place to report issues.  Though, there may be some blend
> of
> both, I personally think that an issue tracker is much more palatable than
> a
> mailing list for many of these kinds of things.  There should probably be
> some guidance document on the iana tz page about what goes where.
>
> -- Item 4 --
> While Paul Eggert is the tz maintainer, and I appreciate his efforts
> greatly, I personally don't feel that it's appropriate for the github repo
> to be in his personal "eggert" account.  There should instead be a common
> "organizational account" for the project, such as github.com/tzdb or
> similar.  ("iana" is taken, but appears to be unused or abandonded.
>  Someone
> may want to inquire about obtaining it, as "github.com/iana/tz" would be
> quite appropriate IMHO).   Though Paul would be the administrator of this
> account, his own personal account would no longer be authoritative.
>
> That also ties back to the idea of pull-requests.  Since Paul makes the
> majority of changes, he would first make them in his own account, and then
> send a pull-request to the main account.  Then a link could be sent to the
> mailing list for discussion on the pull request before it was merged in.
>
> As a side note - I've found that several third-party projects are linking
> to
> the unofficial sources using git submodules.  While this isn't officially
> sanctioned, it would be much better if they could link to iana/tz instead
> of
> eggert/tz.
>
> -- Item 5 --
> While code and data often go hand-in-hand, there are quite a lot of
> projects
> these days that only rely on the tz data.  There are also a lot of releases
> of code changes that don't require data changes.  Having both code and data
> in a single project seems rather inefficient.  I propose that they be split
> back to separate projects, and maintained in separate github repos  (tzdata
> / tzcode).
>
> 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 look forward to feedback on these items.  I'm sure not all will be in
> agreement, but I think it's important that we look forward to new and
> better
> ways to manage this project - rather than just sticking with the ways of
> the
> past.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140727/2935e298/attachment-0001.html>