Re: [GNC-dev] GDPR and gnucash as a project

[Wm via gnucash-devel]

On 22/05/2018 18:14, Geert Janssens wrote:

Op dinsdag 22 mei 2018 16:36:47 CEST schreef David T.:

Geert,

I am not fluent with the issues of the GDPR, but I have had a lifetime of
considering intellectual property issues (as a librarian). Personal
contributions of ideas, thoughts, or intellectual content are IMHO NOT
personal data, even when signed by an individual’s name*.



Those would fall
under intellectual property/copyright rules rather than personal data.



It is my understanding also that use of GPL addresses the question of IP
rights in code and documentation; if a user contributes to the GC project
in these areas, they do so with this release understood.


I had given this some more thought as well. And I agree that our code and
documentation licenses handle this.
Because of these licenses I see a code/documentation contribution as happening
under a contract. So the GDPR doesn't apply there as far as I'm concerned.
Or put differently in my own simplified words: our code is regulated by
copyright law. In order to be able to assert copyright (even in copyleft form)
the author of the protected work must be known. So if someone contributes a
patch that person must be identified together with the patch or copyright
can't work. So "the right to be forgotten" doesn't apply due to the legal
framework in which the personal data (user's name/email) is used.


that is how most of our software works, a person gives it freely

we have had a number of people offer paid contributions but so far as I 
remember we have always refused them



It is also my
understanding that unless someone explicitly states otherwise, their
posting of information in a public place (such as a website, wiki, mailing
list, etc.) would constitute permission to release that information
generally.


Sounds reasonable to me. Though we may be required to mention this more
explicitly in various places.


Yes, we might need to tighten up the guidelines but we are a tiny 
project compared to wikipedia, let's see what they do first.




* - I would be extremely surprised to find that a user’s name, in and of
itself, would constitute protected personal information.


That does sound reasonable to me as well.


A name is not protected.

--
Wm

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

Re: [GNC-dev] GDPR and gnucash as a project

[Wm via gnucash-devel]

On 22/05/2018 18:14, Geert Janssens wrote:

Op dinsdag 22 mei 2018 16:36:47 CEST schreef David T.:

Geert,

I am not fluent with the issues of the GDPR, but I have had a lifetime of
considering intellectual property issues (as a librarian). Personal
contributions of ideas, thoughts, or intellectual content are IMHO NOT
personal data, even when signed by an individual’s name*.



Those would fall
under intellectual property/copyright rules rather than personal data.



It is my understanding also that use of GPL addresses the question of IP
rights in code and documentation; if a user contributes to the GC project
in these areas, they do so with this release understood.


I had given this some more thought as well. And I agree that our code and
documentation licenses handle this.
Because of these licenses I see a code/documentation contribution as happening
under a contract. So the GDPR doesn't apply there as far as I'm concerned.
Or put differently in my own simplified words: our code is regulated by
copyright law. In order to be able to assert copyright (even in copyleft form)
the author of the protected work must be known. So if someone contributes a
patch that person must be identified together with the patch or copyright
can't work. So "the right to be forgotten" doesn't apply due to the legal
framework in which the personal data (user's name/email) is used.


also that the work is given freely

Geert, I want you, one of our leaders to understand that this is 
something you should put  in front of us and hopefully forget.


We can't all code (I have said why) it doesn't mean we can't think or 
don't work.



It is also my
understanding that unless someone explicitly states otherwise, their
posting of information in a public place (such as a website, wiki, mailing
list, etc.) would constitute permission to release that information
generally.


Sounds reasonable to me. Though we may be required to mention this more
explicitly in various places.


That may be part of it, I have seen someone say that a young person's 
idea must be acknowledged by an older person and I'm not in favour of 
that.  Original ideas, yes, please  Good ideas, certainly.  All ideas, no.


Meanwhile, who the fuck is sitting on my messages?

Why are we so old fashioned that only a few people can acknowledge my 
existence or anyone else's?


Is it Liz or one of the old men?

I have time

But in the middle of GDPR we must ask who the FUCK ARE YOU TO STOP MY 
POST ?


And, of course, consider what the lists have been doing wrong and right 
over time.


I think my view is at odds ...

P.S.  I think from now on if you *don't* post my message you have to 
tell me why and that is going to be tricky.



--
Wm



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

Re: [GNC-dev] GDPR and gnucash as a project

[Wm via gnucash-devel]

On 22/05/2018 15:36, David T. via gnucash-devel wrote:


* - I would be extremely surprised to find that a user’s name, in and of 
itself, would constitute protected personal information.


There are some unusual circumstances where a person's name may be 
protected in UK and EU law


I doubt they will be invoked here, move on

--
Wm




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

Re: [GNC-dev] GDPR and gnucash as a project

[Wm via gnucash-devel]

On 22/05/2018 15:36, David T. via gnucash-devel wrote:

Geert,

I am not fluent with the issues of the GDPR,


relatively few people are
but they have been thought about
they are not harmful to you or I

I am not accepting the offered changes in T+C unless it is a bank or 
business I know, then I look at them and usually agree, I mean, I gave 
them my business to start with and checked at the beginning.


A BBC News report say around 5% of people are agreeing to the new terms 
for smaller companies.  This is backwards, the smaller companies are the 
ones that need the contacts.  The big ones haven't said what they are 
going to do if people don't agree.


That is why the European Court is a good thing, USA people, it cares 
about you too.



> but I have had a lifetime of considering intellectual property issues 
(as a librarian).


Librarians are some of my favourite people

Personal contributions of ideas, thoughts, or intellectual content are 
IMHO NOT personal data, even when signed by an individual’s name*. Those 
would fall under intellectual property/copyright rules rather than 
personal data. It is my understanding also that use of GPL addresses the 
question of IP rights in code and documentation; if a user contributes 
to the GC project in these areas, they do so with this release understood.


I don't think that is in doubt, it would be odd for someone to withdraw 
a positive contribution.


More realistic is (I will use myself) I said a bad thing, possibly rude 
(I do that for free) but it was not only wrong (I don't mind being 
wrong) but I also said someone else was wrong ...


... keep going ...

... and someone noticed and complained to someone that the fucking idiot 
Donald Trump doesn't believe can sign an agreement <-- yes it is 
necessary to point out that the people of the USA voted an incompetent 
as their leader and he is stopping them getting their rights.  Why would 
anyone vote for him other than a being a racist or a bedroom russian? 
<-- hello do you know there are girls out there american incel voters?


It is also my understanding that unless someone explicitly states 
otherwise, their posting of information in a public place (such as a 
website, wiki, mailing list, etc.) would constitute permission to 
release that information generally.


yes


David T.

* - I would be extremely surprised to find that a user’s name, in and of 
itself, would constitute protected personal information.


it isn't


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

Re: [GNC-dev] BZ: Comments

[Derek Atkins]

On Wed, May 23, 2018 10:42 am, Geert Janssens wrote:
> Op woensdag 23 mei 2018 16:00:57 CEST schreef John Ralls:
>>
>> I think that it’s premature to break up GnuCash. That will only confuse
>> users. +1 for separating Docs, Website, and Packaging, i.e.
>> gnucash-on-(windows|osx).
>
> Agreed and I like Packaging as name.

So just to be clear, the hierarchy would be:

Product: Documentation
  Components:
  Help
  Guide

Product: Website
  Components:
  Website
  Translations

Product: Packaging
  Components:
   Windows
   MacOS
???

Or are you suggesting separate products for each?

Note: I added Website:Translations above, although I don't think there are
any bugs there -- and even if there were I don't know how to
programatically pull them out -- which means I probably cannot
programatically create it, either.

Similarly, I'm not sure how I would separate out Help and Guide
documentation bugs, but I can probably search through the bug comments and
make an educated heuristic guess.  But we'd need to manually check.

In terms of versions and milestones -- those get built from the bugs
themselves.  So I could theoretically edit them if we knew how we wanted
to map them in the final migration.

> Geert

-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] BZ: Comments

[Derek Atkins]

On Wed, May 23, 2018 12:51 pm, Adrien Monteleone wrote:
>
> If creating a product for ‘Website’ would a ‘Wiki’, ‘Mailman’ and and dare
> I say, ’GnuCash-Bugzilla’ products section also be in order? (the last
> being not for the software, but for the GnuCash instance of it)

I don't think so.

The Web Site product is there because we have an htdocs git repo that
people can send patches against.  Similarly Documentation.  So those make
sense.

The Wiki content can be updated by anyone; I don't see the point of a
bugzilla product for it.  Similarly, Mailman and Bugzilla are standalone
instances -- we're not doing any coding there -- and I'm the only one who
can perform major surgery (although we will have a few "admin" users too).

FWIW, after over a decade I can count on one finger the number of bug
reports I've received about Mailman.  As for the wiki, generally Frank
suggests changes and I go implement them.

Enjoy!

> Regards,
> Adrien

-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] GDPR and terrorism

