aloha packagers today the idea of continuous packaging popped up and I wanted to get some general thoughts on the matter.
# what is this? CP is essentially what project-neon does, build all packages off of upstream git. Conceptually this technically is supposed lto be like proper CI (i.e. build as often as possible with as small changes as possible and run tests). Since this is partially not very practical from a packaging perspective let's for now think of it as regular daily builds. # what's wrong with neon? :O Neon is built in a very specific way. Namely: - completely different prefix - excessive envrionment manipulation to separate data lookup (as much as possible) as well as user specific data and settings storage - single binary units (i.e. each upstream git repo creates exactly one debian package) It is made this way because it creates next to no overhead in packaging, this is curcial to what neon is meant to achive: Provide the most bleeding edge of KDE software *next to* the ongoing efforts of high quality packaging we do manually. In other words neon is made in such a way that it does not take away developer time from the real meat, at the expense of Debian policy compliance (in some ways anyway). # so how would CP be different from neon? The idea is instead of doing daily dummy packages with only one deb as described above we build our actual packages on a daily basis against an actual upstream git branch. Continuously adjusting our packaging to what is in git and will therefore eventually become a release we will pick up. # why oh why? Right now we get a batch of a upstream tarballs, throw our *old* packaging at it, and then hammer at it until it builds. This is not only stressful it also scales really bad. The more changes are between old-release and new-release the more hammering is needed, the longer it takes, the more exhausting it is, the more bugs we introduce. Add to that the fact that we sometimes get a very excessive batch of partially even unrelated releases at pretty much the same time and you've occupied some 2 or 3 packagers for a week or two (think KDE SC, Plasma and KF5 in the same week for example). # how does CP solve that? The idea is, every day you have changes trickle in, ever so slowly, built against our packaging HEAD. Instead of getting a crazy week at the beginning of each month we spend maybe 5 minutes a day adjusting the packages that need adjustment and once the actual release hits we take our packaging throw it at the release tarballs and everything builds without problems (in theory). # why, there must be a downside to all this... Numerous tiny problems popping up all over the place that will need to have solutions invented. So it would be good if we could think of as many as possible before moving forward. I'll make a start: - unless we replicate tooling for l10n retrieval, there won't be translations and more importantly .install files that explicitly list /usr/share/locale/ will fail - doing CP makes packaging branches more confusing unless we actually land into archive (which would seem slightly terrible) as we'd have two HEAD branches... one for the actual packaging in the archive and one for the CP that is constantly moving, since keeping a handle on many branches in bzr is a jolly nightmare I am not too fond of this # and what about the tech? Thanks to blue systems and yours truly most of the tech does already exist and drives neon5 ;) So, what do you guys and gals reckon? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel