[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 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).

Geert