Re: [GNC-dev] Bugzilla Migration Status -- phase 2 -- please test

[Adrien Monteleone]

I suppose you’re still revising things.

Currently, I see components listed, but no bugs found.

I also tried a password reset but never received the email.

Is this only for official developers to test right now, or anyone who has a 
Gnome Bugzilla account and participated in bug reports?

Regards,
Adrien

> On May 14, 2018, at 4:00 PM, Derek Atkins  wrote:
> 
> Hi Everyone,
> 
> tl;dr: I have a partial migration up and running (~105 / 8588 bugs) and I
> think my migration script is "complete" -- please test.  Also, please let
> me know if you know of any bugs that use the see_also field.
> 
> Long Version:
> 
> As you all know, we use Gnome's bugzilla instance, and they are
> transitioning to gitlab (soon, like by June).  Since we only used Gnome
> infrastructure for BZ and nothing else, we decied to migrate to our own BZ
> instance.  Part of this migration is moving the bug data from Gnome's BZ
> to our own.  To that end I've been working on a script using
> Bugzilla::Migrate and the JSON RPC to pull the data from GnomeBZ and then
> migrate it into our instance.
> 
> At this point in time I *BELIEVE* I am migrating all the data we can get. 
> I think we're ready for the next stage of testing, which is making sure
> the data has been migrated correctly, nothing is missing (from the
> migrated data), and that the BZ instance is, effectively "configured".
> 
> To that end, please check the bugs that I've imported.  They are early in
> the sequence (numerically), but three out-of-sequence bugs I pulled in for
> dependencies and one for attachment testing from early on.   Let me know
> if you need some specific bug #s to search for.
> 
> One thing my data does NOT have is a bug with anytihng in the see_also
> data.  Does anyone know of any bugs that use that field?
> 
> A quite note on user accounts:  Users are created with crandom passwords. 
> If you made any comments/changes/etc to a bug then you have an account,
> and should be able to ask for a password reset.  I would ask that right
> now we make this a read-only test.  We can do write tests soon.
> 
> Also note that I will be blowing away the database regularly as we
> continue testing, so if you do reset your password, it will likely be
> resert again out from under you in the not too distant future.
> 
> Thanks for testing.  If you find any issues please let me know.  Also let
> me know if you have any questions.
> 
> Thanks!
> 
> -derek
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Migration Status -- phase 2 -- please test

[John Ralls]

> On May 14, 2018, at 2:00 PM, Derek Atkins  wrote:
> 
> Hi Everyone,
> 
> tl;dr: I have a partial migration up and running (~105 / 8588 bugs) and I
> think my migration script is "complete" -- please test.  Also, please let
> me know if you know of any bugs that use the see_also field.
> 
> Long Version:
> 
> As you all know, we use Gnome's bugzilla instance, and they are
> transitioning to gitlab (soon, like by June).  Since we only used Gnome
> infrastructure for BZ and nothing else, we decied to migrate to our own BZ
> instance.  Part of this migration is moving the bug data from Gnome's BZ
> to our own.  To that end I've been working on a script using
> Bugzilla::Migrate and the JSON RPC to pull the data from GnomeBZ and then
> migrate it into our instance.
> 
> At this point in time I *BELIEVE* I am migrating all the data we can get. 
> I think we're ready for the next stage of testing, which is making sure
> the data has been migrated correctly, nothing is missing (from the
> migrated data), and that the BZ instance is, effectively "configured".
> 
> To that end, please check the bugs that I've imported.  They are early in
> the sequence (numerically), but three out-of-sequence bugs I pulled in for
> dependencies and one for attachment testing from early on.   Let me know
> if you need some specific bug #s to search for.
> 
> One thing my data does NOT have is a bug with anytihng in the see_also
> data.  Does anyone know of any bugs that use that field?
> 
> A quite note on user accounts:  Users are created with crandom passwords. 
> If you made any comments/changes/etc to a bug then you have an account,
> and should be able to ask for a password reset.  I would ask that right
> now we make this a read-only test.  We can do write tests soon.
> 
> Also note that I will be blowing away the database regularly as we
> continue testing, so if you do reset your password, it will likely be
> resert again out from under you in the not too distant future.
> 
> Thanks for testing.  If you find any issues please let me know.  Also let
> me know if you have any questions.


Derek,

There are 67 GnuCash bugs in Gnome with something in the See Also field:

https://bugzilla.gnome.org/buglist.cgi?f1=see_also_id=310012=regexp=Bug%20Number=GnuCash_format=advanced=.%2B
 


