[GNC] Please address broken QIF import

[Jim DeLaHunt]

On 2024-04-23 14:31, Yann Salmon via gnucash-user wrote:
> Since there is, if I understand correctly, a fix to this major bug, I 
> really think a 5.6.1 release would be helpful.… 
On 2024-04-24 15:24, Yann Salmon via gnucash-user wrote:
> …the one thing I learned is : you do not break things, and if you do, 
> you unbreak them as quickly as possible.…
>
> …I would be interested to know the bigger picture that I am obviously 
> missing in the decision not to publish a .1 that fixes a regression 
> (especially on a stable release) and allows Otto Normaluser and his 
> Grandma to quickly get back on their feet by simpling doing what they 
> know and have been educated to do : upgrading their software. 

Oh, I think I can help you see the bigger picture.

Please run a report on your financial records in GnuCash. Look for all 
the payments you made to the GnuCash developers, in order to have the 
use of GnuCash software.  If your records are like mine, the total 
amount will be:

0.00 EUR (approximately 0.00 CAD, 0.00 USD, 0.00 CNY, at current 
exchange rates)

I suspect that the GnuCash team has spent at least double that amount, 
and applied it to making a 5.6.1 release. It was sufficient for them to 
reach 0% of the way to completion. (I am being sarcastic. I don't know 
the internals of the GnuCash project.)

Putting aside sarcasm, please remember that the GnuCash developers are 
volunteers. They are donating their time and expertise to develop 
GnuCash. There are not many of them. Yet they deliver regular releases, 
complete with bug fixes, and ever-increasing capabilities.  The 
appropriate tone to take with them is one of gratitude.

At the same time, the GnuCash developers have granted you a license to 
GnuCash's source code. You are permitted to see the source code, to 
diagnose the problem yourself, and to come up with a fix. If you wish, 
you can donate the fix back to the GnuCash developers. Or, you could 
make your own 5.6.1 release with the fix (but this is "forking", and you 
should give the new software a different name).  If you own skills do 
not extend to diagnosing and fixing the problem, you are free to hire a 
skilled software engineer, and have them diagnose, fix, and release a 
version of the software for you. If you want to pay the software 
engineer for an extended time, so that they can build up a relationship 
with the GnuCash developers, they might be able to take on the task of 
making bug-fix releases. It could be your contribution to GnuCash. 
Please, go right ahead!

However, you may discover that this costs you more in time and money 
than the 0.00 EUR which you have paid for GnuCash so far.

Best regards,
      —Jim DeLaHunt


On 2024-04-24 15:24, Yann Salmon via gnucash-user wrote:
> Hello,
>
> Le 23/04/2024 à 23:48, David Carlson a écrit :
>> Sir,
>>
>> In my experience most financial institutions that offer QIF exports 
>> also offer OFX format which will often go under a similar name.
>
> Alas, a hundred times alas, not always. Not in France, at least. They 
> should…
>
> I was able, however, to use <https://github.com/georggrab/qif2ofx>. I 
> had to reverse all transactions (which is easier to do in the QIF, 
> btw) because my bank seems to directly produce a QIF for my point of 
> view while GnuCash seems to expect a QIF with transactions from the 
> bank's point of view, but that is another story.
>
>
>> If you need the QIF format then you will probably be stuck either 
>> waiting for the 5.7 windows release or reverting either to an earlier 
>> 5 series or maybe even 4 series if you have an older Linux based 
>> machine as I do.
>
> Even though the Gnucash team has been releasing new versions at a 
> steady and formidable rythm of one every 3 to 4 months, that still 
> makes 4 months of non-working QIF import — downgrading is really not a 
> straightforward route as software managers, for good reasons, make 
> upgrading software easy and downgrading it harder (and one would have 
> to get the idea of doing so).
>
> While I admit I am not and have never been trained to be a software 
> project manager, I did write some (extremely) modest pieces of 
> software that are used by some other people, and the one thing I 
> learned is : you do not break things, and if you do, you unbreak them 
> as quickly as possible.
>
> People can be patient with a desired functionnality not being present 
> yet, or even a new functionnality being buggy from its start, but not 
> when something that had been working, and that they are thus using, 
> stops working. It disrupts their workflow, it may mean that something 
> they had to do by some date, and that they were expecting to do with 
> the software, suddenly cannot be done as planned anymore : all in all, 
> it makes the software look unreliable — if faults appear today, and 
> are not fixed, then more and bigger faults could appear tomorrow. And 
> I think this is especially true for a software like GnuCash that is 
> important to users because it is usually great at doing important 
> things like accountancy.
>
> I would be interested to know the bigger picture that I am obviously 
> missing in the decision not to publish a .1 that fixes a regression 
> (especially on a stable release) and allows Otto Normaluser and his 
> Grandma to quickly get back on their feet by simpling doing what they 
> know and have been educated to do : upgrading their software.
>
> -- 
> Cordialement,
>
> Yann Salmon
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.