[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: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available