The earliest one is https://bugzilla.gnome.org/show_bug.cgi?id=402289 
, much later than the ones 
you’ve imported.

https://bugzilla.gnucash.org/bugzilla/buglist.cgi?j_top=OR=Bug%20Number_format=advanced
 

 returns only 103 bugs. Are you sure you imported 105?

If possible it would be nice to convert all of the assignees and QA contacts to 
the pseudo-users (e.g. gnucash-core-ma...@gnucash.bugs 
) instead of the many developers who’re 
no longer working on GnuCash.

Attachments aren’t displayed in the browser even when they’re plain text, see 
https://bugzilla.gnucash.org/bugzilla/attachment.cgi?id=4=edit 
, "The 
attachment is not viewable in your browser due to security restrictions enabled 
by your Bugzilla administrator.”

I’ll poke at it some more tomorrow.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Bugzilla Migration Status -- phase 2 -- please test

[Derek Atkins]

Hi Everyone,

tl;dr: I have a partial migration up and running (~105 / 8588 bugs) and I
think my migration script is "complete" -- please test.  Also, please let
me know if you know of any bugs that use the see_also field.

Long Version:

As you all know, we use Gnome's bugzilla instance, and they are
transitioning to gitlab (soon, like by June).  Since we only used Gnome
infrastructure for BZ and nothing else, we decied to migrate to our own BZ
instance.  Part of this migration is moving the bug data from Gnome's BZ
to our own.  To that end I've been working on a script using
Bugzilla::Migrate and the JSON RPC to pull the data from GnomeBZ and then
migrate it into our instance.

At this point in time I *BELIEVE* I am migrating all the data we can get. 
I think we're ready for the next stage of testing, which is making sure
the data has been migrated correctly, nothing is missing (from the
migrated data), and that the BZ instance is, effectively "configured".

To that end, please check the bugs that I've imported.  They are early in
the sequence (numerically), but three out-of-sequence bugs I pulled in for
dependencies and one for attachment testing from early on.   Let me know
if you need some specific bug #s to search for.

One thing my data does NOT have is a bug with anytihng in the see_also
data.  Does anyone know of any bugs that use that field?

A quite note on user accounts:  Users are created with crandom passwords. 
If you made any comments/changes/etc to a bug then you have an account,
and should be able to ask for a password reset.  I would ask that right
now we make this a read-only test.  We can do write tests soon.

Also note that I will be blowing away the database regularly as we
continue testing, so if you do reset your password, it will likely be
resert again out from under you in the not too distant future.

Thanks for testing.  If you find any issues please let me know.  Also let
me know if you have any questions.

Thanks!

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Derek Atkins]

On Mon, May 14, 2018 2:16 pm, John Ralls wrote:
>
[snip]
> A spot check shows they seem  mostly to be added at bug creation time by
> bug reporters, few of whom are likely to be able to make an informed
> choice. But as you say it's more important to get BZ up and running, and
> we may yet decide to switch to a different tracker which would make it
> moot. We can worry about this later.

For now I have cloned all the gnome keywords and kepts them in the migration.

Thanks.

> Regards,
> John Ralls

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[John Ralls]

> On May 14, 2018, at 10:11 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 14.05.2018 um 18:10 schrieb Derek Atkins:
>> Hi,
>> 
>> On Mon, May 14, 2018 11:41 am, John Ralls wrote:
>>> 
>>> 
>>> The existing keywords don’t seem terribly useful to me and they’re in any
>>> case not used consistently enough: only 364 out of 8590 GnuCash bugs have
>>> a keyword on them. I don’t think that there’s any need to import them
>>> unless BZ requires it.
> 
> Some are only useful, for a QA with a team like that of gnome. Others
> were much more useful, if we would apply them more consistently.
> Example: "Documentation" should be set already, if something has to be
> fixed in engine first, but also needs documentation. Then after engine
> is fixed, it should not be closed as fixed. Instead it should be
> reassigned to documentation.
> 
> So which we should drop, we should decide in a later step.

The keywords in use on GnuCash bugs are:
accessibility (9)
API (6)
BLOCKED_BY_FREEZE (1)
build (3)
documentation (36)
I18N (19)
HELPWANTED (6)
HIG (2)
keynav (5)
L10N (10)
memory (2)
newcomers (6)
perf (4)
portability (1)
pref (10)
printing (1)
qa (1)
relate (1)
security (3)
STACKTRACE (13)
string (4)
usability (239)

