On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > 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 Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine. 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
