[Pkg-corba-devel] omniorb4 4.1.0 upgrade

[Thomas Girard]

Hello Floris,

Great job! Thanks a lot for working on this.

On Thu, Sep 20, 2007 at 09:56:28PM +0100, Floris Bruynooghe wrote:
> I've just committed the changes for the upgrade to 4.1.0 omniorb4,
> here some notes:
> 
>  * Maintainer field is set to pkg-corba-devel at a.d.o.

Right.

>  * I've added myself to the Uploaders field to shut up lintian.  As I
>    have no upload permissions whatsoever I'm not sure if that's even
>    allowed, feel free to remove me again and I'll live with all the
>    lintian errors.

That's indeed the way to go. This is how co-maintainers are declared,
even though the field name does not reflect this.

>  * I need to do more upgrade testing from 4.0.0-2.3 to 4.1.0-1.
> 
>  * I also need to investigate the omniNames init script a bit more as
>    it has sometimes failed to bring up my omniNames in the past few
>    months.

I'm rebuilding it now. We should probably use piuparts to test the
update.

A few remarks and questions:
 * svn-bp:origUrl property on debian/ has to be changed to retrieve the
   latest tarball
 * please mention all significant changes you've made in
   debian/changelog, and do not hesitate to be verbose when describing
   these changes (e.g. debhelper compat level, package renamed because
   of new upstream version)
 * it is a common practice to credit people for their patches in the
   changelog
 * can you please add a note explaining that "the package is being taken
   over by the CORBA team, with blessing from Bastian Blank" to the
   changelog?
 * why did you remove Conflicts: and Provides: from some packages? I'll
   review this more carefully next week, as this has effects on the
   upgrade path
 * there are small typos in your changelog entries and in the copyright
 * about #282811:
   o does the upgrade from package 4.0.6 to 4.1 allows to retrieve
     existing database?
   o wouldn't /var/lib/omniorb4 be more appropriate? I mean if another
     omniorb service maintains a persistent state in another db, it
     would end up in the same directory
 * #430281 should be fixed by this upload as well
 * ditto for #430422 (which version is wrong ;-)
 * we need to sort out remaining bugs

> Also some notes on the svn-buildpackage usage we chose:
> 
>  * svn-upgrade does not merge your changes to the upstream changes in
>    mergeWithUpstream mode, which makes it a more then necessary
>    painful exercise.
> 
>  * I found the lack of being easily able to diff between the new
>    upsteam and my new changes rather anoying.
> 
> Both would be fixed when using svn-buildpackage withouth the
> mergeWithUpstream AIUI, so I would like to try that out for
> python-omniorb2 and see how it goes.

It seems copyMyFilesOverUpstream would be more correct :)

The only other approach I can think of is storing patches, and adapting
them for new releases. How did you proceed to adapt the changes to the
new release? If you don't use mergeWithUpstream, how do you plan to
work?

Cheers,

Thomas