[Wm via gnucash-devel]

On 22/05/2018 19:42, Frank H. Ellenberger wrote:

Am 22.05.2018 um 19:21 schrieb Geert Janssens:

IRC includes IP addresses, which the GDPR explicitly mentions as personal
information, in “joined” messages, and those get logged. ISTM those
messages aren’t important as they’re not part of the conversation and we
could easily stop logging them delete them from the existing logs.


Yes, I think we should do that.


It depends: most private used IPv4 are dynamic IPs - changing at least
daily. They are useless without the dial in protocol of the provider.
That is the reason, anti terror laws try to force them to store them.
Then again courts declare the anti terror law unconstitutional.

I don't know the current practice of providers with IPv6.

Question: How will you behave, if you see, last night XXX announced an
terror attack on our channel?


I suggest IRC is a small (though sometimes very detailed) part of the 
conversation about gnc; I suggest that the people taking part in this 
conversation mainly know each other and a bad person injecting a world 
changing message through IRC should be dealt with as ordinary.


C'mon, are we really expecting someone important other than a Trump or 
Yeltsin to play in the IRC and if it is just a pony, deal with it.


--
Wm

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

Re: [GNC-dev] BZ: Comments

[Adrien Monteleone]

> On May 23, 2018, at 7:28 AM, Derek Atkins  wrote:
> 
>> However as we host bugzilla at gnucash.org, it should be
>> obvious the database is about gnucash.
>> So perhaps we can reuse the product field for a more useful
>> separation of bugs
>> How about having "Gnucash" for that program, "Documentation"
>> for all documentation related bugs and "Website" for our website related
>> bugs
>> Documentation and Website are currently components of gnucash so they
>> would be moved.
>> This split more or less follows the same separation as we have in
>> git. If we take that as a guide we may also want an "OS integration"
>> product covering issues specific to the Windows and OS X integration
>> repos (gnucash-on-windows and gnucash-on-osx)

