DynaGump (was Re: The Gump3 branch)

["Adam R. B. Jack" <aj...@apache.org>]

> The goal now is to allow Gump3 to perform builds and put its data into
> the database so that dynagump can start publishing it.
>
> Everything else is secondary.

I agree, but I think Gump3 is a good idea and I'd like to see it for the
long run. The *right*/focused plan for now is to accept that Gump3 is months
(and a lot of work) off (I know from experience) and that the shortest path
to DynaGump is not Gump3. Work with me to finish the DynaGump actor for
Gump2 that I wrote for you, and let's get it up and running. Let's start
exercising/integrating DynaGump now, not wait for a core re-write.

The best thing that happened to Gump2 is that folks were running Gump1 in
parrelel. Countless bugs were detected/resolved by being able to run side by
side and compare. The best things we can do for Gump3 is allow Gump2 to talk
to DynaGump in parrellel.

If we create a workspace on Brutus called DynaGump and configure it to a DB
with both old and new DB schemas in it, we can have DynaGump up a running in
no time. Nothing (IMHO) better than running DynaGump against DBs formed by
old and new Gump (2 & 3) and also comparing it to the HTML results generated
by Gump2.

Let's allow Gump3 to be team formed by giving it time, whilst we make one
incremental improvement and allow DynaGump to be born. Can we agree on this
as a step in the plan?


> But I also hope that we'll work as a team this time.

Stefano, you make me smile. :-) You are so strong in your opinions (at least
how they read to others) that you come perilously close to stymieing the
community you love. I gave up on Depot, leaving behind parts I love/long to
see, mainly 'cos it was becoming a one man band. Gump, however, is thriving
community, and even when I was the only Python coder we had vast community
efforts in metadata/management/communications
(Wikis/Documentation/Blogs)/problem resolution/and so on. Gump's code is
only a small component of it's whole.

