RFC: Moving kubuntu packaging branches to pkg-kde git

[Philip Muskovac]

On Thursday 07 August 2014 09:55:56 Maximiliano Curia wrote:
> ¡Hola Rohan!
> 
> El 2014-07-29 a las 16:10 +0200, Rohan Garg escribió:
> > > - master: has the shared packaging and targets the latest upstream
> > > (beta?)
> > > release (which should really be everything as long as something doesn't
> > > cause a problem for the other team)
> > > 
> > > - <series> (e.g. unstable, utopic): has any distribution specific
> > > changes that cannot be kept in master (like specific patches,
> > > recommends/suggests changes for archive reasons)
> > > and is used to generate the actual archive packages for that specific
> > > series.
> This is mostly ok, but, as I mentioned via irc, I think it would be better
> to split branches only when there is a packaging difference, and it should
> be a goal to minimize these.
> 
> Right now, we have merged some bzr history for simple packages, mostly
> uneventful, some of the things that we need to solve are:
> 
>  - debian/control Maintainer field
> 
>  Right now Debian packages use:
>   Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>
>  And Ubuntu packages use:
>   Maintainer: Kubuntu Developers <kubuntu-devel at lists.ubuntu.com>
>   XSBC-Original-Maintainer: Debian Qt/KDE Maintainers
> <debian-qt-kde at lists.debian.org> The merged packages use:
>   Maintainer: Debian/Ubuntu Qt/KDE Maintainers
> <debian-qt-kde at lists.debian.org> X-Ubuntu-Maintainer: Kubuntu Developers
> <kubuntu-devel at lists.ubuntu.com>
> 
>  There is a proposal of ScottK to use a debian/control.in to generate the
>  right fields on each case (using the version vendor was it?), I would
>  prefer to set some Maintainer string we can live with and avoid
>  regenerating the debian/control file on build.

Wasn't the whole point of the maintainer change that debian maintainers were 
grumpy about getting mails from issues in derivatives?
If we do a shared maintenance of packages on alioth I *personally* wouldn't 
mind just dumping the kubuntu part here.

> 
>  - Bumping build dependencies versions
> 
>  Kubuntu packages force the rebuild of the kde packages against the newer
>  versions of the libs it uses, even if upstream doesn't require them and/or
>  there is no abi/api change between them, while in Debian we try to bump the
> build dependencies because the upstream CMakeLists.txt declares that it
> needs the newer version or to upload the package in a way that waits for a
> transition to happend.
> 
>  The Kubuntu solution could end up hiding some abi breakage, which, in
> Debian, we would prefer to expose.

We do that really to make our life easier... and did you dump kde-sc-dev-
latest? What we do is pretty much a replacement for that as versioned breaks 
don't work on launchpad.
You have a point though as e.g. we did not notice the ABI breakage in 
kdepimlibs that you found a couple days ago.

> 
>  - Updating packages without source changes
> 
>  On each kde release there are a number of packages that have no changes
>  upstream, in Debian we skip those packages.
> 
>  Again, problems with these packages would expose an abi breakage.

We already only update packages with diffs in post-release updates, so it would 
be trivial to just do that all the time. (The exceptions are kde4libs and 
kdepimlibs which are always updated)

At least if we keep using our scripts we'll have to fix the version bumping 
that we talked about in the previous point.

> 
> > > While I believe that this mostly should work fine, at this point I'm not
> > > quite sure how to manage the changelog. OdyX suggested generating it
> > > from the git commit messages which I think would work out best, as we
> > > could then keep our respective distribution changelogs and only share
> > > the change messages.
> As mentioned via irc, the changelogs can be merged (dpkg-mergechangelogs can
> be useful here), keeping in mind that the first upload of an upstream
> version to a particular distribution requires a full upload, so we'll need
> to use an explicit '-sa' to upload an upstream version that the other
> distribution have already uploaded.
> 
> > > For now, I would propose trying this shared repository idea out with the
> > > new kf5 and later also the plasma packages as you don't have any
> > > repositories for those yet.
> > 
> > Could we move this forward maybe? :D
> 
> Yes, I believe this is the right way.

How would you propose we handle updating copyright files? As you probably know 
we are pretty lazy when it comes to that (as it's a horrible black hole for 
developer time). Would you be fine with updating that whenever you get to the 
point of uploading? Or do you have a process that allows updating them pretty 
fast?
Maybe we could set up a script to check the copyright changes between upstream 
versions to make that faster?

Philip