Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

[Owen Taylor <otaylor redhat com>]

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
>    http://www.bugzilla.org/releases/3.2/new-features.html
>    http://www.bugzilla.org/releases/3.0/new-features.html
>    http://www.bugzilla.org/releases/2.22/new-features.html
> 
> 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"

We'd say:

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

- Owen

(As git-bz author ... xmlrpc - woo!)