Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
- From: "Luis Villa" <luis tieguy org>
- To: desktop-devel-list gnome org, bugmaster gnome org
- Subject: Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
- Date: Thu, 4 Dec 2008 11:31:28 -0500
On Thu, Dec 4, 2008 at 11:00 AM, Olav Vitters <olav bkor dhs org> 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!
>
> For that the proposal is that the following is not part of the initial
> upgraded bgo:
> * The points system
> * index.cgi UI mods
> * Making a new favicon
> * The infomessages on show_bug.cgi
> * Layout modifications for attachment table and the login box
> * duplicates.cgi modifications
> * Fixing the comment headers
> * Patch and keyword emblems
> * delete-keyword.pl, mass-reassign-bugs.pl, and year-end-stats.pl
> * describeuser.cgi
>
> Possibly even:
>
> * Canned responses (this would be a priority immediately after
> the upgrade)
> (the javascript stuff to say things are a dupe etc)
> * show_bug.cgi UI re-ordering & float-right box
> * simple-bug-guide.cgi
> * Grouping products in a <dl> by classification when displayed
> * Asking people if they've provided the NEEDINFO info.
> * Boogle enhancements to QuickSearch (or maybe just implement
> the most important ones first and theno implement the rest later?)
> --> this is the GNOME specific 'simple search'
>
>
> Is above acceptable?
>
>
> IMO I find the following very important:
> * attachment table
> * describeuser.cgi
> * canned responses
> * Boogle
>
> but please focus on what you use: Is the reduced functionality trade-off
> acceptable if in the end we get a newer Bugzilla and the feature back?
> Note that likely some things will work in different ways etc.
One question I'd have: are there any steps that can be/will be taken
to minimize the pain during the inevitable next upgrade? Commitment to
getting changes upstream, use of DVCS, etc.? Getting back to trunk
bugzilla is a good goal and worth sacrificing features for, but it
would be terrific if we could both stay near trunk and add new
features without going through this whole painful cycle again next
time we decide to upgrade.
Luis
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]