[Gtk-sharp-list] Re: FWD: [Mono-cvs-list] Mono CVS: gtk-sharp bobsmith

[Mike Kestner]

I had no intention of this discussion being public, and I am
appreciative of the effort you have expended to try to help me with the
project. You need not respond, but since you chose to flame me publicly
on the list, I will simply provide some clarifications of my position
for posterity and then try to get back to work.

On Tue, 2001-09-25 at 14:36, Bob Smith wrote:
> Ok. I'm done working on gtk-sharp. You assume that everything must be
> perfect when in fact things are unusable.

Actually, I don't expect things to be perfect at this point.  However,
it is completely unworkable for someone to be checking in code to a
distributed project that has never even been exposed to a compiler. Feel
free to find that stance unreasonable, but I find it grounded in logic.

> You MUST expect things to break
> from time to time when there is practically nothing there to begin with.
> gtk sharp is in DESIGN phase, not blind coding phase as you want it to be.

MUST I expect things to break every single time you commit something?
This is not a flame, it is a statment of certainty based on the fact
that you want to contribute to this project without access to a machine
that you can build and test code on.  

> While designing something as complex as a gtk binding, you will need to
> try things out, causing alittle breakage now, rather then spend countless
> hours trying to fix it when you have a few thousand lines of code.

And the only way to effectively try things out is if the code that is
being checked in is being systematically verified for correctness. 

> You are
> managing this project very poorly IMHO. For alittle breakage now, you get
> many many hours saved in the long run. So what if it wont compile now.
> Nothing depends on it. The infrastructure should come first, rather then
> making sure a silly little sample gtk program can compile. We should get
> all the infrastructure in place, debug it, then start worrying about
> getting widgets and other things implemented.

I am undertaking an iterative design and coding paradigm for gtk-sharp,
trying to eat this elephant one piece at a time. I am using the "silly
little sample program" you mention to verify each piece as it is dropped
in. Since C# requires an object oriented approach, any piece which later
proves to be inadequate can be replaced once real profiling data is
available to make intelligent decisions.  I also find your suggestion
that "we" should debug this infrastructure later to be disingenuous,
when you have no access to the tools to do so.  "We" in this context is
clearly me, and I find it easier to debug code when its design and
purpose are fresh in my mind, not at some unspecified point in the
future.  

> Also, this project should
> use CVS as its intended to be used. As a way to let multiple people work
> on the project at once. You keep all your changes to yourself for along
> time, then complain when you cant easily merge your stuff since cvs
> changed. Thats not how cvs works. You make a change, you commit. that way,
> your work is reflected.

Bob, I have committed code to over a dozen open source projects managed
with CVS and never once have I committed code that I had not compiled
and tested first.  Your impression of how CVS is supposed to work is
simply not correct. You make a change, *you verify its correctness*, and
then you commit. The reason I have been keeping code private "for along
time" is because I have had to spend so much effort trying to merge in,
debug, and correct the stuff you have been dumping in, while also trying
to code and debug the functionality that I am working on myself.  Of
course, if I didn't give a damn whether the code worked or not we could
just have a grand old time filling up Ximian's disks with crap.

> All in all, your methods of management do not allow programmers to work on
> the module making more work for you, and the way you manage things meens
> you will have more code churn in the future making even more work.

You and I would be able to work in parallel with wonderful success if
you could check in code that works.  I wish we were able to do this,
because clearly two developers are better than one.  I have worked in
parallel with lots of developers on other projects with success since we
have each taken responsibility for the quality of our commits.  I have
no idea why you think that checking in working code will create greater
churn in the future.

> As I
> havent seen a commit from you in along time, or even you showing up in
> #mono, it seems to me that you dont have much time yourself to work on it
> and things would go alot faster if you could have some help. I suggest for
> the good of the project that you reevaluate your goals. Otherwise,
> a truely usable gtk-sharp wont be released in any reasonable timeframe.

You are correct that I don't have copious amounts of time to dedicate to
this.  Yep, every now and then I leave the laptop closed for a couple
days, this past one for a 3 day jaunt in the woods. That makes it even
more difficult for me to turn away someone who is clearly motivated to
work on the project.  It's unfortunate you don't have access to the
tools to verify your code's quality, and I am simply not willing to
spend the limited time I have available to do that for you.
   
> I'll be able to help out with gtk-sharp again if you want me to, but I'm
> not going to look at it again until you deside how you want to do things.

Thanks again for the effort you have put in to the project.  Perhaps we
can work together on it when mcs and the runtime are up on linux. But my
thoughts on the topic of checking in verified, high-quality code are not
likely to change any time soon.

Regards,
Mike