As previously discussed, here's a preliminary plan for continuous packaging.
# stage 1 - recycle neon orchestration tech to build plasma5 workspace from master using next packaging (this might need branching to support the fact that we need two packaging versions that are both moving at the same time) # stage 2 - introduce auto QA measures and along with that a proposed/stage/landing PPA which is used to conduct QA before promotion to live ppa - britney? - file move detection? - auto upgrade testing # stage 3 - expand CP to frameworks - expand CP to stable branches # stage 4 - kick neon in a bin - possibly expand to more than one series (e.g. one could have trunk, stable, stable/trusty, trunk/trusty branches ....) this entirely depends on effort involved etc. generally though with sufficient degrees of automation one could get to a point where a fix in the oldest supported version will be forward merged automatically and subsequently trigger new builds such that ideally one commit can fix aaaaaaaaaalllllllllll builds for aaaaaaaaaaaaallllllllllllll kubuntu series # problem resolutions - l10n being absent: source package builder needs to attempt a smart sed to drop usr/share/locale/ from installs - inter-package version dependent packages: need to be figured out on a case by case basis, for the time being this should not be applicable for plasma5 so this will only present an issue further down the road as more stuff will get covered - mixed archness (i.e. amd64 built before i386 data makes stuff explode) this will be solved by advanced build retry tech doing a deep dep resolution before attempt a retry. additionally stage 2 QA would prevent update breakage due to missing arch:all deps # unresoved problems - multiple branches are a nightmare for human beings in bzr since a branch is always a repo and handling multiple repos with different paths and different folders locally will totally go wrong at some point. a move to git would be best, question is where to. - if one is to CP frameworks the package would be the same for trunk and stable respectively, so someone will need to come up with an idea to not pointlessly waste resources there (possibly a binary copy dependency is needed) -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