A spot check shows they seem  mostly to be added at bug creation time by bug 
reporters, few of whom are likely to be able to make an informed choice. But as 
you say it's more important to get BZ up and running, and we may yet decide to 
switch to a different tracker which would make it moot. We can worry about this 
later.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Derek Atkins]

On Mon, May 14, 2018 1:22 pm, Derek Atkins wrote:
>
>>> Starting to create Bug 84690
>>> Can't use string ("Bugzilla::Bug") as a HASH ref while "strict refs" in
>>> use at Bugzilla/Bug.pm line 3322.
>>>
>>> I will continue to explore this issue.
>>
>> The default policy was: close the younger report, but there are
[snip]
> I am already doing that.  I don't think that's the issue.  I'm running one
> more test to see if the issue was a dangling reference.  Specifically, I
> think I was trying to import a bug that was marked the duplicate of
> another bug that was outside the range that I was importing.  So I'm
> re-testing that.
>
> I'll let you all know what happens once that completes.

Alas, the issue is multiple-fold.  This error was happening in a
verification routine, but it's assuming that you're verifying from an
actual instance and not as a class (issue #1).  However even if I turn off
the verification, I find that dup_id is not a valid parameter during
create.  So I'm going to have to figure out a way to insert the duplicates
later.

I've put a bunchmore data into the database now for verification.  I'll
look into DUP handling later.

> -derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Derek Atkins]

On Mon, May 14, 2018 1:11 pm, Frank H. Ellenberger wrote:
>> The problem I'm seeing when I leave the
>> dup_iud field is that I get an error from the migration script:
>>
>> Starting to create Bug 84690
>> Can't use string ("Bugzilla::Bug") as a HASH ref while "strict refs" in
>> use at Bugzilla/Bug.pm line 3322.
>>
>> I will continue to explore this issue.
>
> The default policy was: close the younger report, but there are
> exceptions i.e. the younger report had much more useful information, in
> particular attachments.
>
> To reduce conflicts process the bug list sorted by id;
> ProcessBug (ID):
>   If  the bug is not already imported {
> if it is duplicate ProcessBug (duplicate_of);
> continue
> }

I am already doing that.  I don't think that's the issue.  I'm running one
more test to see if the issue was a dangling reference.  Specifically, I
think I was trying to import a bug that was marked the duplicate of
another bug that was outside the range that I was importing.  So I'm
re-testing that.

I'll let you all know what happens once that completes.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Frank H. Ellenberger]

Am 14.05.2018 um 18:10 schrieb Derek Atkins:
> Hi,
> 
> On Mon, May 14, 2018 11:41 am, John Ralls wrote:
>>
>>
>> The existing keywords don’t seem terribly useful to me and they’re in any
>> case not used consistently enough: only 364 out of 8590 GnuCash bugs have
>> a keyword on them. I don’t think that there’s any need to import them
>> unless BZ requires it.

Some are only useful, for a QA with a team like that of gnome. Others
were much more useful, if we would apply them more consistently.
Example: "Documentation" should be set already, if something has to be
fixed in engine first, but also needs documentation. Then after engine
is fixed, it should not be closed as fixed. Instead it should be
reassigned to documentation.

So which we should drop, we should decide in a later step.

>> If you do have to create them, do so and then back up the keyworddefs
>> table using MySQL; you can then easily restore the table when you recreate
>> the db.
> 
> It was easy enough to extract the fieds from gnome-bz into json, so I have
> the list of defined keywords.  And it was easy enough to write some code
> to add them to the database programatically during the migration before I
> insert any data.  So that's what I did.
> 
> So for now I am going to duplicate all the gnome keywords and allow the
> bugs to retain them.  Then we can go through and remove any that are
> superfluous.
> 
> I'm going to run the next try import and see how it behaves.  I have (for
> now) removed the dup_id fields from the import data, which I think means
> we wont properly get duplicates marked in the database.  We'll see how
> this goes and how it all looks.  The problem I'm seeing when I leave the
> dup_iud field is that I get an error from the migration script:
> 
> Starting to create Bug 84690
> Can't use string ("Bugzilla::Bug") as a HASH ref while "strict refs" in
> use at Bugzilla/Bug.pm line 3322.
> 
> I will continue to explore this issue.

The default policy was: close the younger report, but there are
exceptions i.e. the younger report had much more useful information, in
particular attachments.

To reduce conflicts process the bug list sorted by id;
ProcessBug (ID):
  If  the bug is not already imported {
if it is duplicate ProcessBug (duplicate_of);
continue
}

>> Regards,
>> John Ralls
> 
> -derek
> 

~Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Derek Atkins]

Hi,

