Russ Allbery <rra@stanford.edu> wrote: |Andy Heninger <aheninger@google.com> writes: |> While noisy, I think the very public development process is a good |> thing, and that we will end up with better data overall as a result. I |> don't see this as being at all incompatible with having quick, small |> updates for late breaking rule changes. | |The tricky part with quick, small releases is that, if you've already |staged things for the next release, you have to revert those changes or |you have to branch. (You can, of course, branch proactively to do the |staging, but it amounts to the same thing.) | |This means an additional level of complexity to the development process |and possibly the versioning process that historically hasn't been used, |and basically means more work for Paul. This is not true with modern VCS, and especially git(1). I can think of a number of scenarios that could be used to cleanly separate development of TZ, and having different mainline branches for data and code changes comes to mind immediately. Additional sub-branches for speculative work may be easily created as forks from those branches. That is what happens today almost everywhere. (In projects much larger than TZ, though possibly more mature in respect to code changes.) And if there really is a change so pervasive that it causes conflicts, there is git-rerere(1) (i never had a need to use, however). Anyway, like that, in the worst case (no git-rebase(1) easily possible), you git-cherry-pick(1) a range of commits plus possibly other commits individually onto the main line of development. I'm pretty sure that Paul Eggert is aware of all this. I'm convinced even complex workflows with multiple branches as mentioned in the first paragraph are easier to accomplish and much easier to maintain than with sccs(1) or cvs(1) and patchbombs, that are mailed manually. |Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> The pretty old one --steffen