<div dir="ltr">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.<div>
<br></div><div>But pretty much no matter what is decided here as a policy for managing releases, I can deal with it.</div><div><br></div><div> -- Andy</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Sep 19, 2013 at 8:37 AM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Alan Barrett wrote:<br>
> we have not been aware of such controversial changes before.<br>
<br>
</div>And that's the main difference. In the past, development<br>
was made privately, with intermediate patches sometimes<br>
emailed to the list but often not, and the only real notice of a change<br>
was a new release. Now that I've been doing things on a public<br>
github site, we're getting lots more comments from people affected<br>
by changes as they're being considered. So even though the development<br>
practice is roughly the same as before, and even though the proposed<br>
set of changes is far less intrusive than some previous changesets,<br>
people are understandably concerned by seeing the details of a process<br>
that were formerly invisible.<br>
<br>
I continue to be tempted to go back to the old way of keeping<br>
development private, not only because it'd be less work for me,<br>
but because I suspect it'd be less work for everyone else.<br>
<br>
</blockquote></div><br></div>