| Subject | (3) Re: [IBDI] Re: What Ann Harrison promised (longish) |
|---|---|
| Author | Helen Borrie |
| Post date | 2000-09-07T07:33:13Z |
At 10:17 AM 07-09-00 +1000, Robert Schieck wrote:
and I, for one, wish he would come back to the mers list. We can help by
sticking to the "tech support only" rules of the mers list. You can help
by monitoring the list and moving any contentious issues out to IBDI, as I
did with your statement today.
Support personnel and their developer/customer community, too, by
providing this important information without having to be asked and asked
about it, with no response.
by presuming that it was too stupid to understand the code and therefore
must not be given the opportunity to experiment with it except under strict
supervision.
The CVS tools were designed for clued-up community to try things out and
test outcomes in a cooperative environment. In the absence of testing
tools, there has been no other way to work. It is a piece of cake to
unwind commits. The Firebird groups have gone from a "standing start" five
weeks ago to a very promising foundation of understanding about the
interdependencies. Nobody there claims to have all the answers yet; but
Ann's help is proving invaluable.
In that short space of a few weeks, Firebird already has generated a
respectable amount of documentation and has made it available to the public.
Nothing like that happened on the Inprise tree, even though you and Inprise
R & D do have all the tools and documentation that is being denied to Open
Source.
precise order; and 3) is done only on the assumption that the released
code was a "known build". Since that was not even clear to Inprise until
recent days, Firebird can be excused for not being certain what could be
regarded as "known".
Firebird and perhaps reflects your own lack of understanding of the
process. However, thank you for accommodating the Firebird Developer list
on your mers server. It is already helping and the Firebird documenters
are moving as quickly as volunteers can, to build a clearer picture of what
has been evolving there.
observed that the same process is occurring there, except that instead of
it all happening under one roof in Scotts Valley, it is happening for one
platform in Sweden and the US, another platform in Australia and the US,
another platform in Germany, London and Czechoslovakia....and so on. As
the experiences accumulate, the methodology improves. There is always more
than "one right way".
Firebird doesn't yet have access to the facilities that were expected to
have been available to Open Source through a cooperative relationship with
ISC. Synchronising the Firebird tree with the Inprise tree has proved to
be simple - so simple, that it was really easy to discover where the
jrd/cmp.c commits on the Inprise tree originated from. <g>
with the OS activity from the beginning. Provided the pieces are publicly
available, the Firebird tree will benefit from being able to share that.
have a privileged relationship with Inprise would have had similar
arrangements with ISC. The very first thing Inprise did, when it
eventually populated its CVS tree, was to lock out all but yourselves and
close off communication with the many people who have been waiting for half
a year to get their hands on the source code. That is the impasse that
still prevails.
policy absolutely ensures that they won't have the best Open Source people
contributing to their tree. The way it looks currently (until Inprise
opens up its corporate mind to the whole OS issue) is that Inprise
obviously does not have access to the skills it needs to develop InterBase,
unless it blatantly harvests code from the Firebird tree.
So, the benevolent dictator will be there but, unless something changes at
Scotts Valley, it won't be Inprise.
presuppose that it will be able to exploit volunteer developers while
forcing them to build their own tools. There's a pretty critical
assumption there, I think.
However, it is not yet an issue. Inprise does not have anything new of its
own making and appears to be under-resourced for even the most minor
changes. The current kits work. The fire is burning brightly in Firebird
so it's already evident that OS InterBase will work, even if it has to lose
its baptismal name.
issues to the surface.
Unless, somehow, some good, frank communication gets going, I can't see how
Inprise can mend the fences it broke and begin to regain credibility. I
don't need to be convinced that you, Jeff and John Kaster had good
intentions but deliberately employing falsehood and innuendo to sledge the
people at the heart of the community is a very foolish means to an end.
The ISC team committed no wrong by not signing what your boss and his legal
counsel proposed. It was not the wholesome proposal that we started out
with back in February. For the good of yourselves and all of us, please
listen when I counsel you to stop punishing them for sins they didn't
commit. You are making damage for Inprise and you are creating the very
situation which you are trying to blame on others. Stop it for the good of
us all. There is still much you do not know. Be careful about "spins",
lest they force the unacceptable truth out into the light.
Regards,
Helen
http://www.interbase2000.org
___________________________________________________
All for Open and Open for All
___________________________________________________
Team JEDI Member
>The community also has to decide how they are going to handle the InterBaseSo true, and how we miss Charlie. Charlie will not give us spin and fud
>R&D people when the show up on this list. You can continue to "jump" them when
>the surface on this list and drive them away or welcome them to the community
>and use their guidance. After all, the most knowledgable person on the current
>releases of InterBase isn't Ann Harrison nor Jim Starkey, it is Charlie Cairo
>and he is with Borland/InterBase R&D.
and I, for one, wish he would come back to the mers list. We can help by
sticking to the "tech support only" rules of the mers list. You can help
by monitoring the list and moving any contentious issues out to IBDI, as I
did with your statement today.
>The community also had to decide how they are going to handle InterBase TechSame as above applies. Your superiors at Inprise can help their Tech
>Support when they surface on this list, and they will surface here. I hope it
>is with a warm welcome not a "where is my test suite".
Support personnel and their developer/customer community, too, by
providing this important information without having to be asked and asked
about it, with no response.
>Since I am on a roll here, let me continue....Your error - and Inprise's - has been to insult a very clued-up community
>
>I put up the original InterBase CVS archive with the expectations that there
>would be three of them eventually. Mine, IBPheonix/NewCo/FireBird, and
>Borlands. I also expected that the only one left standing in the end would be
>Borlands.
>
>You see (please excuse the plagiarism here from one of my favourite movies),
> >From a source perspective, InterBase isn't easy. You have to want it bad.
>It's
>not easy to build and even tougher to modify if you don't have a lot of
>experience with it.
by presuming that it was too stupid to understand the code and therefore
must not be given the opportunity to experiment with it except under strict
supervision.
The CVS tools were designed for clued-up community to try things out and
test outcomes in a cooperative environment. In the absence of testing
tools, there has been no other way to work. It is a piece of cake to
unwind commits. The Firebird groups have gone from a "standing start" five
weeks ago to a very promising foundation of understanding about the
interdependencies. Nobody there claims to have all the answers yet; but
Ann's help is proving invaluable.
In that short space of a few weeks, Firebird already has generated a
respectable amount of documentation and has made it available to the public.
Nothing like that happened on the Inprise tree, even though you and Inprise
R & D do have all the tools and documentation that is being denied to Open
Source.
>What I had hoped would happen with the CVS archives is:On the contrary, this is pretty close to what is happening. Not in the
>
>1) someone figures out how to build it.
>2) someone create scripts to simplify the build process so everyone can play
>the game (many hands make light work)
>3) the builds are checked against a known build for accuracy so we have a
>known base to work from (there was a plan for this)
>4) cosmetic clean ups of the code are done, changes to correct compile
>warnings are done and builds are checked against the base from 3
>5) when 4 is completed, then bug fixes etc are done.
>
>Unfortunately this is not what happened and you can see the results.
precise order; and 3) is done only on the assumption that the released
code was a "known build". Since that was not even clear to Inprise until
recent days, Firebird can be excused for not being certain what could be
regarded as "known".
>OnIt appears you have not looked closely enough at what is happening in
>FireBird, changes are put in and then taken out as they break things. The side
>effects of changes are difficult to understand without a lot of experience
>with the product.
Firebird and perhaps reflects your own lack of understanding of the
process. However, thank you for accommodating the Firebird Developer list
on your mers server. It is already helping and the Firebird documenters
are moving as quickly as volunteers can, to build a clearer picture of what
has been evolving there.
>I should point out that at InterBase R&D, you compile it on windows andIf you had joined the Firebird Developers list yourself, you would have
>compile on a Unix box to see if you have messed anything up before you put
>change back to the archives which is why item 2 was listed above.
observed that the same process is occurring there, except that instead of
it all happening under one roof in Scotts Valley, it is happening for one
platform in Sweden and the US, another platform in Australia and the US,
another platform in Germany, London and Czechoslovakia....and so on. As
the experiences accumulate, the methodology improves. There is always more
than "one right way".
Firebird doesn't yet have access to the facilities that were expected to
have been available to Open Source through a cooperative relationship with
ISC. Synchronising the Firebird tree with the Inprise tree has proved to
be simple - so simple, that it was really easy to discover where the
jrd/cmp.c commits on the Inprise tree originated from. <g>
>Of the three CVS archives, the InterBase one is the best. The InterBase CVSYes, it would have saved a lot of work-up time to have had that integrated
>has a complete set of backed up databases fully integrated in with their build
>scripts. I ran over them a couple of time for a windows build and got it down
>to a two script build. I was working on getting rid of the korn shell
>requirement but I haven't got back to it in a month or so. From their
>archives, it was possible to do a complete build including the codes program
>with what they presented without a whole lot of work.
with the OS activity from the beginning. Provided the pieces are publicly
available, the Firebird tree will benefit from being able to share that.
>I am a committer on the InterBase CVS, I haven't committed anything. All myIn other circumstances, the skilled coders of the community who do **not**
>changes (very simple stuff) were sent to InterBase R&D and they made the
>changes after checking out my requests.
have a privileged relationship with Inprise would have had similar
arrangements with ISC. The very first thing Inprise did, when it
eventually populated its CVS tree, was to lock out all but yourselves and
close off communication with the many people who have been waiting for half
a year to get their hands on the source code. That is the impasse that
still prevails.
>As it had been said, Open source needsIn a technical sense, that is indisputable. However, Inprise's present
>a benevolent dictator and InterBase R&D fills the role nicely as they have the
>experience with InterBase to assess the side effects of changes.
policy absolutely ensures that they won't have the best Open Source people
contributing to their tree. The way it looks currently (until Inprise
opens up its corporate mind to the whole OS issue) is that Inprise
obviously does not have access to the skills it needs to develop InterBase,
unless it blatantly harvests code from the Firebird tree.
So, the benevolent dictator will be there but, unless something changes at
Scotts Valley, it won't be Inprise.
>As an added bonus, the likely hood of getting a build certified off of theThat, is the way it looks, regrettably - current policy appears to
>InterBase CVS is significantly higher than from any other site including mine.
presuppose that it will be able to exploit volunteer developers while
forcing them to build their own tools. There's a pretty critical
assumption there, I think.
However, it is not yet an issue. Inprise does not have anything new of its
own making and appears to be under-resourced for even the most minor
changes. The current kits work. The fire is burning brightly in Firebird
so it's already evident that OS InterBase will work, even if it has to lose
its baptismal name.
>Enough stuff, I leave it for the community to make their choices and hope theyAnd, Rob, I welcome your taking the opportunity to bring some of these
>choose wisely
>
>Rob
issues to the surface.
Unless, somehow, some good, frank communication gets going, I can't see how
Inprise can mend the fences it broke and begin to regain credibility. I
don't need to be convinced that you, Jeff and John Kaster had good
intentions but deliberately employing falsehood and innuendo to sledge the
people at the heart of the community is a very foolish means to an end.
The ISC team committed no wrong by not signing what your boss and his legal
counsel proposed. It was not the wholesome proposal that we started out
with back in February. For the good of yourselves and all of us, please
listen when I counsel you to stop punishing them for sins they didn't
commit. You are making damage for Inprise and you are creating the very
situation which you are trying to blame on others. Stop it for the good of
us all. There is still much you do not know. Be careful about "spins",
lest they force the unacceptable truth out into the light.
Regards,
Helen
http://www.interbase2000.org
___________________________________________________
All for Open and Open for All
___________________________________________________
Team JEDI Member