Jump to content
funtoo forums

Question

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

Share this post


Link to post
Share on other sites

14 answers to this question

Recommended Posts

  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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?

Share this post


Link to post
Share on other sites
  • 0

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...

Share this post


Link to post
Share on other sites
  • 0

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...

Share this post


Link to post
Share on other sites
  • 0

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...

Share this post


Link to post
Share on other sites
  • 0

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?

Share this post


Link to post
Share on other sites
  • 0

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...

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...