kits logic

[skunk]

hello devs (oleg)  :)

 

i wonder what are the rules behind this new kit organization...

• do packages from the master branch eventually make into a prime branch or are prime branches virtually immutable?
• if the former, after lying into the the master branch for some time (like gentoo's stable/unstable)? how long? any other criterion instead?
• if the latter, are "stable users" supposed to jump from prime-n to prime-n+1 branches at their discretion?

for example i'm on the default 5.10-prime kde-kit's branch and i see that kde-plasma-5.11.0, kde-frameworks-5.39 and kde-apps-17.08.2 were added to the master branch.

i expect at least kde-apps-17.08.2 to make into the 5.10-prime branch since it's a bug fix release, while kde-plasma-5.11.0 to be sometimes added to a new default 5.11-prime branch since it's a major release, not sure about frameworks-5.39 but i consider it pretty safe to include it into 5.10-prime after reaching master for some time...

 

so just curious to know how this new kit organization method works and what's its internal rules  :)

 

thank you

[Oleg Vinichenko]

packages are not flowing from master into prime branches. when new (testing) branch is created ebuilds/eclasses that creating a branch are coming from a certain snapshot of gentoo portage tree controlled by git SHA. it can be set to false, so it is not enabled by default but is available for testing, it can be set to true, when its ready to be used by default. a good thing is that users are actually allowed to do whatever they want with the branches, however the consequences might be various. when the problem happening with default prime branches, there are sa-called kit-fixups, which serve for fixing - it may involve minor ebuilds updates, not critical ebuild updates, security backports and other.

so yes, branches are partially immutable

[skunk]

so in my kde-kit example shall i expect a new, let's say, 5.10-prime-r1 branch with kde-apps-17.08.2 or will it only (kde-apps-17.08.2) be available into the new 5.11-prime branch?

if the latter it would be very unfortunate for someone wanting to stay stable (keep on plasma 5.10 while getting apps 17.08 bugfixes)...

 

thank you

[drobbins]

When we create a 'prime' kit, the idea is that it is snapshotted so we can stabilize it for users. The name is supposed to reflect the version of the main thing in the kit. It looks like we chose a bad time to create 5.10-prime but the general idea would be to just do bug fixes on it until it is very high 'prime' quality.

It may have been better to create a 5-prime kde-kit and that is something we could look into doing instead. I don't use KDE so I need input from others about what is likely to be stable over the long haul.

The goal of a prime kde kit is to just get everything working consistently for users. It may not be bleeding edge but it will be a good starting point. And then we would roll out newer prime kits that are also stable, etc. so the changes would come in controlled and tested groups rather than dribble in as they do now.

[skunk]

thank you daniel for your explication,

kde software compilation, how it's called today, consists of 3 components:

• kde-framework: with a monthly release schedule which may include both bugfixes and new features, since there are no minor versions, it may be snapshotted at any time
• kde-plasma: with frequent minor releases (for bugfixes) and a new major release every 5-6 months, since there usually are just 5 minor versions (except from lts releases), taking a snapshot when it reach a 5.x.5 version it would make an ideal point for a prime release
• kde-apps: with about monthly minor releases (for bugfixes) and a new major release every 4 months, here too since there are just 3 minor versions, taking a snapshot every yy.mm.3 version would be a good point for a stable prime release

imho a prime snapshot should be taken whenever we have a yy.mm.3 kde-apps release and it should include whatever 5.x.5 kde-plasma version it's available at that time if prime snapshots are meant to be (almost) static.

else if snapshots would allow minor changes it would be nice to have for example a 5.12.x lts prime snapshot where bugfixes are pushed when released upstream and (if sub-kits would exist) kde-apps snapshots could be pulled and installed on top of it...

i also notice that dev-qt stuff was added to the kde-kit, i'm not sure if that's a good idea since there are other desktop environments in the desktop-kit that depends on qt5 like lxqt and lumina, but mostly because making a certain kde release dependant from a concrete qt5 release can complicate the snapshotting even more in case of (security) bugfixes that only qt can deliver, so a separate qt-kit would make more sense... of course imho... ;)

thank you

[drobbins]

OK, well this is really good info -- besides this info, what do you think we should do, resnapshot a 5.11-prime and try to stabilize this? or should be have a 'wider' definition for the version so we can bump to 5.12.x? Beyond?

[skunk]

well... none... :) if you ask me, i would better branch on kde-apps version instead of kde-desktop version and number it as follows:

• 17.08.3-prime which includes kde-apps-17.08.3 (due nov. 6) kde-desktop-5.10.5 (released) kde-framework-5.40 (due nov. 4)
• 17.12.3-prime which includes kde-apps-17.12.3 (due march 8) kde-desktop-5.11.5 (due jan. 2) kde-framework-5.whatever on march 8
• 18.04.3-prime which includes kde-apps-18.04.3 (due sometime in july) kde-desktop-5.12.6 (due june 20) kde-framework-5.whatever in july

branching it on kde-desktop version would need to push kde-apps fixes releases to the branch, even more for a wider definition...
doing it on kde-apps instead just have to push -r releases with security issues, again imho...

[skunk]

it would also be very cool to have an lts branch (like eg.18.08.3-lts-prime) which would install latest  kde-apps-18.08.3 with kde-desktop-5.12.7 instead of kde-desktop-5.13.5 like 18.08.3-prime would do...

[Oleg Vinichenko]

i know gentoo never updates kde parts asynchronously, so having a separate kits for kde-apps/frameworks/plasma doesn't seem a necessary step. this could change on their side, of course :)

[skunk]

what do you mean exactly with updating kde parts asynchronously?

kde-apps/frameworks/plasma have different independent release schedules and gentoo adds new ebuild short after there is a release of any of the 3 components afaik...

[Oleg Vinichenko]

that's right, but ebuilds are not added this way. gentoo adding whole update of kde-apps/plasma/frameworks and not partial categories or they do?

[skunk]

i'm pretty sure they actually do it since one component release can be quite far away (in terms of time) from the other...

[drobbins]

So skunk, you are suggesting we have a kde-kit which maybe we snapshot and get to 'prime' quality, and then we have a kde-apps kit that many users may want to set to 'master' to get the latest fixes... or something like this?

[skunk]

well yes, would be nice to have the possibility to choose between kde-plasma-release and kde-plasma-lts...

however if it's too much fuss, just branch using kde-apps as reference instead of kde-desktop...

[pereira.alex]

Why not follow their own definity of lts ?

Having version prime-5.8 of plasma ( which is lts ) and 5.11 which is release. Their 5.8 version ( and I think upcomming 5.12 ) are lts versions, which will be supported much longer than normal releases.