On Mon, May 14, 2018 11:41 am, John Ralls wrote:
>
>
> The existing keywords don’t seem terribly useful to me and they’re in any
> case not used consistently enough: only 364 out of 8590 GnuCash bugs have
> a keyword on them. I don’t think that there’s any need to import them
> unless BZ requires it.
>
> If you do have to create them, do so and then back up the keyworddefs
> table using MySQL; you can then easily restore the table when you recreate
> the db.

It was easy enough to extract the fieds from gnome-bz into json, so I have
the list of defined keywords.  And it was easy enough to write some code
to add them to the database programatically during the migration before I
insert any data.  So that's what I did.

So for now I am going to duplicate all the gnome keywords and allow the
bugs to retain them.  Then we can go through and remove any that are
superfluous.

I'm going to run the next try import and see how it behaves.  I have (for
now) removed the dup_id fields from the import data, which I think means
we wont properly get duplicates marked in the database.  We'll see how
this goes and how it all looks.  The problem I'm seeing when I leave the
dup_iud field is that I get an error from the migration script:

Starting to create Bug 84690
Can't use string ("Bugzilla::Bug") as a HASH ref while "strict refs" in
use at Bugzilla/Bug.pm line 3322.

I will continue to explore this issue.

> Regards,
> John Ralls

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[John Ralls]

> On May 14, 2018, at 6:47 AM, Derek Atkins  wrote:
> 
> Hi All,
> 
> I hit another snag in working on the BZ migration --  we need to
> "predefine" any keywords we wish to use.  I can try to determine which
> ones we DO use (so far I've seen "documentation"), but I figured I would
> put this out there first to decide how we want to handle them.
> 
> First, keywords need to be predefined in the BZ instance.  So unlike
> product categories, which get built based on the bugs being imported, I
> have to know a priori all the keywords that our bugs will use.
> 
> Second, to create a keyword I need the keyword itself and a description.
> 
> The good news is that you can get a list of keywords (and their
> descriptions) from gnome bugzilla without be logged in: 
> https://bugzilla.gnome.org/describekeywords.cgi
> 
> The bad news is that I think I need to install them (manually) every time
> I blow away the database.  I can probably script this, somewhat.
> 
> So my question to the devs:  which keywords do we want to keep?  Should I
> just copy them all (for now) and prune after I import?  Should I figure
> out which ones we need?  Should I ignore keywords completely?
> 
> How do you all feel?

The existing keywords don’t seem terribly useful to me and they’re in any case 
not used consistently enough: only 364 out of 8590 GnuCash bugs have a keyword 
on them. I don’t think that there’s any need to import them unless BZ requires 
it.

If you do have to create them, do so and then back up the keyworddefs table 
using MySQL; you can then easily restore the table when you recreate the db.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Christopher Lam]

Here you go, a prices-report.scm which can be dropped into standard-reports
folder and adds a rudimentary forex analysis. If rebuilding you'll need to
add onto CMakeLists.txt as well.

It scans *only* transactions which involve 2 different commodities. eg
GBP<->EUR or AAPL<->USD.

It calculates and displays the exact price ratio achieved in the particular
transaction, and also finds the nearest pricedb entry applicable for that
date between the two commodities.

It does not modify the datafile, nor pricedb. It ignores any brokerage fees.

For illustration/entertainment only.
(define-module (gnucash report standard-reports prices-report))

(use-modules (gnucash utilities))
(use-modules (srfi srfi-1))
(use-modules (srfi srfi-11))
(use-modules (srfi srfi-13))
(use-modules (gnucash gnc-module))
(use-modules (gnucash gettext))

(gnc:module-load "gnucash/report/report-system" 0)

(define reportname (N_ "Prices Report"))

(define (options-generator)
  (let ((options (gnc:new-options)))
options))

