RFC: Moving kubuntu packaging branches to pkg-kde git

[Philip Muskovac]

Hi Maxy,

On Thursday 07 August 2014 12:44:37 Maximiliano Curia wrote:
> ¡Hola Philip!
> 
> El 2014-08-07 a las 10:39 +0200, Philip Muskovac escribió:
> > Wasn't the whole point of the maintainer change that debian maintainers were
> > grumpy about getting mails from issues in derivatives?
> 
> Afaik it was for reports reported to the Debian maintainers that were unaware
> or not interested in the derivatives, if we are merging the teams then that
> complain shouldn't apply, it sort of depends on the noise level it generates,
> though.
> 
> Is there a way to configure the launchpad bugs to be sent to another ml instead
> of the Maintainer address ?

Launchpad doesn't really care about the Maintainer that much. At least it doesn't matter for the default bug mails so that's a non-issue. I think it's more about people that know a bit about the package management seeing the email address in the package manager.

> 
> > We do that really to make our life easier... and did you dump kde-sc-dev-
> > latest?
> 
> No, but I haven't updated it in a while. It might be obsoleted after kf5, I
> don't know.
> 
> > What we do is pretty much a replacement for that as versioned breaks
> > don't work on launchpad.
> 
> They get ignored? We still need them for moving files between packages
> and such.

They don't get ignored, but if one build-dep breaks another the build will just FTBFS instead of dep-wait on the new version. And even scripted retrying of hundreds of builds is not really fun so we dumped kde-sc-dev-latest.
The reason why we still bump versions all the time is to automatically catch kde-internal lib transitions. So even if we only update the changed packages this should still depend on the most recent packaged version (which should at that point be scripted)

On that point, how do you plan to handle no-change updates for kf5? As far as I remember upstream did say that having mismatched versions between kf5 components is unsupported.

> 
> > 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?
> 
> Doing a git diff upstream/old_version upstream/new_version | grep -i copyright
> helps, specially with no changes, but after a while you need to review the
> whole copyright file again.
> 
> There are a few projects to improve the copyright file checks [1] and
> generation [2], but nothing great. In particular, I don't like the generation
> tools that drop any change manually made to the copyright file. I use a dumb
> wrapper around licensecheck [3] to group the result by license and some vim
> macros to reformat it.
> 
> > Maybe we could set up a script to check the copyright changes between upstream 
> > versions to make that faster?
> 
> Not an easy task, but it may be possible to do a tool that either parses the
> git diff or that calls licensecheck in the old and the new tree and parses the
> licensecheck diff.
> 
> [1]: https://github.com/agustinhenze/dlt
> [2]: https://code.launchpad.net/~clint-fewbar/+junk/lcheck
> [3]: http://maxy.com.ar/debian/license-helper.py
> 

[3] is already more helpful than the other scripts I ran into so far so thanks for sharing that.

Going back to the original mail and the branch layout my original approach might've been a bit over complicated for what we actually need...
So assuming a package that can be synced, where would we put the updates? 
'master' seems to be meant for anything that targets unstable, so if you want to target 4.13 for the time being, should our changes for 4.14 be put into a 'next' that merges the unstable changes from master and is later merged back into master?
Packages with a permanent diff from us lead back to my original proposal, which would mean 'master', 'next' like above and e.g. 'utopic' that we would continuously merge with next.

Does that sound sane or do you have a better idea?

Philip