If creating a product for ‘Website’ would a ‘Wiki’, ‘Mailman’ and and dare I 
say, ’GnuCash-Bugzilla’ products section also be in order? (the last being not 
for the software, but for the GnuCash instance of it)

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

Re: [GNC-dev] [GNC] feature request, select all on reconcille

[Geert Janssens]

Op dinsdag 22 mei 2018 16:32:00 CEST schreef Dennis Powless:
> I do not have gnucash/glade either.
> 
> I've noticed there are several files that deal with the reconcile
> window and I was directed to this one in particular.
> window-reconcile.c
> 
> I will direct my work on this file.  I've got some reading to do, in
> order to get up to speed.  Particularly with gtk
> 
The reconcile functionality is a combination of c code and a glade/gtkbuilder 
interface definition file.
The c code starts in window-reconcile.c, but it depends on custom widgets like 
reconcile-view for complete reconcile functionality.
The interface file is found in
gnucash/gtk-builder/window-reconcile.glade

The latter can be opened with glade. For the c code you'll need a good text 
editor (vim, (x)emacs, kate,...) or and ide (eclipse, kdevelop, xcode,...) 
depending on what you're most comfortable with. I am currently a happy user of 
kdevelop on linux, while I know other developers prefer working directly in 
emacs. And others use eclipse.

Geert


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

Re: [GNC-dev] BZ: Comments

[Geert Janssens]