(define (gnc-account-child-accounts-recursive account)
  (let loop ((account account)
 (initial '()))
(fold (lambda (child-account accumulator)
(append (loop child-account (list child-account))
accumulator))
  initial
  (gnc-account-get-children account

(define (split->splits split)
  (xaccTransGetSplitList
   (xaccSplitGetParent split)))

(define (split->commodities split)
  (delete-duplicates
   (map split->commodity (split->splits split))
   gnc-commodity-equal))

(define (split->commodity split)
  (xaccAccountGetCommodity (xaccSplitGetAccount split)))

(define (split-get-exact-ratio split)
  (let* ((splits (split->splits split))
 (split-1 (car splits))
 (split-2 (cadr splits)))
(/ (xaccSplitGetAmount split-1)
   (xaccSplitGetAmount split-2

(define (split-describe split op)
  (let* ((sp (op (split->splits split
(gnc:make-gnc-monetary (split->commodity sp) (xaccSplitGetAmount sp
  
(define (prices-renderer report-obj)
  ;; (define options (gnc:report-options report-obj))
  (gnc:report-starting reportname)
  (let* ((document (gnc:make-html-document))
 (accounts (gnc-account-child-accounts-recursive
(gnc-get-current-root-account)))
 (query (qof-query-create-for-splits)))
(qof-query-set-book query (gnc-get-current-book))
(xaccQueryAddAccountMatch query accounts QOF-GUID-MATCH-ANY QOF-QUERY-AND)
(xaccQueryAddDateMatchTT query #f 0 #f 0 QOF-QUERY-AND)
(gnc:query-set-match-non-voids-only! query (gnc-get-current-book))
(qof-query-set-sort-order query (list SPLIT-TRANS TRANS-DATE-POSTED) '() '())
(qof-query-set-sort-increasing query #t #t #t)

(let ((splits (xaccQueryGetSplitsUniqueTrans query)))
  (qof-query-destroy query)

  (if (null? splits)

  (gnc:html-document-add-object!
   document
   (gnc:html-make-generic-warning
reportname (gnc:report-id report-obj)
"Empty Book" "Cannot find any transactions"))

  (let ((rep (gnc:make-html-table))
(splits-with-prices (filter
 (lambda (split)
   (= 2 (length
 (split->commodities split
 splits)))

(gnc:html-document-set-title! document reportname)

(for-each
 (lambda (split)
   (gnc:html-table-append-row!
rep
(list

 (qof-print-date (xaccTransGetDate (xaccSplitGetParent split)))

 (gnc:html-transaction-anchor (xaccSplitGetParent split) "Transferring")

 (split-describe split car)
 "and"
 (split-describe split cadr)

 "exact price is"
 (split-get-exact-ratio split)

 (string-join (map gnc-commodity-get-mnemonic (split->commodities split)) "/")

 "and nearest pricedb is"
 (let ((price (gnc-pricedb-lookup-nearest-in-time64 (gnc-pricedb-get-db (gnc-get-current-book))
(cadr (split->commodities split))
(car (split->commodities split))
(xaccTransGetDate (xaccSplitGetParent split

   (val (gnc:exchange-by-pricedb-nearest (gnc:make-gnc-monetary (cadr (split->commodities split)) 1)
   (car (split->commodities split))
   (xaccTransGetDate (xaccSplitGetParent split)
   (if (null? price)
   "missing"
   (gnc:html-price-anchor price 

[GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Derek Atkins]

Hi All,

I hit another snag in working on the BZ migration --  we need to
"predefine" any keywords we wish to use.  I can try to determine which
ones we DO use (so far I've seen "documentation"), but I figured I would
put this out there first to decide how we want to handle them.

First, keywords need to be predefined in the BZ instance.  So unlike
product categories, which get built based on the bugs being imported, I
have to know a priori all the keywords that our bugs will use.

Second, to create a keyword I need the keyword itself and a description.

The good news is that you can get a list of keywords (and their
descriptions) from gnome bugzilla without be logged in: 
https://bugzilla.gnome.org/describekeywords.cgi

The bad news is that I think I need to install them (manually) every time
I blow away the database.  I can probably script this, somewhat.

So my question to the devs:  which keywords do we want to keep?  Should I
just copy them all (for now) and prune after I import?  Should I figure
out which ones we need?  Should I ignore keywords completely?

How do you all feel?

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Alen Siljak]

He he, just to make things a bit more complicated and realistic:

> Sent: Sunday, May 13, 2018 at 6:42 PM
> From: "John Ralls" 
> To: "Adrien Monteleone" 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] pricedb policy
>
> Just get local currency at a bank 

If you're on a weekend trip this won't work most of the time. Especially on 
Sunday in a Catholic country.

>or from a bank’s (preferably indoor) ATM

This means that, once you see something you'd like to buy, you first need to 
find an ATM that won't charge exorbitant prices for currency exchange and cash 
withdrawal. Also, you should use a card provider that doesn't do that.
Even though I had a nice travel card a few times, cash still seems to be the 
king. And exchanged outside the destination country and outside the tourist 
season, if possible. :)

> Make a “cash in wallet” account in the local currency. That will get you 
> better rates and only a few exchange transactions.

I wish all the remaining countries in Europe would start using Euro. That would 
make things so much easier. :D
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel