[Pkg-corba-devel] omniorb4 4.1.0 upgrade

[Floris Bruynooghe]

On Fri, Sep 21, 2007 at 03:30:27PM +0200, Thomas Girard wrote:
> A few remarks and questions:
>  * svn-bp:origUrl property on debian/ has to be changed to retrieve the
>    latest tarball

Oops, done.

>  * 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)

I'll try to be a bit more verbose.

>  * it is a common practice to credit people for their patches in the
>    changelog

I'll look throught the BTS to see where it's applicable.

>  * 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?

ok

>  * 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

I did this a long time ago, but IIRC I did some grep-dctrl searches
and removed the ones that where no longer used.  I like the packages
to be lean and a Conflicts: or Provides: that only make sense in
packages for old-stable just seems like unnecessary polluting of
debian/control to me.

>  * there are small typos in your changelog entries and in the copyright

Eh, I havn't got the hang yet of vim spell checking hence I don't use
it often enough... ;-)

>  * about #282811:
>    o does the upgrade from package 4.0.6 to 4.1 allows to retrieve
>      existing database?

Good point.  Don't think so as I didn't need that... I'll look into it.

>    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

I don't really have any strong feelings about this which is why I just
took what the bug reporter suggested.  Your suggestion is shorter
which is good in my book ;-)

>  * #430281 should be fixed by this upload as well
>  * ditto for #430422 (which version is wrong ;-)
>  * we need to sort out remaining bugs

All this work was mostly what I did to the package before.  I didn't
have a look at the BTS since then (but I've subscribed to the PTS
now).  So yes, these are all reasons why I said it wasn't ready for
uploading yet.

> > 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.

True, but I still think using patches and dpatch/quilt/... kind of
negates keeping everything in a VCS.

> How did you proceed to adapt the changes to the new release?

This was a bit of a special case since I had done the upgrade already
separately with uupdate, so I copied in the files that uupdate merged
for me, checking the .diff.gz of the uupdated package to see wich
files to put in the svn repo.

> If you don't use mergeWithUpstream, how do you plan to work?

Using svn-buildpackage's default behaviour, having a
branches/omniorb4/upstream/4.1.0 directory (in this case) with the
upstream unchaged and having all files, including their modifications
in the trunk.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org