¡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 /\/\ /\ >< `/
signature.asc
Description: Digital signature
-- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
