Re: [Kolab-devel] Upgrade report 3.1 to 3.2 on Debian Wheezy

>>  tbh (and this is just my opinion).
>>
>>  The upgrade procedures feels a bit rough and more like "testing in 
>>the
>>  wild". Kolab Team is announcing a new 3.2 version (and people trust 
>>you
>>  and think it's stable). When you look closer it feels really unstable
>>  and untested. It began with 100% cpu look of kolabd, the missing 
>>upgrade
>>  commands on debian packages (which i fixed in obs)
>
>Is there a Web-viewable summary of these fixes?
It's a combination of resources.
* bugzilla reports (maybe with patches)
* stuff that actually gets applied to git.kolab.org
* reports of users on the mailling list and on irc
* check which packages got applied already to the obs package definition

I think there are still a couple bugs that have already been fixed on 
git but havn't made their way into the package (for example the empty 
amavisd.conf bug for rpm systems).

I can just describe what I did to get hotfixes applied to the official 
packages. Maybe this will help others to understand how things are 
rolling and maybe someone is willing to participate as well.

--

Example 1)
Debian packages didn't called the script to update the roundcube 
database:

I looked into OBS and compared the RPM script with the DEBIAN script. 
Once I realized that the commands were missing in the debian postinst 
script, I forked the package on OBS, updated the script and a few other 
files (versionnr, changelog, etc) (Timotheos has a good guide on 
planet.kolab.org about it) and submitted to changes with the request to 
get it merged back into kolab:development and kolab:3.2.

Example 2)
The outdated mysql initial file

I was testing a clean installation while I figured out that the mysql 
initial file was outdated compared to the upgrade files. I opened a bug 
report on bugzilla with the request to get the the intial file updated 
on git.
Once the file was fixed on git, I forked the package on OBS and added 
the .patch files (taken from git), updated changelog and submitted the 
package back to the kolab team.

This is basically the way how hotfixes are making their way into the 
official kolab packages once they get accepted. Of course once the kolab 
team decides to ship a new upstream version of the package they'll have 
to remove the patches which should be included in the new version 
(hopefully).

--

I know that this might not be the way how you like to maintain and 
create debian packages (since you wrote a guide on creating deb packages 
with pbuilder, but it's the way the kolab team decided to go with and 
how they can provide packages for multiple architecture at once from a 
single repository. When you apply a hotfix into OBS, the fix will can 
get applied to the RPM and DEB version at the same time.


--
regards
Daniel