Re: [OT] Bugzilla/Splinter [was: Re: Board of Directors Elections 2014 - Candidacy - Tobias Mueller]
- From: Andrea Veri <av gnome org>
- To: Andre Klapper <ak-47 gmx net>
- Cc: Foundation List <foundation-list gnome org>
- Subject: Re: [OT] Bugzilla/Splinter [was: Re: Board of Directors Elections 2014 - Candidacy - Tobias Mueller]
- Date: Sun, 1 Jun 2014 17:28:22 +0200
Let me rephrase a bit:
the current Splinter (originally wrote by Owen Taylor) we are running is release '1' (at least that's what
info.pl tells me by looking at extensions/splinter), this extension has proven to be very stable and reliable during all these years and still today there are very rare reports about it not working properly when trying to load a certain patch for review and hanging there forever.
Unfortunately I have no reports of istances running the very latest BZ release and Splinter and according to [1] it seems some minor changes had to be added between the 4.0 and the 4.2 migration. (the code then was never updated, might it be the maintainer found it being working just fine on the 4.4 series? so yeah, mine was mainly a guess on the current status of the splinter extension)
As I reported in multiple occasions (and as the diff between stock 3.4 and b.g.o shows) the greatest changes were introduced on the attachment statuses management which are custom to our istance. I would like to publicly say how much disappointed I am about the previous BZ migration (that took place back in 2009) and how it was handled. Just a few words can be used to describe it all: a lot of custom changes introduced (both hardcoded into the original code like the attachment status patches themselves and as extensions), no documentation of any form for future upgrades, no one looking at and maintaining the b.g.o-related-customizations properly. We ended up with a indomitable beast no one is able or willing to tame.
As a side note we do have a 4.4 istance set up at [2] already running an old copy of the b.g.o database, what we are actually missing is:
1. Making a list of what we really want to port or not
2. Remove the customizations we don't want
3. Port the extensions / customizations we really want (and really need) to see deployed
4. Put all together and migrate the latest database
On this matter Kat was so great to find someone willing to help us out, I'm currently in touch with him and will send a status update as soon as possible.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
