maemo.org Bugzilla – Full Text Bug Listing
|Summary:||List Maemo Bugzilla code changes, upstream backports & customizations|
|Product:||[Websites] maemo.org Website||Reporter:||Andre Klapper <andre_klapper>|
|Status:||NEW||QA Contact:||Ferenc Szekely <bugzilla>|
|Priority:||Low||CC:||andre_klapper, davidk, ferenc, karstenb|
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 REASON: 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 spend). 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 http://wiki.maemo.org/User:Andre/bug3846
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 exist) 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." - http://www.bugzilla.org/status/2009-02-02.html
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: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/?root=bugs&view=log