Re: RFC: Release Management Going Forward
Sebastian Kügler wrote: Let me dump my brain and add how I see release management going forward from here: = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) I would welcome this immensely, even if a bit late. I know a couple distros (fedora, kubuntu at least) had serious complaints about the the current tarball splitting, but have begrudingly been putting in a lot of effort to adapt anyway for lack of repreive. -- rex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: Release Management Going Forward
On Friday 10 June 2011 03:31:20 Sebastian Kügler wrote: I suggest that we also add monolithic tarballs, starting from beta 2. This way we have split and combined tarballs. And I suggest that we continue to do this for the whole 4.7 cycle. And we need to discuss this again for 4.8. Yep, the layout of the tarballs should be the same as for the 4.6.0 release. On top of that, I suggest not changing the layout for 4.8. See below :) I think what hurts most on a packaging level is the uncertainty whether the layout is going to change again (now or later). So, I'd agree with not changing the (split) layout at all anymore and in addition provide monolithic tars. = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) What should be worked out is whether the layout of apps/components that are already split is going to stay the way they are split now, or whether that might change completely for 5.x (thus discouraging packager adoption at this time unless they see value in having intermediate changes). = 5.x = = Notes = * target groups for frameworks are specifically: distros, app developers, 3rd party developers * more frequent releases? More frequent releases does not translate to more frequent adoption though, so I doubt it would have much affect for distros and 3rd party developers (I really do not think latter will build frameworks from source if their distribution already provides everything ready to go). Just something to keep in mind. If a distro is releasing once a year, the better part of the target audience will still get new (QA'd/integrated) versions only once a year. -- Harald ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: Release Management Going Forward
On Friday 10 June 2011, Alexander Neundorf wrote: Yes, sure, but I'm away from this noon until Sunday evening. Is this needed already now for 4.7 ? I was hoping to have some more weeks to give it more testing and finish it. (it being the Superbuild CMakeLists.txt, which provide builds in old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. Alex, can I make use of that now? I would like to tag RC1 tomorrow. For which modules is this right now ? kdesupport, kdegraphics, more ? kdeedu as well, kde-baseapps and kde-runtime. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: Release Management Going Forward
On Monday 20 June 2011, Dirk Mueller wrote: On Friday 10 June 2011, Alexander Neundorf wrote: Yes, sure, but I'm away from this noon until Sunday evening. Is this needed already now for 4.7 ? I was hoping to have some more weeks to give it more testing and finish it. (it being the Superbuild CMakeLists.txt, which provide builds in old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. Alex, can I make use of that now? I would like to tag RC1 tomorrow. Please give it a try, and let me know how it goes, what is missing, etc. I guess a way to give additional cmake argument to the subprojects is at least necessary, right ? The currently existing documentation is this: https://projects.kde.org/projects/kde/superbuild Or, in other words, I do not yet have any feedback from packagers, except the early feedback from Sune in Randa, which is incorporated now, but no fresh feedback yet. So, I'd say you can try it and see whether creating the source packages and building them later on works ok, but simply using it to create the source packages and then hope they work for all packagers might be a bit much. For which modules is this right now ? kdesupport, kdegraphics, more ? kdeedu as well, kde-baseapps and kde-runtime. If you look at the superbuild CMakeLists.txt, you'll see the files are basically trivial :-) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: Release Management Going Forward
On Friday 10 June 2011, Sebastian Kügler wrote: Hey Tom, :) On Thursday, June 09, 2011 22:21:01 Tom Albers wrote: I think we have to respond to the current problems with the beta 1 release. The adaption among distro's wasn't what we are used to due to our unclear message about if this layout is going to be final. Yeah, I think we've created quite a mess, and we need to make our releases backwards compatible for our downstreams, those that consume it. I suggest that we also add monolithic tarballs, starting from beta 2. This way we have split and combined tarballs. And I suggest that we continue to do this for the whole 4.7 cycle. And we need to discuss this again for 4.8. Yep, the layout of the tarballs should be the same as for the 4.6.0 release. On top of that, I suggest not changing the layout for 4.8. See below :) The big problem here is that the release-team has no resources to generate these monolithic tarballs. If we were to decide this, we need help from the buildsystem to adapt our scripts to generate them. The question to the buildsystem guys is, if anyone wants to stand up and help with this. I'm all for it. And I volunteer Alex! ;-) Yes, sure, but I'm away from this noon until Sunday evening. Is this needed already now for 4.7 ? I was hoping to have some more weeks to give it more testing and finish it. (it being the Superbuild CMakeLists.txt, which provide builds in old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. What still needs to be done: - add special handling DESTDIR - add handling for tags - maybe some work on the implementation of ExternalProject in cmake For which modules is this right now ? kdesupport, kdegraphics, more ? Let me dump my brain and add how I see release management going forward from here: = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) = 5.x = There is no 5 ;-) * KDE SC releases ship latest stable of everything * Apps require KDE Frameworks version = 5.x * Independent version numbering of apps * Plasma Desktop, Netbook, Active as separate apps * Apps can do intermittent releases, or skip cycles * KDE Frameworks 5.x ** Mostly source compatible to 4.x ** Strong backwards compatibility commitment, automatic tests if possible ** split out tarballs for KDE Qt Addons and Solutions (see discussion on kde- core-devel) ** monolithic tarballs for easier packaging ** high level git integration tool(s) to make the lives of those who build from source easier = Notes = * precise layout for split frameworks to be decided on k-c-d * first frameworks release aimed at as soon as possible after Qt 5.0 * everything else up to k-c-d * code is released from master branches, which should always be stable (see git workflow thread on k-c-d) * target groups for frameworks are specifically: distros, app developers, 3rd party developers * more frequent releases? The above provides a rough plan that is in line with the results from the Platform11 sprint in Randa. I've deliberately spared many details, to give us back some high-level overview. discuss =) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RFC: Release Management Going Forward
Hey Tom, :) On Thursday, June 09, 2011 22:21:01 Tom Albers wrote: I think we have to respond to the current problems with the beta 1 release. The adaption among distro's wasn't what we are used to due to our unclear message about if this layout is going to be final. Yeah, I think we've created quite a mess, and we need to make our releases backwards compatible for our downstreams, those that consume it. I suggest that we also add monolithic tarballs, starting from beta 2. This way we have split and combined tarballs. And I suggest that we continue to do this for the whole 4.7 cycle. And we need to discuss this again for 4.8. Yep, the layout of the tarballs should be the same as for the 4.6.0 release. On top of that, I suggest not changing the layout for 4.8. See below :) The big problem here is that the release-team has no resources to generate these monolithic tarballs. If we were to decide this, we need help from the buildsystem to adapt our scripts to generate them. The question to the buildsystem guys is, if anyone wants to stand up and help with this. I'm all for it. And I volunteer Alex! ;-) Let me dump my brain and add how I see release management going forward from here: = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) = 5.x = * KDE SC releases ship latest stable of everything * Apps require KDE Frameworks version = 5.x * Independent version numbering of apps * Plasma Desktop, Netbook, Active as separate apps * Apps can do intermittent releases, or skip cycles * KDE Frameworks 5.x ** Mostly source compatible to 4.x ** Strong backwards compatibility commitment, automatic tests if possible ** split out tarballs for KDE Qt Addons and Solutions (see discussion on kde- core-devel) ** monolithic tarballs for easier packaging ** high level git integration tool(s) to make the lives of those who build from source easier = Notes = * precise layout for split frameworks to be decided on k-c-d * first frameworks release aimed at as soon as possible after Qt 5.0 * everything else up to k-c-d * code is released from master branches, which should always be stable (see git workflow thread on k-c-d) * target groups for frameworks are specifically: distros, app developers, 3rd party developers * more frequent releases? The above provides a rough plan that is in line with the results from the Platform11 sprint in Randa. I've deliberately spared many details, to give us back some high-level overview. discuss =) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