Op woensdag 23 mei 2018 16:00:57 CEST schreef John Ralls:
> >>> I am a heavy user of the browse page. On gnomebz this had plenty of
> >>> 
> >>> statistics on a product. There are all gone. Is this because I'm not
> >>> yet known as a developer or was this a gnome customization ?
> >> 
> >> That's a good question; I don't have an answer.  I do think that the
> >> "browse" page on GnomeBZ links to a different page than in our BZ
> >> instance.
> > 
> > It does indeed. Looks like another gnome customization.
> > 
> >>> Each bug report now has a block for effort estimates and
> >>> 
> >>> accounting. Do we want to keep this ? And can it be (globally)
> >>> disabled via configuration ?
> >> 
> >> I believe it can be globally disabled, which I think I just did.  Can
> >> you confirm?
> > 
> > I can confirm it's gone now. Thanks!
> > 
> >>> Looking at attachments and attachment statuses again. Without a status
> >>> flag it is effectively more difficult to track a patch' status.
> >>> 
> >>> I just took the first example:
> >>> https://bugzilla.gnucash.org/bugzilla/show_bug.cgi?id=570011
> >>> 
> >>> I had to read through the whole bug to understand improvemements were
> >>> requested and not yet provided.
> >>> So I'm in two minds about this. I do understand it would require
> >>> bugzilla customization however without it bugzilla gets yet a bit more
> >>> cumbersome to manage patches.
> >> 
> >> There are two issues here.
> >> 
> >> 1) We would need to implement the extension.  It's likely we could
> >> possibly get the code from Gnome to do so, but then we would need to
> >> port it to BZ 5.  I don't know how much code it is, or how hard it would
> >> be to port and/or maintain.
> > 
> > There is the Splinter bugzilla extension (https://github.com/bugzilla/
> > extensions-Splinter/commits/4.0) which seems to implement this. I don't
> > have high hopes though as this was written for bugzilla 4.0 and the code
> > hasn't been touched since 2016 (at least not on github).
> 
> All of the Gnome customizations should be in
> https://git.gnome.org/browse/bugzilla-gnome-org-customizations/
> .
> Certainly the gnome_attachment_status stuff is. They’re obviously for BZ4.4
> and so might need some work to get them going for 5.0.
> 
True. I found references to their customized browse page in there as well.

> I think that it’s premature to break up GnuCash. That will only confuse
> users. +1 for separating Docs, Website, and Packaging, i.e.
> gnucash-on-(windows|osx).

Agreed and I like Packaging as name.

Geert


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

Re: [GNC-dev] BZ: Comments

[John Ralls]

> On May 23, 2018, at 6:29 AM, Geert Janssens  
> wrote:
> 
> Op woensdag 23 mei 2018 14:28:06 CEST schreef Derek Atkins:
>>> However as we host bugzilla at gnucash.org, it should be
>>> 
>>> obvious the database is about gnucash.
>>> 
>>> So perhaps we can reuse the product field for a more useful
>>> 
>>> separation of bugs
>>> 
>>> How about having "Gnucash" for that program, "Documentation"
>>> 
>>> for all documentation related bugs and "Website" for our website related
>>> bugs
>>> 
>>> Documentation and Website are currently components of gnucash so they
>>> 
>>> would be moved.
>>> 
>>> This split more or less follows the same separation as we have in
>>> 
>>> git. If we take that as a guide we may also want an "OS integration"
>>> product covering issues specific to the Windows and OS X integration
>>> repos (gnucash-on-windows and gnucash-on-osx)
>> 
>> We could do that.  I think I could even do that programatically as part
>> of the migration script (which would, of course, require dropping the
>> database to reload).  Anything that is part of the existing
>> Documentation component would move into the new Documentation product,
>> etc.
>> 
>> The biggest issue would just be coming up with the heuristics on how to
>> move stuff around.
>> 
> Indeed.
> 
>>> The "OS Integration" could have a Windows and an OS X/Quarz (or
>>> 
>>> however it's spelled these days) component
>> 
>> This might be a bit more challenging as I don't think there are current
>> cues to use to redirect those bugs.
>> 
> Yes, I think these can only be moved manually after inspection. I'm not even 
> sure if my distinction makes sense. What I do know is we currently have 
> Windows and Macos components which in theory should deal with Windows and 
> Macos specific issues. I have always found these confusing as they overlap 
> with the OS field. I hope we can come up with a better definition of what 
> belongs where.
> 
> So I'm inclined to make this distinction based on the repo in which the 
> changes should happen. This is not necessarily something the reporter can 
> know 
> beforehand. Sometimes this only gets clear after analysis. So I believe it's 
> up to bug triagers to reclassify if necessary, just as we have to do with 
> bugs 
> filed in the Generic category. 
> 
>>> Planning ahead to a potential split of the gnucash product in a real
>>> libgnucash and "libgnucash-consumers" we may want to create a
>>> libgnucash product now as well managing all the lower level components
>>> (backends, engine, ...)
>>> And GnuCash and Bindings as products for the libgnucash-consumers.
>>> This split may be too early though.
>> 
>> Would we want to move bugs there now?  If so, which ones?
>> 
> It depends on how hard it would be to do after the migration. If it's 
> relatively easy to move a category to another product we can do it later as 
> well.
> 
> However if we want to do it now we should carefully think about the new 
> classification.
> 
> A side effect of different products is independent version schemes per 
> product. For me it makes sense the website doesn't follow the gnucash-the-
> program versions. It pretty much stands on its own. Documentation on the 
> other 
> hand is more useful if it does follow the same versioning scheme.
> For the integration repos we don't really use versioning although I think it 
> would be useful if we did. A user may want to report a bug s/he ran into 
> while 
> trying to install gnucash 3.1 on Windows. It would help us to know exactly 
> which installer was used for example.
> 
>>> I am a heavy user of the browse page. On gnomebz this had plenty of
>>> 
>>> statistics on a product. There are all gone. Is this because I'm not
>>> yet known as a developer or was this a gnome customization ?
>> 
>> That's a good question; I don't have an answer.  I do think that the
>> "browse" page on GnomeBZ links to a different page than in our BZ
>> instance.
>> 
> It does indeed. Looks like another gnome customization.
> 
>>> Each bug report now has a block for effort estimates and
>>> 
>>> accounting. Do we want to keep this ? And can it be (globally)
>>> disabled via configuration ?
>> 
>> I believe it can be globally disabled, which I think I just did.  Can
>> you confirm?
>> 
> I can confirm it's gone now. Thanks!
> 
>>> Looking at attachments and attachment statuses again. Without a status
>>> flag it is effectively more difficult to track a patch' status.
>>> 
>>> I just took the first example:
>>> https://bugzilla.gnucash.org/bugzilla/show_bug.cgi?id=570011
>>> 
>>> I had to read through the whole bug to understand improvemements were
>>> requested and not yet provided.
>>> So I'm in two minds about this. I do understand it would require
>>> bugzilla customization however without it bugzilla gets yet a bit more
>>> cumbersome to manage patches.
>> 
>> There are two issues here.
>> 
>> 1) We would need to implement the extension.  It's likely we could
>> 

