On Tue, Dec 29, 2009 at 1:26 PM, Brian Matherly <brian@gramps-project.org> wrote:

>> Another way to say this is "We don't want to
>> throw out the baby with the bath water". It is
>> important to stay focused on our primary use cases - which I
>> think Gerald has accurately identified. Changing the data
>> model used by Gramps desktop application could hinder the
>> application's performance in our primary use case.

> Yikes! Nothing that we are discussing would hinder Gramps
> Gtk... part of the point was that what was good for one
> (only unserializing/retrieving what you need) would be good
> for both.

Nobody is going to allow Gramps-GTK to be hindered. But your "point" about "what's good for one is good for both" hasn't been proven (yet).

>> This makes me wonder ... has anyone considered that there
>> may be so little in common between Gramps-Connect and the
>> Gramps desktop application that it might not even be worth
>> sharing code at all? What real benefit do we gain by
>> sharing?

> You guys act like you're just realizing that
> Gramps-Connect exists... yes, a lot of discussion has been
> made, and it was decided that a lot can be shared.
>> I've seen Doug crank out large amounts of code in a
>> short amount of time. I bet that if we said "Doug, take
>> what you want from Gramps, start your own project, and
>> customize it however you see fit", he would be done by
>> now.
> I don't know if he'd been done by now, but he'd
> be pretty sad that the group that he thought he was working
> with told him to go away.

No one is going to tell you to go away. Please don't take these questions so personally. The community (of which you are a part) will decide what is best.

>> I'm just wondering out loud and not trying to advocate
>> one way or another. But it is a question worth asking ;)

> That question could have been asked, perhaps, when the
> suggestion was first made. Or when I wrote a GEP. Or when
> Benny suggested Django. Or when we had a SVN branch. Or when
> Benny suggested that we move it over to trunk. Or when I
> proposed that we have a student work on it for a semester.
> Or when we picked a name for the project. But at some point,
> please, stop asking this question and either accept that
> gramps includes gramps-connect, or reject it.

You obviously don't know our own strength. You single handedly produce VOLUMES of traffic on the wiki, bug tracker, mailing list, blog and in SVN (all of it valuable and important, by the way). There are many nights when I sit down for the precious little time I have for Gramps and it is all I can do to read all the messages that result from your work (and if I'm lucky, respond). You must either spend 8 hours a day working on Gramps, or you have super-human programming abilities. You are just going to have to accept that not all of us have super-human programming abilities and you are going to have to stop occasionally and let the rest of us catch up. That's what Gerald and I are doing now.

Additionally, when all the past decisions were made, they were made with the information that was available at the time. As development progresses, we learn more about what we have, and how things are fitting together. This new information opens the possibility that we may want to change a decision that we made in the past. The worst thing we can do is dig our heels in and say "I don't care if there's a better way - we've already made the decision". So, when someone challenges a past decision, we need to consider the new information and re-evaluate.

Right now, I think we have new information. It appears that code we once thought was easily shared between gramps-connect and gramps-gtk may not be as easily shared as we thought. Am I right, is that new information? Because it is to me.

None of this is new, as Benny has been discussing this since at least August, and he was interested in pure speed up for Gramps Gtk:


I hope you can sympathize with my situation. I'm doing the best I can to keep up, honestly.

When you get caught up, please let us all know if gramps-connect is indeed part of gramps.



This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
Gramps-devel mailing list