> On May 23, 2018, at 6:29 AM, Geert Janssens <geert.gnuc...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel