<div class="gmail_quote">On Thu, Jun 18, 2009 at 6:00 PM, Tom Lane <span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">Braden McDaniel  writes:<br>
> On 6/18/09 5:42 PM, Tom Lane wrote:<br>
</div><div class="im">>> I don't think the guidelines should tell people what to do one way or<br>
>> the other.<br>
<br>
</div><div class="im">> My impression is that the term "guideline" indicates that maintainers<br>
> should use their discretion.  A guideline indicates the default position<br>
> to take in the absence of information that would lead to a different<br>
> conclusion.<br>
<br>
</div>When the proposed additions involve the use of the word MUST in capital<br>
letters, one is left with the inescapable impression that the intention<br>
is to remove one's discretion.<br>
<br>
I wouldn't have any problem with an addition that listed reasons why one<br>
might or might not want to rebuild derived files (including all the<br>
points touched on in this discussion), and then said "use your own<br>
judgment about this".  That is not what the proposal reads like, though.<br>
</blockquote><div><br>Then please give suggestions to improve the proposal draft. There is an obvious confusion for what can be regarded as the pre-built binary. pdf and mo files are binary but are they covered with the existing guideline? At least, this needs to be sorted out. doxygen or other stuff can be left out of the proposal...<br>

<br>Saying "I don't like this proposal because of X" will not help much for improving a draft. Also comments like "I don't agree with this proposal, I want to keep things as is" has little value unless it is said during an FPC vote.<br>

<br>On the other hand, being constructive just helps.<br><br>Thanks,<br>Orcan<br></div></div>