I welcome more coders into Gump code, in fact I've longed for it & tried to
encourage entry many times.Gump2 was a one man band 'cos nobody else wished
to invest time and effort in a possibly dying venture, and yet out of it (in
part by you helping it becoming a TLP) Gump was re-born and is once again
thriving. Gump thrives based of it's contributions to the community, and
hence their contributions to it (via metadata/effort) not due to the code. I
welcome Gump3 as great opportunity for discussion and solving some mistakes
of Gump2. Leo has address some, but not all (as I'll write) that need
solving. I see no point in doing a re-write if after months and much effort
we are no better off, and we've just shifted the one man team to a new man
who we'll near burn out w/ all the 'implementation nits' that pure theory
doesn't prepare you for. I'm no Leo, but I know this, I've been there.

Stefano, we are a team, and as a team we will have different world
views/skill sets/insights -- and yes, have different weakness/make different
mistakes. I'll keep raising concerns/issues based off my one-man-band wealth
of experience, and hope we'll all keep an open mind to what is re-instating
a past mistake, and what is a practical insight. Part of being a team is,
perhaps, you educating me into your views/insights and me pressure testing
them on me.

Let's not let our desire for progress to weaken our team.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: DynaGump (was Re: The Gump3 branch)

[Stefano Mazzocchi <st...@apache.org>]

Boy, this really came across wrong.

First of all (and not for the first time, but probably not for the last 
either.. unfortunately) allow me to apologize: I *really* would love to 
just have time to spend on this, showing how gump could potentially be 
the killer app of the semantic web... but no, I'm supposed to deliver 
other things... :-(

Anyway, this is not an excuse to be rude and disrespectful and I'm sorry 
for that.

Adam R. B. Jack wrote:
>>The goal now is to allow Gump3 to perform builds and put its data into
>>the database so that dynagump can start publishing it.
>>
>>Everything else is secondary.
> 
> I agree, but I think Gump3 is a good idea and I'd like to see it for the
> long run. The *right*/focused plan for now is to accept that Gump3 is months
> (and a lot of work) off (I know from experience) and that the shortest path
> to DynaGump is not Gump3. Work with me to finish the DynaGump actor for
> Gump2 that I wrote for you, and let's get it up and running. Let's start
> exercising/integrating DynaGump now, not wait for a core re-write.\

Good point: SoC also enforces polymorphism.

> The best thing that happened to Gump2 is that folks were running Gump1 in
> parrelel. Countless bugs were detected/resolved by being able to run side by
> side and compare. The best things we can do for Gump3 is allow Gump2 to talk
> to DynaGump in parrellel.

Very good point as well.

> If we create a workspace on Brutus called DynaGump and configure it to a DB
> with both old and new DB schemas in it, we can have DynaGump up a running in
> no time. Nothing (IMHO) better than running DynaGump against DBs formed by
> old and new Gump (2 & 3) and also comparing it to the HTML results generated
> by Gump2.
> 
> Let's allow Gump3 to be team formed by giving it time, whilst we make one
> incremental improvement and allow DynaGump to be born. Can we agree on this
> as a step in the plan?

+1

>>But I also hope that we'll work as a team this time.
> 
> Stefano, you make me smile. :-) You are so strong in your opinions (at least
> how they read to others) that you come perilously close to stymieing the
> community you love. 

Yeah, well, (looking down) I know.

> I gave up on Depot, leaving behind parts I love/long to
> see, mainly 'cos it was becoming a one man band. Gump, however, is thriving
> community, and even when I was the only Python coder we had vast community
> efforts in metadata/management/communications
> (Wikis/Documentation/Blogs)/problem resolution/and so on. Gump's code is
> only a small component of it's whole.

Agreed. Yet, we *must* have more people touching the code and, IMO, we 
should do so by thinking that every line of python code puts us a little 
bit farther away from that goal.

> I welcome more coders into Gump code, in fact I've longed for it & tried to
> encourage entry many times.

Yes, I know. I'm *not* blaming it on you. I'm blaming it more on me.

> Gump2 was a one man band 'cos nobody else wished
> to invest time and effort in a possibly dying venture, and yet out of it (in
> part by you helping it becoming a TLP) Gump was re-born and is once again
> thriving. 

Oh, here I really came across wrong: if it wasn't for your effort, I 
wouldn't have been involved in the first place since I thought that 
Sam's try just had failed to attract attention and momentum. Your energy 
and vitality gave me new hope and I think that's why we have a lot more 
gumpers today (even if they still don't touch the code!).

Hopefully, the next wave will be the final one: when the community 
behaves just like any other and it's diversified enough to sustain any 
single individual leaving.

> Gump thrives based of it's contributions to the community, and
> hence their contributions to it (via metadata/effort) not due to the code. I
> welcome Gump3 as great opportunity for discussion and solving some mistakes
> of Gump2. Leo has address some, but not all (as I'll write) that need
> solving. I see no point in doing a re-write if after months and much effort
> we are no better off, and we've just shifted the one man team to a new man
> who we'll near burn out w/ all the 'implementation nits' that pure theory
> doesn't prepare you for. I'm no Leo, but I know this, I've been there.

Completely agree.

> Stefano, we are a team, and as a team we will have different world
> views/skill sets/insights -- and yes, have different weakness/make different
> mistakes. I'll keep raising concerns/issues based off my one-man-band wealth
> of experience, and hope we'll all keep an open mind to what is re-instating
> a past mistake, and what is a practical insight. Part of being a team is,
> perhaps, you educating me into your views/insights and me pressure testing
> them on me.
> 
> Let's not let our desire for progress to weaken our team.

Very wise.

Again, I apologize. I came across wrong, rude and disrespectful. It was 
not my intention.

I very much welcome the idea of using gump2 and gump3 *both* to drive 
dynagump.

I say let's do it :-)

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: DynaGump (was Re: The Gump3 branch)

[Leo Simons <ma...@leosimons.com>]

On 09-01-2005 17:40, "Adam R. B. Jack" <aj...@apache.org> wrote:
>> The goal now is to allow Gump3 to perform builds and put its data into
>> the database so that dynagump can start publishing it.
>> 
>> Everything else is secondary.
> 
> I agree, but I think Gump3 is a good idea and I'd like to see it for the
> long run.

I think we're all in violent agreement :-D

> The *right*/focused plan for now is to accept that Gump3 is months
> (and a lot of work) off

Yep! Oh man, so much work...

> (I know from experience) and that the shortest path
> to DynaGump is not Gump3. Work with me to finish the DynaGump actor for
> Gump2 that I wrote for you, and let's get it up and running. Let's start
> exercising/integrating DynaGump now, not wait for a core re-write.

The power I'm hoping to maximize on (and I think that was something Stefano
was getting at) is the power of the "clean sheet". Sam did this as well,
only the clean sheet he provided was so amazingly smart that we all had the
hardest time understanding it!

I'm guessing one of the key bits that makes a gump2/dynagump integration
difficult is just how much cool ideas Stefano has in his head wrt dynagump
and how immensely difficult it is to figure out how to weld those ideas into
gump2. Since gump3 has no outputs, no builders, no generators, we can start
with the kind of output we need and go from there. A "reversed" approach if
you will.

By starting with an "empty shell" like gump3, it becomes easier to visualize
how to do those things (its a hard hard problem to get right). From there,
we should be able to figure out together how to make gump2 deliver the
outputs that dynagump needs to fly.

It's not an or/or decision, its and/and. Let's just go with the flow. That's
always worked for the gump community so far. We're that good ;)

> The best thing that happened to Gump2 is that folks were running Gump1 in
> parrelel. Countless bugs were detected/resolved by being able to run side by
> side and compare. The best things we can do for Gump3 is allow Gump2 to talk
> to DynaGump in parrellel.

That makes a lot of sense.

> If we create a workspace on Brutus called DynaGump and configure it to a DB
> with both old and new DB schemas in it, we can have DynaGump up a running in
> no time.

Hehehe. Don't be too optimistic. The dynagump database schema as stefano
built seems to be completely different in some ways from how gump2 is set
up. Thinking about it hurts :-D

> Nothing (IMHO) better than running DynaGump against DBs formed by
> old and new Gump (2 & 3) and also comparing it to the HTML results generated
> by Gump2.
> 
> Let's allow Gump3 to be team formed by giving it time, whilst we make one
> incremental improvement and allow DynaGump to be born. Can we agree on this
> as a step in the plan?

Like I said, it makes sense. What I'd really love to see would be for you to
fully digest all the fledgling concepts in gump3 (after we figure out what
they are :-D) so you can figure out what kind of migration/integration/
reorganisation strategy makes sense.

And also, as I mentioned in my previous e-mail, I think we really don't need
a grand plan to all agree on. Baby steps. Python makes it so easy to glue
things up, there's a miriad of possibilities to make different versions of
gump all interoperate. We can figure all that out!

>> But I also hope that we'll work as a team this time.
> 
> Stefano, you make me smile. :-) You are so strong in your opinions (at least
> how they read to others) that you come perilously close to stymieing the
> community you love.

Hehehe. Take that, you passionate Italian! :-D

> Gump, however, is thriving
> community, and even when I was the only Python coder we had vast community
> efforts in metadata/management/communications
> (Wikis/Documentation/Blogs)/problem resolution/and so on. Gump's code is
> only a small component of it's whole.
> 
> I welcome more coders into Gump code, in fact I've longed for it & tried to
> encourage entry many times.Gump2 was a one man band 'cos nobody else wished
> to invest time and effort in a possibly dying venture, and yet out of it (in
> part by you helping it becoming a TLP) Gump was re-born and is once again
> thriving. Gump thrives based of it's contributions to the community, and
> hence their contributions to it (via metadata/effort) not due to the code. I
> welcome Gump3 as great opportunity for discussion and solving some mistakes
> of Gump2. Leo has address some, but not all (as I'll write) that need
> solving. I see no point in doing a re-write if after months and much effort
> we are no better off, and we've just shifted the one man team to a new man
> who we'll near burn out w/ all the 'implementation nits' that pure theory
> doesn't prepare you for. I'm no Leo, but I know this, I've been there.
> 
> Stefano, we are a team, and as a team we will have different world
> views/skill sets/insights -- and yes, have different weakness/make different
> mistakes. I'll keep raising concerns/issues based off my one-man-band wealth
> of experience, and hope we'll all keep an open mind to what is re-instating
> a past mistake, and what is a practical insight. Part of being a team is,
> perhaps, you educating me into your views/insights and me pressure testing
> them on me.

Amen. And likewise. The cool thing with open source is we all get to learn
from each other!

Cheers!

- LSD
 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org