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