This post is to get some opinions about changing how KaOS ships Plasma 5.
Currently KDE releases a new major version every 3 months. For the first few weeks after a new release, there is a weekly minor version, then slows down to every 2-3 weeks, until a beta for the new major version comes out.

Issue is, new stable weekly/bi-weekly tars are tagged and released the same day, no testing upstream, many times, no one even build them before releasing.
Almost all KDE devs run and work on master Plasma git only, and only know issues in that branch. Bug fixes are much quicker available in master then anywhere else. New features (which most of the time are really needed options) can take months to move to release tars. This will be especially true with plasma 5.8. This is an LTS release, intended for distros staying on old Qt, so it can implement features that only Qt 5.7 and above support.

What is suggested now is to do a Plasma 5 build from git master for KaOS. Leave that build one week in the [build] repo for thorough checking (and if needed, create an internal test ISO with it), then move to all users.

This way there won't be a need to constantly backport much needed patches from git master and do many in between releases rebuilds.
Applications that don't see any commits in git will be left off these automated builds. Examples are (huge) oxygen-icons & plasma-workspace-wallpapers.

What is your opinion in this?

    I prefer the new way. Less patches and bugs, faster features...

    I also prefer the new way, thanks for asking.

    I also prefer the new way.

    +1 for getting the new shiny thing sooner. Hopefully the experience will be like that of chrome-dev; new features sooner and rare, if any, breakage.

    I didn't quite understand as to how often you will be building from git. I am guessing anytime you detect significant changes or a bug is reported/fixed?

    Never mind the question. The title says bi-weekly. Read the contents, missed the title 🙂

    • demm replied to this.

      jantarmantar
      Plan is to coordinate more with Frameworks releases, those are tagged (and build for KaOS) the first Saturday of each month and released the second Saturday. Now quite often Plasma is a few weeks behind and I end up rebuilding all of Plasma on new Frameworks.
      So plan is to build right after new Frameworks first Saturday and move second Saturday, then do another build the third Saturday.

      For clarification, KDE devs uses latest git stable branch, because in this moment master == 5.8, now not even in beta stage. Patchs are applied in stable branch and forwarded to master (most of time, in some cases commited simultaneously). New features is applied to master, but they don't use them in master, it's applied to stable branch.

        I support the idea of building from git master, but that reason for that is (as demm described) how KDE devs work. As I see it, it steals unnecessary time from demm: rebuild on new Frameworks, additional patches (back)ported to stable from master git to remove problems, ... With building from master demm has a less work to do (and more time to focus on other nicer things 🙂). If the tarballs were more tested, then it would be another thing.

        Plasma 5.8 will be an LTS release (the current master in git, release in mid October). Is there a chance that at this point the devs will run 5.8 or will they stay on master (future 5.9)? I don't know the KDE development good enough to make a guess on this. If the devs switch to the LTS to work on and 5.9 becomes a lame duck, than the whole point of switching to master might backfire. There is currently no date set in the release shedule for Plasma 5.9 (which should be released around jan/Feb 2017).

        Also, what do you want to build from master git. Plasma (Desktop), Frameworks and Applications? Or only Plasma and Frameworks and Applications stay on tarballs?

        • demm replied to this.

          adurol bvbfan
          Only Plasma will see this change. Frameworks is always based on master and the releases are tagged, tested a week, then released, so you don't see the same issue as in Plasma.
          Apps have no need either. Those that need a git build already have that in KaOS, the rest again is tested with a week between tagging and release.

          Devs being on "stable" only is not a correct assumption, many use master exclusively.
          But it does bring up a point I thought of too, what when master is just opened for new development? And is very Alpha?
          For that I think it is best to stay flexible. Example, say in 2-3 weeks start to build from git master, Plasma 5.7.90. Once Plasma 5.8 is just released, stay with that branch a few more weeks, bi-weekly git builds from 5.8. Then when master reaches 5.8.90 or so, switch to master again.
          The buildscripts have already been adjusted that automation for this just works.

          I'm afraid this has hit a major hurdle.
          Translations for KDE are not part of any git, they have a complete separate place and need all kinds of ruby scripts to be extracted and then somehow added to one "plasma l10n" package or added to each plasma 5 package.

          No answer at all how to make this work and if this can't be solved, then git builds for Plasma 5 are not an option, the desktop needs to be tramslated.

          Translations issue is resolved, new package added "plasma-l10n"
          The today released Plasma 5.7.4 will be build from git as a first test.

          Can you add 'bg' for bulgarian language in plasma-l10n.

          • demm replied to this.

            Please add also estonian language 🙂

            • demm replied to this.