Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
- From: Owen Taylor <otaylor redhat com>
- To: Olav Vitters <olav bkor dhs org>
- Cc: bugmaster gnome org, desktop-devel-list gnome org
- Subject: Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
- Date: Fri, 05 Dec 2008 10:03:11 -0500
On Thu, 2008-12-04 at 17:00 +0100, Olav Vitters wrote:
> The GNOME Bugzilla is still using 2.20. Current stable upstream is at
> 3.2. The stable version has several benefits, but overall:
> * no crappy table locking, while still allowing full text indexing
> (table locking causes many performance problems)
> * Upstream supported XMLRPC (not perfect, but various things can be
> done, see WebService stuff at http://www.bugzilla.org/docs/3.2/en/html/api/)
> * Supported by upstream (security bugs)
> * bla bla see
> There is a proposal to upgrade the GNOME Bugzilla by:
> * having an external party do it (not me)
> * deliver the functionality in multiple stages (hard requirement)
> --> Means that not all the current functionality will be available!
My take here is that this has to be treated a bit like someone came to a
GNOME module maintainer and wanted to do a big code change.
We would never say "if you do X, we'll promise to commit it"
- X sounds like a good idea
- What help do you need from us to accomplish X?
- Here are the basic requirements to get X committed
- When you've done X, if it looks good, we'll commit it
That's a risk that you just have to take as a contributor. In the end, a
decision as to whether something is ready to go live has to be made as a
judgment of the bugmaster team looking at where the port is at.
To me as a developer, I'd say that the added features you've listed
aren't very important ... I don't use most of them, I didn't even know
many existed. I'd put more weight on a) preserving important
look-and-feel customizations b) making sure that all the field
customizations transfer smoothly and no data is lost.
(As git-bz author ... xmlrpc - woo!)
] [Thread Prev