On 19 September 2013 13:21, Andy Heninger <aheninger@google.com> wrote:
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.

I, too, fail to see any incompatibility.  While I am now mildly receptive to Paul's assertions that some of the changes are not major issues (although I still don't agree with all of them, for reasons others have mentioned), there is a clear separation in my mind: The Fiji change needs to happen.  A vast majority of the others simply don't.  Yes, these other changes may (or may not) improve upon some aspect of tz's broader goals, but regardless they are of a completely different level of importance.

If we are to turn away from the more ardent "if it ain't broke, don't fix it" mentality of the past (and I maintain that that is an okay thing to do), and thus start making changes to the scope and/or spirit of this project, it would indeed be wise to separate that long-term incremental work in the project's evolution from the short-term necessities of publishing correct data for timestamps in the immediate vicinity of now.

I don't see such an approach requiring more than three Git branches: one for official releases, one for timely data changes mostly ready for release, and one for longer-term development of the database and code itself.

On 19 September 2013 15:06, Stephen Colebourne <scolebourne@joda.org> wrote:
I humbly suggest that its not the more open process that caused recent
long threads, but the nature of the changes proposed. One email
described it as "revolution not evolution" IIRC. Had you used the same
open process, but not made any of the controversial changes I simply
do not think that there would have been the same level of debate. ie.
not all of us see the last two months as being "roughly the same as
before".

Not just the nature of the changes proposed, but also how those proposals were presented to the list.  Nearly all of the feedback came after proposed patches were pushed, as it seems little feedback was sought in advance of those patches being created.  I respect the challenges of Paul's maintenance role, and do not fault him for trying to make things easier on himself; however, his personal wishlist for the future of tz is not congruent to the users' collective wishlist.  The more public development process under Paul's leadership is indeed a good thing, but I think it requires a bit more proactive consensus on the direction we should be moving with things.

On 19 September 2013 15:06, Stephen Colebourne <scolebourne@joda.org> wrote:
The real question at this point is not what has happened, but what
will happen. Do you believe you have effective consensus to release as
is? Or do you believe you will gain greater harmony by selecting an
uncontroversial subset to release now?

I'm interested in the response to this.

--
Tim Parenti