RFC: Moving kubuntu packaging branches to pkg-kde git

[Philip Muskovac]

Hi Maxy,

> El 2014-08-12 a las 21:47 +0200, Philip Muskovac escribió:
> > 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)
> 
> It could be an interesting project, kde-sc-dev-latest is a nice way to do
> build dependencies change once, and thus with fewer errors, so if the amount
> of bumps needed is big enought then any development pays itself.
> 
> > 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.
> 
> I might have missed that comment. I don't see the point on
> uploading/rebuilding the package if the code doesn't change. So, what do
> they mean by unsupported? They plan to break the abi on every release?

No, not that but:
<apachelogger> framework cmakelists have one var for version
<apachelogger> that is defined to both define the framework's version and the 
versions it will look for in other frameworks
so cmake would probably be rather unhappy if you skip things. And as the 
version changes for all components each release there wouldn't really be "no" 
change.

> 
> > > > 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.
> I'm glad and surprised its useful to someone else. :)
> 
> Working in the calligra package made me reevaluate lcheck, and now I think
> that a mix of static information mixed with the auto updated blocks is
> possible.
> 
> > 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?
> 
> Sounds like a solid plan. About this particular example, I plan to build
> 4.13.97 soonish to prepare the transitions (if any) to have 4.14 in jessie.
> 
> > 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?
> 
> I'm not sure if having branches that we are not actually using/building is
> going to work, doing merges and reverts for unwanted changes is too awful?

The idea was to make things easier for your side considering we would be 
moving into your repositories...  I wouldn't mind starting out simple:
Just move our packaging to alioth and start our branches by branching from 
master and then working there like we currently do with bzr on launchpad.
Once you get to the point where you start working on a new version you could 
then merge our dev branch into master revert anything you don't want and batch 
our changelog into one update entry. After that we go and merge the result 
back into our branch and continue from there. 
That is close to what we do now (considering you've been looking at our 
packages), and should be an easy enough workflow for people to switch to.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20140813/d0a4e006/attachment.sig>