Branko Èibej <brane@xbc.nu> wrote on 07/24/2005 08:27:00 PM:
> I think you're wrong about svnserve not restarting -- it can and will,
> if it's wrapped with some kind of service wrapper.
>
> But more important: we're talking about server administration here.
> Servers usually run unattended. The biggest pain in the ass about
> Windows (as a server OS) is that 99% of the server software running on
> it assumes that someone will always monitor the server through a GUI.
> Your crash report code even assumes that the box actually has a mail
> client installed.
>
> An administrator can view the event log remotely (without a GUI login),
> and can get at files on the server remotely.
>
>
> The patch itself is almsot there, I only counted one tab, a few cases of
> hungarian notation, and some funny indentaion and space-before-paren not
> consistent with the rest of the file.
>
> But before we go and iron out these nits, let's solve the problem of the
> format of the crash reports themselves, please.
I have to say, if I were Stefan I would be a bit frustrated right now.
This is how I see what has happened here.
Stefan submits a code example based on how he has integrated this feature
into TortoiseSVN. He makes is pretty clear that he is not submitting a
patch to be applied as is, but rather a suggestion as to a possible way to
solve this issue.
His submission gets picked apart repeatedly over style issues with
virtually no mention of the technical details and merits of the approach.
Only after he resubmits it several times correcting said style issues is
it now brought up that this approach has some significant areas that would
need to be addressed.
I have no problem with the merit of the disagreement over the details of
this approach but why couldn't you or anyone else have engaged Stefan on
these issues based on his original submission, or at least the one where
he corrected the log message? I understand, agree with and even admire
the attention that goes into patch review on this list, but isn't there
any room for a non-committer to submit code and generate a discussion? I
see this as a real missed opportunity. This project could use another
person or two that is paying close attention to how this software runs on
Windows. This submission could have been an opportunity to attract a new
committer. The technical problems with this approach could have been
raised up front, possibly with some encouragement attached to the response
to see if Stefan wanted to try to solve those problems. If he decided to
solve those problems and came back with a new patch, then you could have
raised the issue about supplying a patch that met the coding standards of
the project. Or perhaps he would have taken the time to do so on his own,
since now he would know he was submitting an actual patch. Instead, I
would just be surprised if Stefan is going to feel any motivation to take
this any further and see if the crashrpt.dll could be modified to dump the
information to a file instead of requiring email and a GUI.
End of rant. This wasn't really directed at just you brane, I am seeing
this more and more as the project is growing and people are probably
feeling more overwhelmed as there are so many proposals flying around. It
just seems like it ought to be possible to detect when something comes
across the list that is more of an idea, then a patch. That idea could be
discussed a bit, and if it gets somewhere and the person that submitted
the idea wants to go back and work on a patch, then they could perhaps be
reminded of the coding guidelines so that they are prepared for those
comments when they eventually submit the patch.
Just some thoughts.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 03:38:33 2005