Re: [GNC-dev] BZ: Comments

[Geert Janssens]

Op woensdag 23 mei 2018 14:28:06 CEST schreef Derek Atkins:
> >  However as we host bugzilla at gnucash.org, it should be
> > 
> > obvious the database is about gnucash.
> > 
> >  So perhaps we can reuse the product field for a more useful
> > 
> > separation of bugs
> > 
> >  How about having "Gnucash" for that program, "Documentation"
> > 
> > for all documentation related bugs and "Website" for our website related
> > bugs
> > 
> >  Documentation and Website are currently components of gnucash so they
> > 
> > would be moved.
> > 
> >  This split more or less follows the same separation as we have in
> > 
> > git. If we take that as a guide we may also want an "OS integration"
> > product covering issues specific to the Windows and OS X integration
> > repos (gnucash-on-windows and gnucash-on-osx)
> 
> We could do that.  I think I could even do that programatically as part
> of the migration script (which would, of course, require dropping the
> database to reload).  Anything that is part of the existing
> Documentation component would move into the new Documentation product,
> etc.
> 
> The biggest issue would just be coming up with the heuristics on how to
> move stuff around.
> 
Indeed.

> >  The "OS Integration" could have a Windows and an OS X/Quarz (or
> > 
> > however it's spelled these days) component
> 
> This might be a bit more challenging as I don't think there are current
> cues to use to redirect those bugs.
> 
Yes, I think these can only be moved manually after inspection. I'm not even 
sure if my distinction makes sense. What I do know is we currently have 
Windows and Macos components which in theory should deal with Windows and 
Macos specific issues. I have always found these confusing as they overlap 
with the OS field. I hope we can come up with a better definition of what 
belongs where.

So I'm inclined to make this distinction based on the repo in which the 
changes should happen. This is not necessarily something the reporter can know 
beforehand. Sometimes this only gets clear after analysis. So I believe it's 
up to bug triagers to reclassify if necessary, just as we have to do with bugs 
filed in the Generic category. 

> > Planning ahead to a potential split of the gnucash product in a real
> > libgnucash and "libgnucash-consumers" we may want to create a
> > libgnucash product now as well managing all the lower level components
> > (backends, engine, ...)
> > And GnuCash and Bindings as products for the libgnucash-consumers.
> > This split may be too early though.
> 
> Would we want to move bugs there now?  If so, which ones?
> 
It depends on how hard it would be to do after the migration. If it's 
relatively easy to move a category to another product we can do it later as 
well.

However if we want to do it now we should carefully think about the new 
classification.

A side effect of different products is independent version schemes per 
product. For me it makes sense the website doesn't follow the gnucash-the-
program versions. It pretty much stands on its own. Documentation on the other 
hand is more useful if it does follow the same versioning scheme.
For the integration repos we don't really use versioning although I think it 
would be useful if we did. A user may want to report a bug s/he ran into while 
trying to install gnucash 3.1 on Windows. It would help us to know exactly 
which installer was used for example.

> >  I am a heavy user of the browse page. On gnomebz this had plenty of
> > 
> > statistics on a product. There are all gone. Is this because I'm not
> > yet known as a developer or was this a gnome customization ?
> 
> That's a good question; I don't have an answer.  I do think that the
> "browse" page on GnomeBZ links to a different page than in our BZ
> instance.
> 
It does indeed. Looks like another gnome customization.

> >  Each bug report now has a block for effort estimates and
> > 
> > accounting. Do we want to keep this ? And can it be (globally)
> > disabled via configuration ?
> 
> I believe it can be globally disabled, which I think I just did.  Can
> you confirm?
> 
I can confirm it's gone now. Thanks!

> >  Looking at attachments and attachment statuses again. Without a status
> > flag it is effectively more difficult to track a patch' status.
> > 
> >  I just took the first example:
> > https://bugzilla.gnucash.org/bugzilla/show_bug.cgi?id=570011
> > 
> >  I had to read through the whole bug to understand improvemements were
> > requested and not yet provided.
> >  So I'm in two minds about this. I do understand it would require
> > bugzilla customization however without it bugzilla gets yet a bit more
> > cumbersome to manage patches.
> 
> There are two issues here.
> 
> 1) We would need to implement the extension.  It's likely we could
> possibly get the code from Gnome to do so, but then we would need to
> port it to BZ 5.  I don't know how much code it is, or how hard it would
> be to port and/or maintain.
> 
There is the Splinter 

