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.