RFC: Moving kubuntu packaging branches to pkg-kde git

[Maximiliano Curia]

¡Hola Philip!

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?

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

-- 
"Good judgement comes from experience, and experience comes from bad
judgement."
-- Fred Brooks
Saludos /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20140813/20bcb097/attachment.sig>