Re: KDE EPEL8 plan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm going to summarize.  Hopefully I get correctly what people have said.
Feel free to continue to comment and suggest.
At some point I'd like to put this on a EPEL KDE page for future guidance.

* Follow the KDE LTS branches as much as possible.
** qt5
*** RHEL's version of qt packages will dictate this.  If RHEL's
versions change, adjust with them.
*** RHEL 8 qt5 is 5.11.1
**** There are about 10 packages that have to stay at 5.11 due to
RHEL's packages.  The rest can get built with the current LTS, 5.12.x
*** https://download.qt.io/official_releases/qt/5.12/
** plasma
*** Follow the LTS stream that corresponds with our qt5
*** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18
**** plasma 5.18 will not be out until Feb. or March 2020.
**** Keep with our current version until them, which is 5.15
*** https://download.kde.org/stable/plasma/
*** Update all plasma at one time, if possible
** framework (kf5)
*** Use the stream that corresponds with our plasma
*** When plasma 5.18 comes out, that will be kf5 5.66
**** Keep with our current version until plasma is updated, which is 5.59
*** https://download.kde.org/stable/frameworks/
*** Update all kf5 at one time, if possible
** KDE apps
*** Let the version be the decision of each app maintainer

* For qt5, plasma and kf5, have a group be the maintainer.
* For apps, it depends on the app.  Each app can be maintained by
either a group or individual.

*  module vs non-module
** The above plan will all be for non-module kde components.  This is
what people get straight out of epel.
** There will be at least one kde module.
*** Any epel kde modules will not be enabled by default.  These are
only for people who want to test with a newer kde, or want to run the
latest kde and don't mind breaking some compatibility.
*** There will be a kde-rawhide module.
**** The kde-rawhide module will track the fedora kde packages.
**** The module will be updated once a month, building whatever is in
Fedora rawhide at that time.
*** There might be other kde modules, but none are currently planned.

As I said, this plan is open to suggestions and comments, but here is
my plan of getting things going.
It's sorta logical that I be the person who at least starts things,
even if we are going to maintain them as a group.
If nobody has any objections, on Monday, Dec. 16,  I was planning on
starting building kde in standard epel, following the above
guidelines.
I would build the qt5, plasma and k5 packages, and open bugzilla
requests for all the rest.
For most everything, I will just be pulling over what is in epel8-playground.
Hopefully we can get everything built, and in bodhi, by the end of the
week.  They can then sit and be tested while people are celebrating
the end of the year holidays.  And hopefully, at the beginning of the
new year, they will all be ready and in the epel8 repository.

Troy
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [KDE Users]     [Fedora General Discussion]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Triage]     [Coolkey]     [Yum Users]     [Yosemite Forum]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux