Hey Keith, No problem at all and I am fine with the commit first review later policy. I just want to make sure that Tika isn't driven by internal developer deadlines: trust me you don't want to see the ones I have at JPL :) We'd all be huddled around our computers committing things every 5 minutes but that's another story ;)
Anyhoo, about the MimeTypes.load() call logging message: would perhaps setting the LOG level to LOG.fine() or LOG.finest() address your issue? There's a bigger overall issue here and that's closing the loop on which logging facilities we use in Tika (my +1 for JDK logging again). Because once we've chosen a logging facility, a user can control whether or not that message gets printed in her local configuration by modifying the appropriate logging level and suppressing the others. Cheers, Chris On 10/18/07 3:09 PM, "Keith R. Bennett" <[EMAIL PROTECTED]> wrote: > > Chris - > > I understand what you're saying, and I realize it appeared odd, to say the > least, that I didn't wait, given that my message implied that I would. > After I sent the message I thought about how it had been said on this list > that we often operate by commit first, review later, and I figured that > since this was a minimal change and not controversial, I would commit it, > and reverse it later if anyone objected. > > On another note, would it be all right with you if I disable or delete the > logging call in MimeTypes.load(), or can you tell me how a Tika user could > do so? > > Thanks, > Keith > > > Chris Mattmann wrote: >> >> Hi Keith: >> >>> >>> This is pretty urgent for me -- I have a software deadline tonight and >>> I'd >>> like to use a version of Tika that is checked into subversion. If it's >>> ok >>> with you I'd like to commit the TIKA-81 patch this afternoon, and we can >>> devise a longer term solution later. >>> >> >> For a small piece of agreed upon functionality this is fine, but I just >> want >> to clarify that commits/patches/etc. should not necessarily be driven by >> the >> deadlines of a single developer. Again, in this case it's fine: this was a >> small piece of code that was universally agreed upon and added >> functionality: rather than reorganized, or removed it. >> >> In the future though, I think it should be discouraged to allow such >> timelines to be a driver for committing patches. In this case, you waited >> 7 >> minutes (as far as I can tell) between sending your last email and >> committing the patch. Seeing as though we all live in different >> locations/timezones, etc., this wasn't even enough time for (m)any folks >> to >> reply. >> >> I just wanted to send this as a heads up to you as far as my preference. >> The >> other developers may have their own, which they are entitled to. >> >> Cheers, >> Chris >> ______________________________________________ Chris Mattmann, Ph.D. [EMAIL PROTECTED] Cognizant Development Engineer Early Detection Research Network Project _________________________________________________ Jet Propulsion Laboratory Pasadena, CA Office: 171-266B Mailstop: 171-246 _______________________________________________________ Disclaimer: The opinions presented within are my own and do not reflect those of either NASA, JPL, or the California Institute of Technology.
