Re: Let's get in release mode!
El Dissabte, 14 de desembre de 2013, a les 20:30:14, Kevin Ottens va escriure: > Hello everyone, > > Now we're really getting there! Epics and review board are clean, thanks to > everyone who helped to get there. Now it's the time to go for the last push. > For that I opened what will be the last epic for the 5.0 release: > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation As discussed on IRC the other day I added a "Make sure the Frameworks handle l10n correctly" task that links to http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/l10n Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
Le mercredi 18 décembre 2013 00:00:57 Cornelius Schumacher a écrit : > On Tuesday 17 December 2013 Kevin Ottens wrote: > > That's an option. We could also see if we could make inqlude.org job > > easier, I guess it uses a similar input format too. > > Yes, inqlude.org uses a similar meta file, but I would argue it's more > simple, and we have full control about it. Going to start a new mail thread for this discussion. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Wed, Dec 18, 2013 at 2:24 AM, Ben Cooksley wrote: > > I have now re-split kdelibs, updated repositories can be found in the > usual place. > One new conflict did come up - kdnssd is already taken, so it was called > kdnssd-framework instead. > Thank you Ben. I've just pushed updates to kdesrc-build - it will now build all frameworks instead of kdelibs-frameworks. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 11:47 PM, Martin Klapetek wrote: > On Tue, Dec 17, 2013 at 11:39 AM, David Faure wrote: > >> On Tuesday 17 December 2013 23:27:39 Ben Cooksley wrote: >> > Other than apidox, I was also concerned about frameworkintegration, >> > itemmodels, itemviews and dnssd. The rest of the names are quite >> > descriptive as to what they contain and are fine. >> >> Yeah, itemmodels and itemviews often come up as not descriptive enough, >> but nobody has fixed that. What could we do? kf5itemmodels, kf5itemviews? >> > > Fwiw, I'd suggest to remove the "5" from repo name, because when we'll do > kf6 (couple years away, but still..), we'll have to either rename the repos > again or create set of new repos. > I have now re-split kdelibs, updated repositories can be found in the usual place. One new conflict did come up - kdnssd is already taken, so it was called kdnssd-framework instead. > > Cheers > -- > Martin Klapetek | KDE Developer > Thanks, Ben > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tuesday 17 December 2013 Kevin Ottens wrote: > > That's an option. We could also see if we could make inqlude.org job > easier, I guess it uses a similar input format too. Yes, inqlude.org uses a similar meta file, but I would argue it's more simple, and we have full control about it. I was actually planning to look into adding inqlude manifests to the frameworks repositories, but wanted to wait with putting up a patch for review until after the split. -- Cornelius Schumacher ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tuesday 17 December 2013 11:32:46 Aurélien Gâteau wrote: > On Tue, 17 Dec 2013 11:17:35 +0100, Aurélien Gâteau wrote: > > On Mon, 16 Dec 2013 18:17:59 +0100, Kevin Ottens wrote: > >>> Regarding the split: what is going to happen to the frameworks > >>> branch of the > >>> kdelibs repository after the split? Is it going to be removed or is > >>> it > >>> going to stay there with the framework folders pointing to the > >>> framework > >>> repositories through git sub-modules? The work on the graph > >>> generator and > >>> api.kde.org will be different depending on what the branch becomes. > >> > >> Consider it removed from the graph generator pov. Technically it'll > >> stay but > >> will be frozen (no push allowed). > > > > Do you have a plan to indicate which tier a framework belongs to? My > > kf5dot tool relies on folder names right now, but it's not going to > > work > > anymore. I am thinking there should be either a standard > > meta-information file in the root of each framework repository, or a > > standard variable set within CMake which we can grep out (a bit > > ugly). > > Replying to myself: I think using DOAP files [1] would provide a place > to store this (through an extension) and other information like > licenses and maintainers. That's an option. We could also see if we could make inqlude.org job easier, I guess it uses a similar input format too. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: framework names (Re: Let's get in release mode!)
On 17/12/13 15:31, Alex Merry wrote: > On 17/12/13 15:26, Aurélien Gâteau wrote: >> On Tue, 17 Dec 2013 14:54:44 +, Alex Merry wrote: >>> On 17/12/13 12:57, Aurélien Gâteau wrote: > I guess the question is - what does this module actually bring. I > assume, a consistent look-n-feel for KDE-produced api docs, right? Yes. It also goes a bit further by doing things like generating menus in the sidebar and handling cross-doxygen search (though that bit could use some improvements). It should at some point include the work I did on dependency diagram generation. >>> >>> It almost sounds like this is more sysadmin-ish than framework-ish... >> >> In all case, this code was in kdelibs until now, so even if it is not a >> framework since it does not provide libraries for applications to >> link to and is not used by the end user, it needs a repository. >> >> It is tied to frameworks though. It expects to find certain files in >> projects source code in order to build its documentation, for example a >> Mainpage.dox file to build api.kde.org sidebar menu. >> >> I expect more conventions regarding docs are going to be defined, which >> all projects documented on api.kde.org will have to follow so that >> apidox can extract relevant information from there. > > Oh, absolutely, I agree with all of that. However, it might be better > suited to a different location on projects.kde.org. And, I should add, this may influence the name it is given. Personally, I'd go for something like kde-apidox: it generates apidox in the preferred style of the KDE community. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: framework names (Re: Let's get in release mode!)
On Tue, 17 Dec 2013 14:54:44 +, Alex Merry wrote: On 17/12/13 12:57, Aurélien Gâteau wrote: I guess the question is - what does this module actually bring. I assume, a consistent look-n-feel for KDE-produced api docs, right? Yes. It also goes a bit further by doing things like generating menus in the sidebar and handling cross-doxygen search (though that bit could use some improvements). It should at some point include the work I did on dependency diagram generation. It almost sounds like this is more sysadmin-ish than framework-ish... In all case, this code was in kdelibs until now, so even if it is not a framework since it does not provide libraries for applications to link to and is not used by the end user, it needs a repository. It is tied to frameworks though. It expects to find certain files in projects source code in order to build its documentation, for example a Mainpage.dox file to build api.kde.org sidebar menu. I expect more conventions regarding docs are going to be defined, which all projects documented on api.kde.org will have to follow so that apidox can extract relevant information from there. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: framework names (Re: Let's get in release mode!)
On 17/12/13 15:26, Aurélien Gâteau wrote: > On Tue, 17 Dec 2013 14:54:44 +, Alex Merry wrote: >> On 17/12/13 12:57, Aurélien Gâteau wrote: I guess the question is - what does this module actually bring. I assume, a consistent look-n-feel for KDE-produced api docs, right? >>> >>> Yes. It also goes a bit further by doing things like generating menus >>> in the sidebar and handling cross-doxygen search (though that bit could >>> use some improvements). It should at some point include the work I did >>> on dependency diagram generation. >> >> It almost sounds like this is more sysadmin-ish than framework-ish... > > In all case, this code was in kdelibs until now, so even if it is not a > framework since it does not provide libraries for applications to > link to and is not used by the end user, it needs a repository. > > It is tied to frameworks though. It expects to find certain files in > projects source code in order to build its documentation, for example a > Mainpage.dox file to build api.kde.org sidebar menu. > > I expect more conventions regarding docs are going to be defined, which > all projects documented on api.kde.org will have to follow so that > apidox can extract relevant information from there. Oh, absolutely, I agree with all of that. However, it might be better suited to a different location on projects.kde.org. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: framework names (Re: Let's get in release mode!)
On 17/12/13 12:57, Aurélien Gâteau wrote: >> I guess the question is - what does this module actually bring. I >> assume, a consistent look-n-feel for KDE-produced api docs, right? > > Yes. It also goes a bit further by doing things like generating menus > in the sidebar and handling cross-doxygen search (though that bit could > use some improvements). It should at some point include the work I did > on dependency diagram generation. It almost sounds like this is more sysadmin-ish than framework-ish... Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: framework names (Re: Let's get in release mode!)
On Tue, 17 Dec 2013 13:25:02 +0100, David Faure wrote: On Tuesday 17 December 2013 23:27:39 Ben Cooksley wrote: Other than apidox, I was also concerned about frameworkintegration, itemmodels, itemviews and dnssd. Let's rename the repos to kitemmodels, kitemviews and kdnssd, this will be in line with karchive and most others (this doesn't change the actual framework target name or the library name). Anyone up for doing this today? Aurélien: so apidox is useful to all kde software? It is used to build all docs on api.kde.org, which covers most of KDE SC I think. Then it could be kdeapidox or kapidox or something like that, right? Both are equally undescriptive, but I don't have any better suggestions, so I am fine with either :) I guess the question is - what does this module actually bring. I assume, a consistent look-n-feel for KDE-produced api docs, right? Yes. It also goes a bit further by doing things like generating menus in the sidebar and handling cross-doxygen search (though that bit could use some improvements). It should at some point include the work I did on dependency diagram generation. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
framework names (Re: Let's get in release mode!)
On Tuesday 17 December 2013 23:27:39 Ben Cooksley wrote: > Other than apidox, I was also concerned about frameworkintegration, > itemmodels, itemviews and dnssd. Let's rename the repos to kitemmodels, kitemviews and kdnssd, this will be in line with karchive and most others (this doesn't change the actual framework target name or the library name). Anyone up for doing this today? Aurélien: so apidox is useful to all kde software? Then it could be kdeapidox or kapidox or something like that, right? I guess the question is - what does this module actually bring. I assume, a consistent look-n-feel for KDE-produced api docs, right? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 11:39 AM, David Faure wrote: > On Tuesday 17 December 2013 23:27:39 Ben Cooksley wrote: > > Other than apidox, I was also concerned about frameworkintegration, > > itemmodels, itemviews and dnssd. The rest of the names are quite > > descriptive as to what they contain and are fine. > > Yeah, itemmodels and itemviews often come up as not descriptive enough, > but nobody has fixed that. What could we do? kf5itemmodels, kf5itemviews? > Fwiw, I'd suggest to remove the "5" from repo name, because when we'll do kf6 (couple years away, but still..), we'll have to either rename the repos again or create set of new repos. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tuesday 17 December 2013 23:27:39 Ben Cooksley wrote: > Other than apidox, I was also concerned about frameworkintegration, > itemmodels, itemviews and dnssd. The rest of the names are quite > descriptive as to what they contain and are fine. Yeah, itemmodels and itemviews often come up as not descriptive enough, but nobody has fixed that. What could we do? kf5itemmodels, kf5itemviews? But actually the frameworks are already called that way, right? So this is really just about the git repo? Which are in fact frameworks/itemmodels.git, in terms of projects.kde.org? > kde4support is also problematic as it is very similar to kdesupport and > could become confused with it. Yeah, it's always been the case though (kde4support vs kdesupport). People know what to find in kde4support, from its name, for historical reasons. kdesupport, OTOH is kind of going away anyway, its contents should be framework-ified soon. > kf5umbrella also seemed a little odd... Better than "umbrella" :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, 17 Dec 2013 11:17:35 +0100, Aurélien Gâteau wrote: On Mon, 16 Dec 2013 18:17:59 +0100, Kevin Ottens wrote: Regarding the split: what is going to happen to the frameworks branch of the kdelibs repository after the split? Is it going to be removed or is it going to stay there with the framework folders pointing to the framework repositories through git sub-modules? The work on the graph generator and api.kde.org will be different depending on what the branch becomes. Consider it removed from the graph generator pov. Technically it'll stay but will be frozen (no push allowed). Do you have a plan to indicate which tier a framework belongs to? My kf5dot tool relies on folder names right now, but it's not going to work anymore. I am thinking there should be either a standard meta-information file in the root of each framework repository, or a standard variable set within CMake which we can grep out (a bit ugly). Replying to myself: I think using DOAP files [1] would provide a place to store this (through an extension) and other information like licenses and maintainers. Aurélien [1]: https://github.com/edumbill/doap/wiki ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 10:59 PM, David Faure wrote: > On Tuesday 17 December 2013 21:40:48 Ben Cooksley wrote: > > On Tue, Dec 17, 2013 at 9:37 PM, David Faure wrote: > > > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > > > > I do have some reservations as to the name of quite a few of those > > > > repositories however as they are very generic - and thus tread on > common > > > > namespace. Suggestions are welcome. > > > > > > In case anyone wonders, here's the full list of frameworks: > > > > > > apidoxkauthkconfigwidgets kded > kf5umbrella > > > kiconthemeskjs kparts ktextwidgets sonnet > > > dnssd kbookmarks kcoreaddons kdesu > > > kfileaudiopreview kidletime kjsembedkplotting > > > kunitconversion threadweaver > > > frameworkintegration kcmutils kcrash kdewebkit > > > kglobalaccel > > > kimageformats kmediaplayerkprintutils kwallet xmlgui > > > itemmodelskcodecs kdbusaddons kdewidgets > kguiaddons > > > kinit knewstuff kpty kwidgetsaddons > > > itemviews kcompletion kde4support kdoctools khtml > > > kioknotifications krosskwindowsystem > > > karchive kconfig kdeclarativekemoticons ki18n > > > kjobwidgetsknotifyconfig kservice solid > > Did we really mean for apidox to be a framework? > > Other than that, it's not too bad, is it? > Only very few don't start with a k, and those who don't, map to the actual > brand name of the framework (ThreadWeaver, Sollid). Other than apidox, I was also concerned about frameworkintegration, itemmodels, itemviews and dnssd. The rest of the names are quite descriptive as to what they contain and are fine. It isn't the lack of starting with a k which bothers me - but more the claim to a generic name. KPty, KArchive, KConfig all stand on their own - itemmodels doesn't really... kde4support is also problematic as it is very similar to kdesupport and could become confused with it. kf5umbrella also seemed a little odd... > > > > There is one exception to the above naming scheme, KWallet - as the > > > > "kwallet" repository already exists it has been called > > > > "kwallet-framework" instead. > > > > > > We should probably merge these two repos together > > > > I see. The current KWallet repository exists as part of kdeutils, so that > > will be a little difficult in the interim. > > Can someone else help with that? I think this requires clever usage of git > filter-branch, which I don't know anything about. > > > > > Also, the following frameworks could not be pushed due to audit (EOL) > > > > failures, something which shouldn't exist in final code: > > > > - kde4support > > > > - kdoctools > > > > - kjsembed > > > > > > What's the plan? Shall I include support for fixing that in the > splitting > > > script, and we re-run it for these? > > > > That would be a good idea, alternately one could fix it in commits made > to > > kdelibs prior to the split. Either would work I imagine, depends on what > > makes it easier for the Git graft I guess. > > Ah, that means re-splitting everything, so it conflicts with the last > issue in > this email (pushing onto the existing repos). OK, let's fix one thing at a > time then. > > Do you have the error messages for these 3 repos? Or how can I find out > where > the EOL problems are? (`file` doesn't help much with C++ code). > > Is it missing EOL at EOF, or CRLF/LF mixup? I assumed the latter but > flip -u **/*.cpp **/*.h doesn't make any changes... > It was a CRLF/LF issue - the hooks don't check for EOL at EOF. Output is at http://pastebin.kde.org/ppl8uu2bt > > > > Everything else went fine as far as I can tell, although it wasn't > > > > possible to see if the astyle tools ran or not. > > > > > > It didn't. Can I run it and push to the frameworks repos? > > > > I've granted you force push powers to the frameworks repos. The commit > > notification hooks should still be off for them. > > Thanks, I'll do that later then, after the re-splitting. > Oki. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > > Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 11:15 PM, Alex Merry wrote: > On 17/12/13 08:37, David Faure wrote: > > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > >> I do have some reservations as to the name of quite a few of those > >> repositories however as they are very generic - and thus tread on common > >> namespace. Suggestions are welcome. > > > > In case anyone wonders, here's the full list of frameworks: > > > > apidoxkauthkconfigwidgets kded > kf5umbrella > > kiconthemeskjs kparts ktextwidgets sonnet > > dnssd kbookmarks kcoreaddons kdesu > > kfileaudiopreview kidletime kjsembedkplotting > kunitconversion > > threadweaver > > frameworkintegration kcmutils kcrash kdewebkit > kglobalaccel > > kimageformats kmediaplayerkprintutils kwallet xmlgui > > itemmodelskcodecs kdbusaddons kdewidgets kguiaddons > > kinit knewstuff kpty kwidgetsaddons > > itemviews kcompletion kde4support kdoctools khtml > > kioknotifications krosskwindowsystem > > karchive kconfig kdeclarativekemoticons ki18n > > kjobwidgetsknotifyconfig kservice solid > > kdewidgets needs to become kdesignerplugin -- I was too late getting > that commit in to the kdelibs repo. The "internal" renaming can happen > later, but is it easier to rename the repo itself now or later? > That needs to happen as soon as possible essentially. Once things get set in concrete they'll be much harder to change as it will mean making changes in many, many places. > > Alex > Thanks, Ben > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Mon, 16 Dec 2013 18:17:59 +0100, Kevin Ottens wrote: Hello, On Monday 16 December 2013 15:16:42 Aurélien Gâteau wrote: Do you want us to add ourselves as contacts in the table or do you plan to fill it later? If the former, I would assign myself to "Get the dependency graph generator script ready", "Have the frameworks on api.kde.org" (already did some work in that area last week, http://api.kde.org/frameworks/kdelibs-apidocs/ looks more complete now) and I'd like to help with "Reduce the KDE footprint in ECM as much as possible". As usual, put your name next to it when you turn it into "in progress". I pre- allocated a couple because I knew some discussion was going on (maybe I shouldn't have). OK, will do. Regarding the split: what is going to happen to the frameworks branch of the kdelibs repository after the split? Is it going to be removed or is it going to stay there with the framework folders pointing to the framework repositories through git sub-modules? The work on the graph generator and api.kde.org will be different depending on what the branch becomes. Consider it removed from the graph generator pov. Technically it'll stay but will be frozen (no push allowed). Do you have a plan to indicate which tier a framework belongs to? My kf5dot tool relies on folder names right now, but it's not going to work anymore. I am thinking there should be either a standard meta-information file in the root of each framework repository, or a standard variable set within CMake which we can grep out (a bit ugly). Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On 17/12/13 08:37, David Faure wrote: > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: >> I do have some reservations as to the name of quite a few of those >> repositories however as they are very generic - and thus tread on common >> namespace. Suggestions are welcome. > > In case anyone wonders, here's the full list of frameworks: > > apidoxkauthkconfigwidgets kdedkf5umbrella > > kiconthemeskjs kparts ktextwidgets sonnet > dnssd kbookmarks kcoreaddons kdesu > kfileaudiopreview kidletime kjsembedkplotting > kunitconversion > threadweaver > frameworkintegration kcmutils kcrash kdewebkit kglobalaccel > > kimageformats kmediaplayerkprintutils kwallet xmlgui > itemmodelskcodecs kdbusaddons kdewidgets kguiaddons > > kinit knewstuff kpty kwidgetsaddons > itemviews kcompletion kde4support kdoctools khtml > > kioknotifications krosskwindowsystem > karchive kconfig kdeclarativekemoticons ki18n > > kjobwidgetsknotifyconfig kservice solid kdewidgets needs to become kdesignerplugin -- I was too late getting that commit in to the kdelibs repo. The "internal" renaming can happen later, but is it easier to rename the repo itself now or later? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, 17 Dec 2013 10:59:45 +0100, David Faure wrote: On Tuesday 17 December 2013 21:40:48 Ben Cooksley wrote: On Tue, Dec 17, 2013 at 9:37 PM, David Faure wrote: > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > > I do have some reservations as to the name of quite a few of those > > repositories however as they are very generic - and thus tread on common > > namespace. Suggestions are welcome. > > In case anyone wonders, here's the full list of frameworks: > > apidoxkauthkconfigwidgets kded kf5umbrella > kiconthemeskjs kparts ktextwidgets sonnet > dnssd kbookmarks kcoreaddons kdesu > kfileaudiopreview kidletime kjsembedkplotting > kunitconversion threadweaver > frameworkintegration kcmutils kcrash kdewebkit > kglobalaccel > kimageformats kmediaplayerkprintutils kwallet xmlgui > itemmodelskcodecs kdbusaddons kdewidgets kguiaddons > kinit knewstuff kpty kwidgetsaddons > itemviews kcompletion kde4support kdoctools khtml > kioknotifications krosskwindowsystem > karchive kconfig kdeclarativekemoticons ki18n > kjobwidgetsknotifyconfig kservice solid Did we really mean for apidox to be a framework? Poor apidox needs a home :). Even if it is does not provide libraries to build applications on top of it, it needs to have a repository, right? Apidox is used by several libraries to agregate multiple Doxygen projects, I'd be actually interested in turning it into something usable outside of api.kde.org (I am weird in that way: I like to work on documentation tools) Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tuesday 17 December 2013 21:40:48 Ben Cooksley wrote: > On Tue, Dec 17, 2013 at 9:37 PM, David Faure wrote: > > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > > > I do have some reservations as to the name of quite a few of those > > > repositories however as they are very generic - and thus tread on common > > > namespace. Suggestions are welcome. > > > > In case anyone wonders, here's the full list of frameworks: > > > > apidoxkauthkconfigwidgets kdedkf5umbrella > > kiconthemeskjs kparts ktextwidgets sonnet > > dnssd kbookmarks kcoreaddons kdesu > > kfileaudiopreview kidletime kjsembedkplotting > > kunitconversion threadweaver > > frameworkintegration kcmutils kcrash kdewebkit > > kglobalaccel > > kimageformats kmediaplayerkprintutils kwallet xmlgui > > itemmodelskcodecs kdbusaddons kdewidgets kguiaddons > > kinit knewstuff kpty kwidgetsaddons > > itemviews kcompletion kde4support kdoctools khtml > > kioknotifications krosskwindowsystem > > karchive kconfig kdeclarativekemoticons ki18n > > kjobwidgetsknotifyconfig kservice solid Did we really mean for apidox to be a framework? Other than that, it's not too bad, is it? Only very few don't start with a k, and those who don't, map to the actual brand name of the framework (ThreadWeaver, Sollid). > > > There is one exception to the above naming scheme, KWallet - as the > > > "kwallet" repository already exists it has been called > > > "kwallet-framework" instead. > > > > We should probably merge these two repos together > > I see. The current KWallet repository exists as part of kdeutils, so that > will be a little difficult in the interim. Can someone else help with that? I think this requires clever usage of git filter-branch, which I don't know anything about. > > > Also, the following frameworks could not be pushed due to audit (EOL) > > > failures, something which shouldn't exist in final code: > > > - kde4support > > > - kdoctools > > > - kjsembed > > > > What's the plan? Shall I include support for fixing that in the splitting > > script, and we re-run it for these? > > That would be a good idea, alternately one could fix it in commits made to > kdelibs prior to the split. Either would work I imagine, depends on what > makes it easier for the Git graft I guess. Ah, that means re-splitting everything, so it conflicts with the last issue in this email (pushing onto the existing repos). OK, let's fix one thing at a time then. Do you have the error messages for these 3 repos? Or how can I find out where the EOL problems are? (`file` doesn't help much with C++ code). Is it missing EOL at EOF, or CRLF/LF mixup? I assumed the latter but flip -u **/*.cpp **/*.h doesn't make any changes... > > > Everything else went fine as far as I can tell, although it wasn't > > > possible to see if the astyle tools ran or not. > > > > It didn't. Can I run it and push to the frameworks repos? > > I've granted you force push powers to the frameworks repos. The commit > notification hooks should still be off for them. Thanks, I'll do that later then, after the re-splitting. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 9:37 PM, David Faure wrote: > On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > > I do have some reservations as to the name of quite a few of those > > repositories however as they are very generic - and thus tread on common > > namespace. Suggestions are welcome. > > In case anyone wonders, here's the full list of frameworks: > > apidoxkauthkconfigwidgets kdedkf5umbrella > kiconthemeskjs kparts ktextwidgets sonnet > dnssd kbookmarks kcoreaddons kdesu > kfileaudiopreview kidletime kjsembedkplotting > kunitconversion > threadweaver > frameworkintegration kcmutils kcrash kdewebkit kglobalaccel > kimageformats kmediaplayerkprintutils kwallet xmlgui > itemmodelskcodecs kdbusaddons kdewidgets kguiaddons > kinit knewstuff kpty kwidgetsaddons > itemviews kcompletion kde4support kdoctools khtml > kioknotifications krosskwindowsystem > karchive kconfig kdeclarativekemoticons ki18n > kjobwidgetsknotifyconfig kservice solid > > > There is one exception to the above naming scheme, KWallet - as the > > "kwallet" repository already exists it has been called > "kwallet-framework" > > instead. > > We should probably merge these two repos together > I see. The current KWallet repository exists as part of kdeutils, so that will be a little difficult in the interim. > > > Also, the following frameworks could not be pushed due to audit (EOL) > > failures, something which shouldn't exist in final code: > > - kde4support > > - kdoctools > > - kjsembed > > What's the plan? Shall I include support for fixing that in the splitting > script, and we re-run it for these? > That would be a good idea, alternately one could fix it in commits made to kdelibs prior to the split. Either would work I imagine, depends on what makes it easier for the Git graft I guess. > > > Everything else went fine as far as I can tell, although it wasn't > possible > > to see if the astyle tools ran or not. > > It didn't. Can I run it and push to the frameworks repos? > I've granted you force push powers to the frameworks repos. The commit notification hooks should still be off for them. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > > Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tuesday 17 December 2013 14:10:56 Ben Cooksley wrote: > I do have some reservations as to the name of quite a few of those > repositories however as they are very generic - and thus tread on common > namespace. Suggestions are welcome. In case anyone wonders, here's the full list of frameworks: apidoxkauthkconfigwidgets kdedkf5umbrella kiconthemeskjs kparts ktextwidgets sonnet dnssd kbookmarks kcoreaddons kdesu kfileaudiopreview kidletime kjsembedkplottingkunitconversion threadweaver frameworkintegration kcmutils kcrash kdewebkit kglobalaccel kimageformats kmediaplayerkprintutils kwallet xmlgui itemmodelskcodecs kdbusaddons kdewidgets kguiaddons kinit knewstuff kpty kwidgetsaddons itemviews kcompletion kde4support kdoctools khtml kioknotifications krosskwindowsystem karchive kconfig kdeclarativekemoticons ki18n kjobwidgetsknotifyconfig kservice solid > There is one exception to the above naming scheme, KWallet - as the > "kwallet" repository already exists it has been called "kwallet-framework" > instead. We should probably merge these two repos together > Also, the following frameworks could not be pushed due to audit (EOL) > failures, something which shouldn't exist in final code: > - kde4support > - kdoctools > - kjsembed What's the plan? Shall I include support for fixing that in the splitting script, and we re-run it for these? > Everything else went fine as far as I can tell, although it wasn't possible > to see if the astyle tools ran or not. It didn't. Can I run it and push to the frameworks repos? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Tue, Dec 17, 2013 at 1:04 PM, Ben Cooksley wrote: > On Mon, Dec 16, 2013 at 10:18 AM, Kevin Ottens wrote: > >> On Sunday 15 December 2013 10:58:35 Alex Merry wrote: >> > On 14/12/13 19:30, Kevin Ottens wrote: >> > > Now we're really getting there! Epics and review board are clean, >> thanks >> > > to >> > > everyone who helped to get there. Now it's the time to go for the last >> > > push. For that I opened what will be the last epic for the 5.0 >> release: >> > > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation >> > > >> > > As you can see it is split in two, one part for the tech preview, the >> > > second part for what will be needed for a final release. I urge >> everyone >> > > to focus on the tech preview tasks for now. Don't hesitate to give a >> hand >> > > to the people I put in contact for those tasks. >> > >> > I'd like to rename the makekdewidgets executable to something like >> > kgendesignerplugin, to be more descriptive; this should be SC providing >> > we keep the old CMake variables around, but should probably still happen >> > before the TP, I guess? >> >> Can happen either before or after IMO. You can go ahead with it (as it >> looks >> small enough) if you manage to produce the change before Ben starts >> splitting >> the repositories. :-) >> > > I have now begun the process of splitting the repositories out. > kdelibs[frameworks] has now been frozen for pushes for all except myself, > ervin and dfaure to allow for any last minute changes if absolutely > necessary. > > More news on the testing repositories will follow soon. > The repositories have now been created and pushed, with a few exceptions. They can be found at https://projects.kde.org/projects/frameworks, and are available under their respective framework name at g...@git.kde.org: I do have some reservations as to the name of quite a few of those repositories however as they are very generic - and thus tread on common namespace. Suggestions are welcome. There is one exception to the above naming scheme, KWallet - as the "kwallet" repository already exists it has been called "kwallet-framework" instead. Also, the following frameworks could not be pushed due to audit (EOL) failures, something which shouldn't exist in final code: - kde4support - kdoctools - kjsembed Everything else went fine as far as I can tell, although it wasn't possible to see if the astyle tools ran or not. > > >> >> Regards. >> -- >> Kévin Ottens, http://ervin.ipsquad.net >> >> KDAB - proud supporter of KDE, http://www.kdab.com >> >> >> ___ >> Kde-frameworks-devel mailing list >> Kde-frameworks-devel@kde.org >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel >> >> Thanks, > Ben > Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Mon, Dec 16, 2013 at 10:18 AM, Kevin Ottens wrote: > On Sunday 15 December 2013 10:58:35 Alex Merry wrote: > > On 14/12/13 19:30, Kevin Ottens wrote: > > > Now we're really getting there! Epics and review board are clean, > thanks > > > to > > > everyone who helped to get there. Now it's the time to go for the last > > > push. For that I opened what will be the last epic for the 5.0 release: > > > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation > > > > > > As you can see it is split in two, one part for the tech preview, the > > > second part for what will be needed for a final release. I urge > everyone > > > to focus on the tech preview tasks for now. Don't hesitate to give a > hand > > > to the people I put in contact for those tasks. > > > > I'd like to rename the makekdewidgets executable to something like > > kgendesignerplugin, to be more descriptive; this should be SC providing > > we keep the old CMake variables around, but should probably still happen > > before the TP, I guess? > > Can happen either before or after IMO. You can go ahead with it (as it > looks > small enough) if you manage to produce the change before Ben starts > splitting > the repositories. :-) > I have now begun the process of splitting the repositories out. kdelibs[frameworks] has now been frozen for pushes for all except myself, ervin and dfaure to allow for any last minute changes if absolutely necessary. More news on the testing repositories will follow soon. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud supporter of KDE, http://www.kdab.com > > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
Hello, On Monday 16 December 2013 15:16:42 Aurélien Gâteau wrote: > Do you want us to add ourselves as contacts in the table or do you plan to > fill it later? If the former, I would assign myself to "Get the dependency > graph generator script ready", "Have the frameworks on api.kde.org" (already > did some work in that area last week, > http://api.kde.org/frameworks/kdelibs-apidocs/ looks more complete now) and > I'd like to help with "Reduce the KDE footprint in ECM as much as > possible". As usual, put your name next to it when you turn it into "in progress". I pre- allocated a couple because I knew some discussion was going on (maybe I shouldn't have). > Regarding the split: what is going to happen to the frameworks branch of the > kdelibs repository after the split? Is it going to be removed or is it > going to stay there with the framework folders pointing to the framework > repositories through git sub-modules? The work on the graph generator and > api.kde.org will be different depending on what the branch becomes. Consider it removed from the graph generator pov. Technically it'll stay but will be frozen (no push allowed). Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
Le samedi 14 décembre 2013 20:30:14 Kevin Ottens a écrit : > Hello everyone, > > Now we're really getting there! Epics and review board are clean, thanks to > everyone who helped to get there. Now it's the time to go for the last push. > For that I opened what will be the last epic for the 5.0 release: > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation Do you want us to add ourselves as contacts in the table or do you plan to fill it later? If the former, I would assign myself to "Get the dependency graph generator script ready", "Have the frameworks on api.kde.org" (already did some work in that area last week, http://api.kde.org/frameworks/kdelibs-apidocs/ looks more complete now) and I'd like to help with "Reduce the KDE footprint in ECM as much as possible". Regarding the split: what is going to happen to the frameworks branch of the kdelibs repository after the split? Is it going to be removed or is it going to stay there with the framework folders pointing to the framework repositories through git sub-modules? The work on the graph generator and api.kde.org will be different depending on what the branch becomes. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On 15/12/13 21:18, Kevin Ottens wrote: > On Sunday 15 December 2013 10:58:35 Alex Merry wrote: >> I'd like to rename the makekdewidgets executable to something like >> kgendesignerplugin, to be more descriptive; this should be SC providing >> we keep the old CMake variables around, but should probably still happen >> before the TP, I guess? > > Can happen either before or after IMO. You can go ahead with it (as it looks > small enough) if you manage to produce the change before Ben starts splitting > the repositories. :-) Huh, looks like kdewidgets was never renamed to kf5designerplugin at all. I'm on a train (and hence off the internet) for most of this afternoon. Working on the assumption the splitting won't happen today, I'll work on renaming that framework (including the executable). I'll also move the .desktop files for Qt's imageformat plugins from kimageformats to kde4support (to be with their user, KImageIO), on the basis that you shouldn't need to install kimageformats to use KImageIO on Qt's imageformat plugins. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Sunday 15 December 2013 16:38:40 Albert Astals Cid wrote:
> El Dissabte, 14 de desembre de 2013, a les 20:30:14, Kevin Ottens va
escriure:
> > Hello everyone,
> >
> > Now we're really getting there! Epics and review board are clean, thanks
> > to
> > everyone who helped to get there. Now it's the time to go for the last
> > push. For that I opened what will be the last epic for the 5.0 release:
> > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
> >
> > As you can see it is split in two, one part for the tech preview, the
> > second part for what will be needed for a final release. I urge everyone
> > to focus on the tech preview tasks for now. Don't hesitate to give a hand
> > to the people I put in contact for those tasks.
> >
> > Obviously splitting the repositories will likely come first as it was the
> > focus for the past efforts.
> >
> > In particular please help Ben with the transition to the split
> > repositories
> > by first not pushing stuff (although if he prevents pushes in the first
> > place you'll be the ones with patches to port ;)) and second by
> > extensively
> > testing the repositories once they are online. We might need several tries
> > to get them ready, so pay attention to Ben's communication as he'll
> > obviously coordinate that with his sysadmin super powers.
> >
> > Once the technology preview is tagged, then all attention will be needed
> > on
> > the remaining tasks to get a final release. This list looks suspiciously
> > short to me (although some tasks are in fact rather large), so either
> > we're
> > in a good position already or I missed some stuff... The later being the
> > most probable don't hesitate to add more to the list if you see fit. This
> > list of tasks is basically our disguised definition of done for KF 5.0. If
> > we get all the tasks done we should be able to release right away.
> >
> > After the technology preview we'll switch to a time based release for
> > alphas and betas. We still have to decide on a frequency (I'm leaning
> > toward every two weeks). It will be a good exercise to find issues in our
> > release process and fix them before 5.0 final.
>
> I'm missing a task so that the mentions of KDE4 in frameworks is smaller
> than it is now, a quick grep gives me stuff like
>
> ./INSTALL:2:http://techbase.kde.org/Getting_Started/Build/KDE4
> ./tier2/kauth/src/kauthactionreply.h:158:
> kde4_add_executable( your sources...)
> ./tier2/kauth/src/kauthactionreply.h:174:
> kde4_install_auth_actions( )
> ./tier4/apidox/src/doxygen-preprocess-kcfg.sh:5:kcfg_compiler="`kde4-config
> -- prefix`/bin/kconfig_compiler"
> ./tier4/apidox/src/doxygen-preprocess-kcfg.sh:5:kcfg_compiler="`kde4-config
> -- prefix`/bin/kconfig_compiler"
> ./tier3/knewstuff/tests/CMakeLists.txt:56:#kde4_add_executable(kdxspreview
> TEST ${kdxspreview_SRCS})
> ./tier3/xmlgui/src/kbugreport.cpp:395: // ### KDE4: why oh why is
> KEMailSettings in kio?
> ./tier3/kio/src/widgets/thumbcreator.h:57: * find_package(KDE4 REQUIRED)
> ./tier3/kio/src/widgets/thumbcreator.h:58: * include (KDE4Defaults)
> ./tier3/kio/src/kpac/CMakeLists.txt:10:set(CMAKE_CXX_FLAGS
> "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
>
> And lots more that seem to be wrong/leftovers/needattention.
Makes sense, feel free to add to the bottom table on the wiki page.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Sunday 15 December 2013 10:58:35 Alex Merry wrote: > On 14/12/13 19:30, Kevin Ottens wrote: > > Now we're really getting there! Epics and review board are clean, thanks > > to > > everyone who helped to get there. Now it's the time to go for the last > > push. For that I opened what will be the last epic for the 5.0 release: > > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation > > > > As you can see it is split in two, one part for the tech preview, the > > second part for what will be needed for a final release. I urge everyone > > to focus on the tech preview tasks for now. Don't hesitate to give a hand > > to the people I put in contact for those tasks. > > I'd like to rename the makekdewidgets executable to something like > kgendesignerplugin, to be more descriptive; this should be SC providing > we keep the old CMake variables around, but should probably still happen > before the TP, I guess? Can happen either before or after IMO. You can go ahead with it (as it looks small enough) if you manage to produce the change before Ben starts splitting the repositories. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
El Dissabte, 14 de desembre de 2013, a les 20:30:14, Kevin Ottens va escriure:
> Hello everyone,
>
> Now we're really getting there! Epics and review board are clean, thanks to
> everyone who helped to get there. Now it's the time to go for the last push.
> For that I opened what will be the last epic for the 5.0 release:
> http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
>
> As you can see it is split in two, one part for the tech preview, the second
> part for what will be needed for a final release. I urge everyone to focus
> on the tech preview tasks for now. Don't hesitate to give a hand to the
> people I put in contact for those tasks.
>
> Obviously splitting the repositories will likely come first as it was the
> focus for the past efforts.
>
> In particular please help Ben with the transition to the split repositories
> by first not pushing stuff (although if he prevents pushes in the first
> place you'll be the ones with patches to port ;)) and second by extensively
> testing the repositories once they are online. We might need several tries
> to get them ready, so pay attention to Ben's communication as he'll
> obviously coordinate that with his sysadmin super powers.
>
> Once the technology preview is tagged, then all attention will be needed on
> the remaining tasks to get a final release. This list looks suspiciously
> short to me (although some tasks are in fact rather large), so either we're
> in a good position already or I missed some stuff... The later being the
> most probable don't hesitate to add more to the list if you see fit. This
> list of tasks is basically our disguised definition of done for KF 5.0. If
> we get all the tasks done we should be able to release right away.
>
> After the technology preview we'll switch to a time based release for alphas
> and betas. We still have to decide on a frequency (I'm leaning toward every
> two weeks). It will be a good exercise to find issues in our release
> process and fix them before 5.0 final.
I'm missing a task so that the mentions of KDE4 in frameworks is smaller than
it is now, a quick grep gives me stuff like
./INSTALL:2:http://techbase.kde.org/Getting_Started/Build/KDE4
./tier2/kauth/src/kauthactionreply.h:158: kde4_add_executable(
your sources...)
./tier2/kauth/src/kauthactionreply.h:174:
kde4_install_auth_actions( )
./tier4/apidox/src/doxygen-preprocess-kcfg.sh:5:kcfg_compiler="`kde4-config --
prefix`/bin/kconfig_compiler"
./tier4/apidox/src/doxygen-preprocess-kcfg.sh:5:kcfg_compiler="`kde4-config --
prefix`/bin/kconfig_compiler"
./tier3/knewstuff/tests/CMakeLists.txt:56:#kde4_add_executable(kdxspreview
TEST ${kdxspreview_SRCS})
./tier3/xmlgui/src/kbugreport.cpp:395: // ### KDE4: why oh why is
KEMailSettings in kio?
./tier3/kio/src/widgets/thumbcreator.h:57: * find_package(KDE4 REQUIRED)
./tier3/kio/src/widgets/thumbcreator.h:58: * include (KDE4Defaults)
./tier3/kio/src/kpac/CMakeLists.txt:10:set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}
${KDE4_ENABLE_EXCEPTIONS}")
And lots more that seem to be wrong/leftovers/needattention.
Cheers,
Albert
>
> Regards.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On 14/12/13 19:30, Kevin Ottens wrote: > Now we're really getting there! Epics and review board are clean, thanks to > everyone who helped to get there. Now it's the time to go for the last push. > For that I opened what will be the last epic for the 5.0 release: > http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation > > As you can see it is split in two, one part for the tech preview, the second > part for what will be needed for a final release. I urge everyone to focus on > the tech preview tasks for now. Don't hesitate to give a hand to the people I > put in contact for those tasks. I'd like to rename the makekdewidgets executable to something like kgendesignerplugin, to be more descriptive; this should be SC providing we keep the old CMake variables around, but should probably still happen before the TP, I guess? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
On Saturday 14 December 2013 20:55:30 Sebastian Kügler wrote: > Hi Kévin, > > On Saturday, December 14, 2013 20:30:14 Kevin Ottens wrote: > > Once the technology preview is tagged, then all attention will be needed > > on the remaining tasks to get a final release. This list looks > > suspiciously short to me (although some tasks are in fact rather large), > > so either we're in a good position already or I missed some stuff... > > I just looked for the "what's left" myself, just two days ago. Where is this > definition of done documented? Sorry if I've been unclear in that part, it was the URL linked at the beginning of my email: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation And yes it wasn't here two days ago, as I said I opened it yesterday. It's really the finalization tasks toward a release. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Let's get in release mode!
Hi Kévin, On Saturday, December 14, 2013 20:30:14 Kevin Ottens wrote: > Once the technology preview is tagged, then all attention will be needed on > the remaining tasks to get a final release. This list looks suspiciously > short to me (although some tasks are in fact rather large), so either we're > in a good position already or I missed some stuff... I just looked for the "what's left" myself, just two days ago. Where is this definition of done documented? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Let's get in release mode!
Hello everyone, Now we're really getting there! Epics and review board are clean, thanks to everyone who helped to get there. Now it's the time to go for the last push. For that I opened what will be the last epic for the 5.0 release: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation As you can see it is split in two, one part for the tech preview, the second part for what will be needed for a final release. I urge everyone to focus on the tech preview tasks for now. Don't hesitate to give a hand to the people I put in contact for those tasks. Obviously splitting the repositories will likely come first as it was the focus for the past efforts. In particular please help Ben with the transition to the split repositories by first not pushing stuff (although if he prevents pushes in the first place you'll be the ones with patches to port ;)) and second by extensively testing the repositories once they are online. We might need several tries to get them ready, so pay attention to Ben's communication as he'll obviously coordinate that with his sysadmin super powers. Once the technology preview is tagged, then all attention will be needed on the remaining tasks to get a final release. This list looks suspiciously short to me (although some tasks are in fact rather large), so either we're in a good position already or I missed some stuff... The later being the most probable don't hesitate to add more to the list if you see fit. This list of tasks is basically our disguised definition of done for KF 5.0. If we get all the tasks done we should be able to release right away. After the technology preview we'll switch to a time based release for alphas and betas. We still have to decide on a frequency (I'm leaning toward every two weeks). It will be a good exercise to find issues in our release process and fix them before 5.0 final. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
