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.

But pretty much no matter what is decided here as a policy for managing releases, I can deal with it.

  -- Andy



On Thu, Sep 19, 2013 at 8:37 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Alan Barrett wrote:
> we have not been aware of such controversial changes before.

And that's the main difference.  In the past, development
was made privately, with intermediate patches sometimes
emailed to the list but often not, and the only real notice of a change
was a new release.  Now that I've been doing things on a public
github site, we're getting lots more comments from people affected
by changes as they're being considered.  So even though the development
practice is roughly the same as before, and even though the proposed
set of changes is far less intrusive than some previous changesets,
people are understandably concerned by seeing the details of a process
that were formerly invisible.

I continue to be tempted to go back to the old way of keeping
development private, not only because it'd be less work for me,
but because I suspect it'd be less work for everyone else.