On 5 Feb 2001, at 15:37, Jason Wharton wrote:

> You are probably right in your suggestions. They just seem like

more hassle

> to me and do not meet my personal preferences. Imagine how

hard it would be

> to produce patch releases if I had so many different sub-

directories to

> worry about. Merging in changes from other developers?

Managing my own

> internal version control? Synchronizing changes between my

notebook, work

> computer and home computer?
>
> One directory for sources does pile things up a bit but it sure

simplifies

> things where the rubber meets the road, development work.
>

Jason, I know that even in small groups of developers version
control can be very tricky (well, I've designed team projects myself,
I'm no newbie in that). But piling things up will just get the project
messy and full of bugs. Well, that what seems logical to me (just a
thought).

> IBO isn't your shrink-wrap variety product. I can't play by those

rules and

> keep up as aggressively as I do. I'm a hybrid between them and

open source

> type projects. I think my blend is friendly enough to pick up good

numbers

> of participants.
>

Why open source projects can't be shrink-wrap products?? What I
understand for a shrink-wrap product is a product that you can sell
or give away or whatever knowing that it's stable and finished. I
know that IBO is far from that, it's very dynamic and all; but every
now and then, it NEEDS a "sealed" version.

But ok, you're the boss here. My concern is that being so
"agressive" will lead to poor quality control. I have to admit that I
haven't found a bug in the IBO engine yet; but I've already found
several in the property editors. They have an "unpolished" feel.

Anyway, maybe all the main user wants is a DCP file, no source of
any kind, maybe some samples and some help files. That's where
a installer goes fine. I could get along with that. But instead I'm
here trying to help the development process. So, don't hit me for
my needs of more hassle. :).

Thanks.
Leonardo Quijano