It is used *once* ?! Bleh. Then I'd ask why we even have the type, especially why does it exist in svn_types.h.
Your other points: quite fair. I assumed tristate_t was much more important due to its placement in svn_types. Cheers, -g On Tue, Nov 9, 2010 at 12:15, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > I would +1 everything you said... if Julian had changed svn_boolean_t. > > He changed svn_tristate_t, which is used exactly once in trunk, so > I don't see the need to be as careful with it. > > The caveat? This assumes that --- as we ought to --- we not act on > feedback differently because it comes after the change has been > committed. Feedback that would have caused a "No, let's not commit this > yet" reaction if provided early should cause a "OK, let's revert this > for now then" reaction if provided later. > > Daniel > > Greg Stein wrote on Tue, Nov 09, 2010 at 00:47:27 -0500: >> On Thu, Nov 4, 2010 at 08:45, Hyrum K. Wright >> <hyrum_wri...@mail.utexas.edu> wrote: >> > On Thu, Nov 4, 2010 at 7:43 AM, Julian Foad <julian.f...@wandisco.com> >> > wrote: >> >... >> >> Having said all that, +1 on removing the gratuitous inconsistency by >> >> applying this patch. >> >> >> >> Committed r1030909. >> > >> > Gah. Can we please wait a little bit longer on this kind of stuff to >> > allow people in other timezones a chance to weigh in? >> >> I have raised this before, Julian. For making changes with some >> impact, where feedback from the community is desired, then the >> standard Apache rule is 72 hours. And even if we don't worry about >> rules, it is simply *respectful* to give others a chance to speak up. >> >> Last time, you bumped the format with something like FOUR hours >> notice. That was really bad. I'm not sure about the extent of the >> badness here (tho changing something as central as svn_types.h seems >> pretty obvious as an "input-required" change), but given that another >> member of the community has said "woah. too quick", then you REALLY >> need to slow down. >> >> This isn't an attempt to slow down your work. This is an attempt >> (bordering on requirement) for you to work with the rest of the >> community on changes to our codebase. >> >> -g >
