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

[Joe Shaw]

On Tue, 2001-09-25 at 15: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. 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.

While it's good to try different designs out on your own, it's pretty
customary in a distributed project such as this to propose a design
before going and committing it to the tree.  Even a "heads up" is
appreciated.

As for blind coding, I checked out the tree the other day and tried to
build it, and it didn't even come close to building.  I had to fix
countless typos and completely invalid syntactic constructs before I got
close.  And when I got to the invalid implicit casts (System.Delegate to
EventHandler), I just gave up and checked out the older stuff that Mike
did and built that instead, which needed a simple search and replace of
'DllImport("gtk-1.3")' to 'DllImport("gtk-1.3.dll")'.

> So what if it wont compile now.

In all of the projects that I've been apart of that use CVS, the first
rule of thumb has *always* been "Never Break The Build".  Even if it
doesn't actually work after you commit, that's better than breaking the
build, because otherwise it makes it impossible for other contributors
to get any work done.

> 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 agree wholeheartedly that a design should come first.  But the code in
CVS is an implementation, and an implementation is useless if it doesn't
build, because then *none* of it can be tested (whereas one that doesn't
totally work can usually have certain parts tested).

> 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.

I tend to agree with you here.  I am more of the school of incremental
committing, a work-in-progress, but other people have other methods, and
that's fine.  But that's not an excuse for breaking the build.

> 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.

Having worked with Mike on other projects, I've always found him to be
very responsive to emails and proposals on the lists.  While I've
sometimes wanted him to just commit whatever he has :), the code he
writes is always of great quality, so I can't complain.

> 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.

I'm just a lurker, so what do I know, but I would guess that your
contributions would be welcome.  I think, though, that some compomise on
either side would be beneficial.

Joe