> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