Re: [GNC-dev] BZ: Comments

[Derek Atkins]

Geert sent a bunch of comments about BZ to IRC.  I am forwarding them
here and responding for posterity (and a wider audience).

>  jralls, warlord: I finally have some time now to look at the
> bugzilla migration. I'll add my thoughts here as I go along
>  First thing: when clicking on the "Browse" button two
> products are presented: "GnuCash" and "TestProduct".
>  Obviously the TestProduct is just that and will probably
> disappear when we go live.

Correct, that product is automatically created, and I do not
automatically delete it.  I could certainly update the migration script
to do that (or it can be done manually).

>  However as we host bugzilla at gnucash.org, it should be
> obvious the database is about gnucash.
>  So perhaps we can reuse the product field for a more useful
> separation of bugs
>  How about having "Gnucash" for that program, "Documentation"
> for all documentation related bugs and "Website" for our website related
> bugs
>  Documentation and Website are currently components of gnucash so they
> would be moved.
>  This split more or less follows the same separation as we have in
> git. If we take that as a guide we may also want an "OS integration"
> product covering issues specific to the Windows and OS X integration
> repos (gnucash-on-windows and gnucash-on-osx)

We could do that.  I think I could even do that programatically as part
of the migration script (which would, of course, require dropping the
database to reload).  Anything that is part of the existing
Documentation component would move into the new Documentation product,
etc.

The biggest issue would just be coming up with the heuristics on how to
move stuff around.

