Dear Mr. Benny Malengier,
I'm very grateful for your considerate answer.
Unfortunatelly, I'm not as of today an active member of the open-source community. I restrain myself
to using Debian Stable to get the work I need done. In that sense, I know I'm not a model of participation,
but you can think of me as a highly savy Unix user.
Ever since I started this user phase, I try to stick to Debian Stable. I expect a lot of GRAMPS, it is a
very important program.
The points you make sadden me indeed. It almost seems like every new developer feels he/she can rewrite
the whole thing under the same name as long as nobody complains. That's bad news for common people
who just use it and are not engaged in development, but do expect things to keep a level of coherence.
The vanilla Etch Stable version brought me the GEDCOM export bug. Fortunatelly pinning was easy this
time (rare luck), so I could upgrade to the testing version which fixed it. Then I was sad to learn there was a
major bug with reports - the , , etc. source references simply did not show up in DetAncestralReport.
Fortunately I was able to grab the fix manually from the latest SVN code, but it stunned me how long this
bug persisted, since DDR is now the _single most important descendants report_.
The old report code was far from perfect, but I had already fixed the old python scripts myself to suit my
taste a little better with hours of work. Thing is, I can't keep using version 1.X.X. forever.. (FTM report is
It seems to me that the effort to savory the old code is being overlooked, maybe because of so many new
programmers. I feel that is too bad..
(This has nothing to do with you, I know you're just stating the _way things are_. I'm just disappointed).
The reports are part of a plugin system for which we have a programming guide. Most where written and contributed by users.
Going from 2.0.x to 2.2.x was a big API change, and only those reports where retained that had active developers.
The main developers at that time did not want to keep supporting reports of which no users or developers where known to help maintain it (test, ...).
As nobody complained in the years since, I can only agree to that decision.
Again, feel free to do a feature request for what you want, but be descriptive (example, ....), as the present developers have no or almost no knowledge of version 1.x
GRAMPS does not favor one system over the other, but the community decides how things evolve. One active users supporting a system can mean it does not get discarded. If nobody speaks up, code simplifications and reorganizations will mean things are scrapped that have no supporters.
If you feel strongly about changes, consider signing up to the user mailing list to have a better view of how things evolve.
This bug list is actually only followed by a couple of people of the core devel group, so is no good forum to report non-bug related things.
2007/11/29, James Friedmann <firstname.lastname@example.org>:-------------------------------------------------------------------------Hey again,
There were major changes between version 1.X.X and version 2 concerning
this. The most noticeable was the abandonment of a Register-like numbering
system in favour of a Henry-like numbering system for the Detailed Descendant
I don't understand why GRAMPS should favour one system over the other.
It seems to me that it should strive to offer both major systems as options.
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
Gramps-bugs mailing list