Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:30, Michal Humpula michal.hump...@seznam.cz wrote: If I may post a little input here. I've implemented print preview in kate (KF5) with QPrintPreviewDialog, mainly for the reasons mentioned above. But what I'm missing is ability to add custom configuration tabs as in KdePrint::createPrintDialog. Though KPrintPreview doesn't seems to support them either:-) Yeap, neither allows on-the-fly use of the custom tabs in the preview, which is a short-coming, but QPrintPreviewDialog at least gives the possibility of doing so in future with a dynamic update of the preview, KPrintPreview really doesn't support such a work flow. The other issue is anyone clicking on the print dialog button in the menu of QPrintPreviewDialog gets a dialog without any custom tabs either, which was one reason for not using it before when we added our extra stuff. It should be easy enough for me to add Qt api to allow you to set them and have the preview pass them through to the dialog, but I'm not sure how I'd show the widgets in the preview itself. Perhaps a button to pop them up? Something to think about anyway. John. P.S. Not forgetting that the app widgets are not cross-platform, they don't work on Windows or Mac, but that's on my feature plan for 5.4/5.5 time-frame.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 8 January 2014 07:17, Kevin Ottens er...@kde.org wrote: For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). Good point :-) I'm fine keeping it even if it's small. OK, I'll take the chainsaw to it this weekend and see what we're left with. Cheers! John.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Wednesday 08 January 2014 10:56:41 John Layt wrote: On 8 January 2014 07:17, Kevin Ottens er...@kde.org wrote: For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). Good point :-) I'm fine keeping it even if it's small. OK, I'll take the chainsaw to it this weekend and see what we're left with. Don't forget to keep SC though. Might mean properly deprecating stuff (toward kde4support for instance). 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:52, Alex Merry k...@randomguy3.me.uk wrote: If these additions are something that applications would need to be aware of, I see no issue with creating a wrapper class or some such as-and-when we find a use for one. If they are something that would be hidden to applications, would you consider having platform integration hooks in QPrinter for that sort of thing? The idea is to add things without the app needing to know or worry about, and without having to go through every app and re-code to use a new wrapper (I did that for 4.0 and 4.2, never again!). On the other hand, without knowing what those requirements might be it's a bit much to assume that the current wrapper will meet those needs. Platform hooks are possible, we have a QPA plugin for printing, but would need to be done in a cross-platform way, and until those needs arise we don't know what shape it would need to take. For color management, the idea was an extra tab would be automatically added to the dialog if color management was configured, which would then query the config for the colorspace to use and do some magic to apply it. However the proposal we discussed at the Color Management hack-fest does rely on an obscure build-time dependency and a PDF based workflow using Ghostscript that I'm really not keen on. It's also requires a decision to support Oyranos and/or colord in the core that I don't think we're ready to make yet, or indeed have the abstraction classes to do so. I think for now it's better if the Oyranos and colord camps provide their own tab widgets that apps can choose to use to configure things, and then the app takes care of deciding on color management support and workflow. I'll look again at adding the color OutputIntent to Qt's PDF support, but I'd have to do that using a QString for the ICC Profile name, when I'd rather wait until we have a proper QIccProfile class to use. Sigh, so may tasks, so little time... Anyway, far too much detail for here, I think I'm convincing myself that it's less useful to keep the empty wrapper around for now, it may be better moved to KDE4Support, along with KPrintPreview, leaving an empty repo. John.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Tuesday 07 of January 2014 23:10:11 John Layt wrote: On 7 January 2014 19:55, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 7 de gener de 2014, a les 18:24:41, Alex Merry va escriure: On 07/01/14 17:10, John Layt wrote: I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) I don't remember, but looking at email archives and Qt docs, it looks like that probably was the reason; I think we started KDE4 depending on Qt 4.3, and QPrintPreview was added in 4.4. And the underlying tech is totally different too, KPrintPreview prints to pdf and then shows the preview in an okular part while QPrintPreview does a totally different thing. I've mostly avoided looking at QPrintPreviewDialog so far (bad maintainer!), but it is basically another paint device you paint to when requested, using exactly the same painting code as you would for normal printing, or printing the preview to PDF. In theory it should be better than KPrintPreview as it only asks you to render the pages it needs as it needs them, rather than pre-rendering the whole document like KPrintPreview does, and it doesn't need the Okular KPart installed to work either. I think some apps like Calligra already prefer to use it for those reasons (that and zander being the original author). It wouldn't work for use inside Okular though, but then it always seems a little weird to do a print preview in Okular to just get an Okular window again :-) I'll do a more in-depth investigation and come back to the list to make a decision. If I may post a little input here. I've implemented print preview in kate (KF5) with QPrintPreviewDialog, mainly for the reasons mentioned above. But what I'm missing is ability to add custom configuration tabs as in KdePrint::createPrintDialog. Though KPrintPreview doesn't seems to support them either:-) Cheers Michal
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 06/01/14 06:52, Kevin Ottens wrote: I used to say that the maintenance model of kdelibs was David Faure by default. It's great to have someone like David around, but at the same time it's delusional and dangerous to think that he'll always be able to save the day. This model has to stop now. And hopefully having smaller packages will help people to feel responsible for their modules. The current list of modules is there: http://community.kde.org/Frameworks/List Having done some work on kimageformats and kmediaplayer, I would be comfortable maintaining those. Possibly also kapidox, as good apidox is something I care strongly about (although I'm not yet particularly familiar with the codebase in that module). Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Le mardi 7 janvier 2014 11:36:34 Alex Merry a écrit : On 06/01/14 06:52, Kevin Ottens wrote: I used to say that the maintenance model of kdelibs was David Faure by default. It's great to have someone like David around, but at the same time it's delusional and dangerous to think that he'll always be able to save the day. This model has to stop now. And hopefully having smaller packages will help people to feel responsible for their modules. The current list of modules is there: http://community.kde.org/Frameworks/List Having done some work on kimageformats and kmediaplayer, I would be comfortable maintaining those. Possibly also kapidox, as good apidox is something I care strongly about (although I'm not yet particularly familiar with the codebase in that module). I am also interested in kapidox, for the same reasons (and also because I want to integrate kf5dot in it). Aurélien
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Tuesday 07 January 2014 07:22:01 Kevin Ottens wrote: On Tuesday 07 January 2014 00:45:19 Christoph Feck wrote: On Monday 06 January 2014 23:54:46 Kevin Ottens wrote: On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... If everything else fails (in other words, if we really want to have a name listed, but nobody else steps up), I am willing to maintain these frameworks: - kiconthemes - kimageformats (including webp plugin from kde-runtime) - kplotting - kwidgetsaddons You can take KIconThemes, KPlotting and KWidgetsAddons then. I'm not aware of anyone else interested in those. If you're still willing to maintain them you know where and how to put your name in front of them. ;-) 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 6 January 2014 07:52, Kevin Ottens er...@kde.org wrote: I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) If the original author Petri Damstén doesn't step up, I could take on KUnitConversion, seeing as I'm partly familiar with the code. Cheers! John.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 07/01/14 17:10, John Layt wrote: I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) I don't remember, but looking at email archives and Qt docs, it looks like that probably was the reason; I think we started KDE4 depending on Qt 4.3, and QPrintPreview was added in 4.4. Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Tuesday 07 January 2014 18:10:10 John Layt wrote: On 6 January 2014 07:52, Kevin Ottens er...@kde.org wrote: I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); I've put myself down (rather obviously) for KPrintUtils. How surprising. :-) Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) Well, the initial plan was to not have KPrintUtils at all. It's here mainly because of timing issues because the necessary upstream work to get everything to disappear in KPrintUtils wasn't done in time for Qt 5.2. If the original author Petri Damstén doesn't step up, I could take on KUnitConversion, seeing as I'm partly familiar with the code. Then put your name in front with a note for Petri to kick you off if he shows up. :-) I don't think we've been in touch with him yet. 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
El Dimarts, 7 de gener de 2014, a les 18:24:41, Alex Merry va escriure: On 07/01/14 17:10, John Layt wrote: I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) I don't remember, but looking at email archives and Qt docs, it looks like that probably was the reason; I think we started KDE4 depending on Qt 4.3, and QPrintPreview was added in 4.4. And the underlying tech is totally different too, KPrintPreview prints to pdf and then shows the preview in an okular part while QPrintPreview does a totally different thing. Cheers, Albert Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 19:55, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 7 de gener de 2014, a les 18:24:41, Alex Merry va escriure: On 07/01/14 17:10, John Layt wrote: I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) I don't remember, but looking at email archives and Qt docs, it looks like that probably was the reason; I think we started KDE4 depending on Qt 4.3, and QPrintPreview was added in 4.4. And the underlying tech is totally different too, KPrintPreview prints to pdf and then shows the preview in an okular part while QPrintPreview does a totally different thing. I've mostly avoided looking at QPrintPreviewDialog so far (bad maintainer!), but it is basically another paint device you paint to when requested, using exactly the same painting code as you would for normal printing, or printing the preview to PDF. In theory it should be better than KPrintPreview as it only asks you to render the pages it needs as it needs them, rather than pre-rendering the whole document like KPrintPreview does, and it doesn't need the Okular KPart installed to work either. I think some apps like Calligra already prefer to use it for those reasons (that and zander being the original author). It wouldn't work for use inside Okular though, but then it always seems a little weird to do a print preview in Okular to just get an Okular window again :-) I'll do a more in-depth investigation and come back to the list to make a decision. John.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
El Dimarts, 7 de gener de 2014, a les 23:10:11, John Layt va escriure: On 7 January 2014 19:55, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 7 de gener de 2014, a les 18:24:41, Alex Merry va escriure: On 07/01/14 17:10, John Layt wrote: I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) I don't remember, but looking at email archives and Qt docs, it looks like that probably was the reason; I think we started KDE4 depending on Qt 4.3, and QPrintPreview was added in 4.4. And the underlying tech is totally different too, KPrintPreview prints to pdf and then shows the preview in an okular part while QPrintPreview does a totally different thing. I've mostly avoided looking at QPrintPreviewDialog so far (bad maintainer!), but it is basically another paint device you paint to when requested, using exactly the same painting code as you would for normal printing, or printing the preview to PDF. In theory it should be better than KPrintPreview as it only asks you to render the pages it needs as it needs them, rather than pre-rendering the whole document like KPrintPreview does, and it doesn't need the Okular KPart installed to work either. I think some apps like Calligra already prefer to use it for those reasons (that and zander being the original author). It wouldn't work for use inside Okular though, but then it always seems a little weird to do a print preview in Okular to just get an Okular window again :-) Okular does not use KPrintPreview anyway ;-) Cheers, Albert I'll do a more in-depth investigation and come back to the list to make a decision. John. ___ Kde-frameworks-devel mailing list kde-frameworks-de...@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 19:49, Kevin Ottens er...@kde.org wrote: Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) Well, the initial plan was to not have KPrintUtils at all. It's here mainly because of timing issues because the necessary upstream work to get everything to disappear in KPrintUtils wasn't done in time for Qt 5.2. Running through the print dialog features, I'm don't think there is anything left to be upstreamed. There's a couple of very minor CUPS features in the dialog that I don't think anyone uses (mirror page, page border, page label) that I don't really want in Qt, but can add if anyone really makes a fuss. If we decide to replace KPrintPreview with QPrintPreviewDialog then we're just left with the convenience api to create a QPrintDialog that won't actually add anything extra. That could be still worth keeping for a couple of reasons, but it could then move to KGuiAddons. The main reason to keep it is future-proofing if we need to add common widgets or extra checks again, in particular I think it may be the only way to do color-managed printing until Qt adds proper support in QtGui. If the original author Petri Damstén doesn't step up, I could take on KUnitConversion, seeing as I'm partly familiar with the code. Then put your name in front with a note for Petri to kick you off if he shows up. :-) I don't think we've been in touch with him yet. Done :-) John.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 07/01/14 22:30, John Layt wrote: Running through the print dialog features, I'm don't think there is anything left to be upstreamed. There's a couple of very minor CUPS features in the dialog that I don't think anyone uses (mirror page, page border, page label) that I don't really want in Qt, but can add if anyone really makes a fuss. If we decide to replace KPrintPreview with QPrintPreviewDialog then we're just left with the convenience api to create a QPrintDialog that won't actually add anything extra. That could be still worth keeping for a couple of reasons, but it could then move to KGuiAddons. The main reason to keep it is future-proofing if we need to add common widgets or extra checks again, in particular I think it may be the only way to do color-managed printing until Qt adds proper support in QtGui. If these additions are something that applications would need to be aware of, I see no issue with creating a wrapper class or some such as-and-when we find a use for one. If they are something that would be hidden to applications, would you consider having platform integration hooks in QPrinter for that sort of thing? Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Tuesday 07 January 2014 23:30:28 John Layt wrote: On 7 January 2014 19:49, Kevin Ottens er...@kde.org wrote: Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) Well, the initial plan was to not have KPrintUtils at all. It's here mainly because of timing issues because the necessary upstream work to get everything to disappear in KPrintUtils wasn't done in time for Qt 5.2. Running through the print dialog features, I'm don't think there is anything left to be upstreamed. There's a couple of very minor CUPS features in the dialog that I don't think anyone uses (mirror page, page border, page label) that I don't really want in Qt, but can add if anyone really makes a fuss. If we decide to replace KPrintPreview with QPrintPreviewDialog then we're just left with the convenience api to create a QPrintDialog that won't actually add anything extra. That could be still worth keeping for a couple of reasons, but it could then move to KGuiAddons. For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). The main reason to keep it is future-proofing if we need to add common widgets or extra checks again, in particular I think it may be the only way to do color-managed printing until Qt adds proper support in QtGui. I'm fine keeping it even if it's small. 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Monday 06 January 2014 09:33:38 Martin Graesslin wrote: On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? That's a good question. In my opinion it's fine for a maintainer to delegate the duties to make things work on a given platform to someone else, but, he has to be able to answer at all time is this platform supported? is there anything broken there?. I think that's important that at the end of the day the maintainer is the point of contact for the given framework. This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. Of course, for most of the frameworks it shouldn't be an issue (if they're pure Qt), that's a very valid concern for frameworks which make native calls. In that case I think it's very important that we're blunt and honest about the situation. I'd rather see a few frameworks where we claim sorry, we don't support platform X yet/at all, than having a list where we claim we support all platforms for all frameworks while we're in fact lying for some of them. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? I'd rather have a person name to be honest. It's really for the single point of contact situation in case of big troubles and to avoid diluting the responsibility. How in practice the work is then distributed for a framework is to the discretion of the appointed maintainer, if there's a whole team helping all the better. 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014, Kevin Ottens wrote: Hello all, Now that TP1 is almost out of the door, it is time to move toward the final release and put in place the governance of KDE Frameworks. It is a very large and multi-faceted product, so we will need people with longer term commitment if we want it to shine on release day. ## What's left for a final? Short answer: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation (Tasks for Final Release section) To get there, we'll move into a monthly release schedule: * Alpha 1, February 1st; * Alpha 2, March 1st; * Beta 1, April 1st; * Beta 2, May 1st; * Final, June 1st; Between beta 2 and final we'll insert release candidates following a shorter weekly cycle to nail down the remaining minor issues. We don't expect the source code to drastically change between now and final. At least, short term, we shouldn't see code flying from one framework to another one. As you can see most of the tasks revolve around the tooling next to the code (CI, buildsystem, apidox, etc.)... Still there's one big elephant missing there as it's not really something actionable: code quality. I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... ## Frameworks Governance? I used to say that the maintenance model of kdelibs was David Faure by default. It's great to have someone like David around, but at the same time it's delusional and dangerous to think that he'll always be able to save the day. This model has to stop now. And hopefully having smaller packages will help people to feel responsible for their modules. The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). ### Governance at the framework level At the framework level, the maintainer will be responsible for the quality of the code produced. In particular he'll have to make sure the different policies in place are respected inside his module: http://community.kde.org/Frameworks/Policies In practice that means that the day to day activities (and minimum required from a maintainer) will be to: * Review others' code; * Make sure that his module is always in a releasable state (in particular the CI is always green); * Decide on the direction his module is going in case of conflicts. Note that we're not expecting maintainers to have ideas on features or on a direction to give to the module (of course they can, it's just not required). That means it is fine to be more of the reactive type of maintainer if you want to, letting contributors propose directions and trying to move the lines, you just have to pick one in case of conflicting goals. ### Governance at the KDE Frameworks level Because of the structure of KDE Frameworks (which is already more than 50 modules and that number will likely increase again for 5.1), we also need to have a body that looks at the overall coherency of the whole. My goal here is not to create a huge bureaucracy, so we'll start as small as possible and grow if the need arises. To bootstrap this body, we'll reuse something as close to the status quo as possible. In our case that means that the KDE Frameworks Release Team will start with David Faure and myself. The responsibilities of that team will be the following: * Beating the drum on the product rhythms (mostly the release schedule, but also interim meetings); * Defining the content of the overall product; * Defining the rules of work. All of that in the usual KDE fashion, that is by collecting information from the trenches (that is the maintainers and contributors). IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... 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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 23:54:46 Kevin Ottens wrote: On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... If everything else fails (in other words, if we really want to have a name listed, but nobody else steps up), I am willing to maintain these frameworks: - kiconthemes - kimageformats (including webp plugin from kde-runtime) - kplotting - kwidgetsaddons I may also be interested in kconfigwidgets, kcmutils, kcompletion, and kguiaddons in the future (I don't know the code good enough yet). Christoph Feck (kdepepo)