>  The "OS Integration" could have a Windows and an OS X/Quarz (or
> however it's spelled these days) component

This might be a bit more challenging as I don't think there are current
cues to use to redirect those bugs.

> Planning ahead to a potential split of the gnucash product in a real
> libgnucash and "libgnucash-consumers" we may want to create a
> libgnucash product now as well managing all the lower level components
> (backends, engine, ...)
> And GnuCash and Bindings as products for the libgnucash-consumers.
> This split may be too early though.

Would we want to move bugs there now?  If so, which ones?

>  Gnome bugzilla has a summary report -
> https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html
>  This is missing in gnucash bugzilla. Was this a gnome customization ?

Yes.  I do not see a "weekly-bug-summary" anywhere in the installation.

>  I am a heavy user of the browse page. On gnomebz this had plenty of
> statistics on a product. There are all gone. Is this because I'm not
> yet known as a developer or was this a gnome customization ?

That's a good question; I don't have an answer.  I do think that the
"browse" page on GnomeBZ links to a different page than in our BZ
instance.

>  Each bug report now has a block for effort estimates and
> accounting. Do we want to keep this ? And can it be (globally)
> disabled via configuration ?

I believe it can be globally disabled, which I think I just did.  Can
you confirm?

>  Looking at attachments and attachment statuses again. Without a status
> flag it is effectively more difficult to track a patch' status.
>  I just took the first example:
> https://bugzilla.gnucash.org/bugzilla/show_bug.cgi?id=570011 
>  I had to read through the whole bug to understand improvemements were
> requested and not yet provided. 
>  So I'm in two minds about this. I do understand it would require
> bugzilla customization however without it bugzilla gets yet a bit more
> cumbersome to manage patches. 

There are two issues here.

1) We would need to implement the extension.  It's likely we could
possibly get the code from Gnome to do so, but then we would need to
port it to BZ 5.  I don't know how much code it is, or how hard it would
be to port and/or maintain.

2) We would need to manually obtain all the data from GnomeBZ.  The JSON
API does not include those fields when I fetch it, so we'll have to
manually go through and pull it down.

Granted, I'm overstating #2 a little -- the JSON API *DOES* include the
changes to this flag in the history, so I could theoretically search the
history for the status changes and set it to the "last" change made.

>  We could also change our patch policy and only accept PR's over github
> (who would have thought when we started with git several years ago I'd
> one day consider proposing that...) 
>  The subtle pinch there is that it would mean we start to depend solely
> on a proprietary service to accept code contributions from a
> non-commiter 
> Which is not ideal for a project promoting free software :(

Agreed.  I'm not sure what is the right approach.  But we do need to
make a decision in the next few weeks.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: 

Re: [GNC-dev] GDPR and terrorism

[Geert Janssens]

Op dinsdag 22 mei 2018 20:51:30 CEST schreef John Ralls:
> > On May 22, 2018, at 11:42 AM, Frank H. Ellenberger
> >  wrote:> 
> > Am 22.05.2018 um 19:21 schrieb Geert Janssens:
> >>> IRC includes IP addresses, which the GDPR explicitly mentions as
> >>> personal
> >>> information, in “joined” messages, and those get logged. ISTM those
> >>> messages aren’t important as they’re not part of the conversation and we
> >>> could easily stop logging them delete them from the existing logs.
> >> 
> >> Yes, I think we should do that.
> > 
> > It depends: most private used IPv4 are dynamic IPs - changing at least
> > daily. They are useless without the dial in protocol of the provider.
> > That is the reason, anti terror laws try to force them to store them.
> > Then again courts declare the anti terror law unconstitutional.
> > 
> > I don't know the current practice of providers with IPv6.
> > 
> > Question: How will you behave, if you see, last night XXX announced an
> > terror attack on our channel?
> 
> Even with dynamically-allocated IP addresses the ISP can identify which
> customer has an address -IPv4 and IPv6-given the address and the timestamp.
> IP addresses are specifically mentioned in article 30.
> 
> I would notify local law enforcement who will pass it up the chain to the
> appropriate level. Article 19 excludes criminal activity from being
> protected under the GDPR.
> 
> Regards,
> John Ralls

And to make the link with whether or not we should keep the IP addresses in 
our logs for that reason, I don't think so.

We don't host the irc service. It's hosted by universities coming together 
under the GIMPnet. In case of criminal activity I would expect law enforcement 
to request the logs directly from the owners of the servers running the 
service. If Derek were to host his own irc server then yes he should probably 
keep irc logs (off line) for the legally required time or at least the 
necessary meta data.

The ip data is not relevant for the gnucash project in any way so we should 
remove it. We're not making law enforcement more difficult by doing so but we 
would be in a better position with regards to the GDPR.

Geert


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