[GNC-dev] BZ: Comments

[John Ralls]

> On May 23, 2018, at 6:29 AM, Geert Janssens <geert.gnucash at kobaltwit.be> 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
>> 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/ <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.

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

Regards,
John Ralls