maemo.org Bugzilla – Bug 3846
List Maemo Bugzilla code changes, upstream backports & customizations
Last modified: 2014-03-08 11:18:11 UTC
You need to
before you can comment on or make changes to this bug.
Analyze the SVN backlog of bugs.maemo.org to list the changes we have made to
the Vanilla installation of Bugzilla 2.22.1-debian2.
So far there have been about 40 commits IIRC.
This means creating a wikipage under the Bugsquad umbrella that lists:
* Current 2.22 Customizations written "ourselves"
* Fixes/Code changes "only" backported from upstream Bugzilla 2.*/3.*
* Any potential Questions/Notes to solve
In the long run, we will probably update our 2.22 installation to a more recent
one (the non-existing 3.4 or 4.0, at least there are a few features planned
that sound attractive to me).
We will not have to care about changes that were just backported.
We will have to care about any customizations and port them if required.
Having a wikipage listing and documenting this (and kept up-to-date when
committing new code changes to Maemo Bugzilla) will make a potential later
porting much easier to handle (also with regard to estimating work and time to
The earlier, the less work later on.
Assigning to myself as I started working on it. More a long-term issue though.
Not to myself: Very rough first list of commits stored at
Note to myself: RedHat got a public test installation of new Bugzilla 3.2 with
email disabled at https://partner-bugzilla.redhat.com/ .
Something similar might be an option too later on.
According to Marcell and Ferenc changes have not been documented.
=> Diffing with the upstream package is the way to go.
That will make cost/time evaluation... a bit harder.
So the plan is:
1) Sort out / analyze custom patches in maemo.org Bugzilla [in progress]
2) Define porting required, and acceptable regressions we will ignore
3) Talk to people that committed changes that I simply don't get (they do
4) Install plain upstream Bugzilla Debian package on Testzilla
5) Get people to port the changes from 3) and document them
6) All other changes: Patch it, break it, but document it this time :-P
7) Ask for some public beta testing by the community
8) Fix potential issues found in 7)
9) Go live
Going to 3.4 directly would be awesome because it will include a few helpful
features compared to 3.2 wrt getting Nokia more involved here.
"Estimated release date for Bugzilla 3.4 is May 15, 2009, although that's a
very rough estimate and may change." -
Bugzilla 3.4 is now installed on test.maemo.org. Figured out that making a diff
for the SQL schema changes does not make sense. Bugzilla has a tool which will
do the necessary DB updates, so we don't have to alter old, or create new
tables by hand.
Next is to analyze the custom Nokia patches.
For information, the Subversion repository in the ‘bugs’ Garage component has
the latest changes from upstream Bugzilla 3.4.8: