[kde-community] Updating TechBase Getting_Started pages
Hi, I've started to update the old TechBase Getting_Started pages for the new KF5 world [1]. My aim is to teach the one simplest quickest way to build KF5 for new KDE contributors. There's a few key concepts I want this rewrite to follow: 1) There is only one way to do things, no giving alternatives 2) There is only KF5, no KDE4 3) There is only kdesrc-build, no manual messing around The three build scenarios (= new dev personas) that will be presented will be: 1) Build an app only using packaged Qt and KF5 2) Build Plasma only using packaged Qt and KF5 3) Build Frameworks using packaged Qt All the more detailed or historic information will be removed to other parts of TechBase [2]. New build instructions for external devs just wanting to use a Framework or two should also go here and not Getting_Started. This may result in some default build configs needing to be added to the kdesrc-build repo to make life easier. There may also need to be a couple of simple scripts to set-up kdesrc-build to start with, and to actually run things seeing as kdesrc-build doesn't. The less the new dev has to worry about the better. Thoughts? Is anyone else working on something similar? John. [1] https://techbase.kde.org/KF5/Getting_Started [2] Probably https://techbase.kde.org/Development/Build? ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 17 August 2015 at 14:42, Jeremy Whiting jpwhit...@kde.org wrote: Boud, That page is generated by the contents of https://websvn.kde.org/trunk/www/sites/www/applications/apps/krita.json?view=log and the image file relative to it and such. If you don't have svn karma to update it feel free to send me a patch or new icon and I can do that for you (or ask sysadmin for karma if you rather). Interesting. Shouldn't we be auto-generating that json from the appdata file in each repo? I think I suggested such a thing a while back... John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Updating TechBase Getting_Started pages
On 17 August 2015 at 10:56, Alex Merry alex.me...@kde.org wrote: At some point we will need to address this extra info as well - there's no point leaving a jumbled mess around. Yes, there lots of more advanced scenarios that we need to provide docs for. There's also a serious need for people to review all of TechBase for KF5 and Git, for example the Application Lifecycle page still refers to SVN! If anyone has time to spare, jump in. I'm wondering though if we shouldn't try organise a week where *everyone* stops coding and writes or cleans-up some docs instead? I think we want a brief next steps at the end of the build instructions - hey, you did the thing, look here for what to do next. The obvious next step is to submit a patch (either claiming a junior job on b.k.o, say, or some pet issue the person already wants to solve). Yeap, linking to Contribute is appropriate here. Most of the stuff is still very draft, but it has had all the unnecessary guff chainsawed out, so now I'm shuffling things around trying to get the right flow before fleshing out the details. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Updating TechBase Getting_Started pages
On 17 August 2015 at 17:57, Alex Merry alex.me...@kde.org wrote: The general equivalent of this page is https://community.kde.org/Get_Involved - it gives an overview of the areas you can get involved in, and links to pages with more detail about how to get involved in that way. I think it makes a nice jumping-off point, and is good for emphasising that writing code is far from the be-all-and-end-all of KDE. It's very much a community involvement page, though, and techbase needs an equivalent whose selection is more along the lines of I want to write code / I want to use the Frameworks in my own project / I want to deploy KDE software to 20 000 computers. The how to build our software is just one part of that. Co-ordinating the development track on the community wiki and the build / send in patches track on the techbase wiki is going to take some thought, though. You mean like https://techbase.kde.org/Contribute? :-) It may help to have standard names for these sorts of matching pages. But yes, ideally we would have an overall design to follow, complete with personas for target audience, then lock down the pages so no-one can dilute the message (while leaving it open enough to edit as things change!). John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Updating TechBase Getting_Started pages
On 17 August 2015 at 10:25, Luigi Toscano luigi.tosc...@tiscali.it wrote: Is it really s/removed/moved/, right? We already have name-spaced historical information around (for example https://techbase.kde.org/Development/Architecture/KDE4 ) so I guess it would be just an addition to them. Yes, one of the joys of the ambiguity/redundancy built into English, here 'removed to' is the same as 'moved to' :-) Yes, was thinking of moving the https://techbase.kde.org/Getting_Started/Build/Historic page (instructions since 2.2.2!) to Development/Build/Historic and adding all the KDE4 stuff to it, leaving the top level Development/Build page to the detailed yet-to-be-written KF5 stuff. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Updating TechBase Getting_Started pages
On 17 August 2015 at 10:56, Alex Merry alex.me...@kde.org wrote: At some point we will need to address this extra info as well - there's no point leaving a jumbled mess around. Yes, there lots of more advanced scenarios that we need to provide docs for. There's also a serious need for people to review all of TechBase for KF5 and Git, for example the Application Lifecycle page still refers to SVN! If anyone has time to spare, jump in. I'm wondering though if we shouldn't try organise a week where *everyone* stops coding and writes or cleans-up some docs instead? I think we want a brief next steps at the end of the build instructions - hey, you did the thing, look here for what to do next. The obvious next step is to submit a patch (either claiming a junior job on b.k.o, say, or some pet issue the person already wants to solve). Yeap, linking to Contribute is appropriate here. Most of the stuff is still very draft, but it has had all the unnecessary guff chainsawed out, so now I'm shuffling things around trying to get the right flow before fleshing out the details. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 17 August 2015 at 07:54, Jos Poortvliet jospoortvl...@gmail.com wrote: I'd say the main benefit of Github is that it makes it easy for the many developers used to it to do a pull request - effectively widening our potential contributor base. Some might send in one or two minor pull requests, not being interested in becoming regular contributors, others might be convinced, after a few patches, to join KDE and then get on our infrastructure. Why make people first join a mailing list and/or go through other hoops before we allow them to help make KDE better? Of course, you can leave it up to individual sub projects if they're interested in more contributions or not. I'll address this separately while I decide if the main topic is a good thing or not. Given how hard it is to just build a KDE app or Framework, and the efforts potential contributors have to go to just to get a working build, then I think making them go through the normal submission channels is the least of our worries. If they were by some miracle able to build something and create a patch, then it's really not much harder to create and upload a patch to Bugzilla or Reviewboard (we could script it). I'm hoping Phabricator solves this by allowing a push like Gerrit does? is so then even easier then... We need to solve the build problem first. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] FOSDEM Organisation
Hi, Just a heads-up that I will not be attending FOSDEM next year and will not be assisting in any way with preparations for FOSDEM or providing any hardware. This is the result of the FOSDEM organisers refusing to institute a proper Code of Conduct for attendees or to take any other steps in addressing the dreadful gender ratio of speakers on their program or attending the conference itself. I have attempted to discuss these issues with them and found their attitude and beliefs completely unacceptable to me. As such I cannot give them any form of support, and sadly that means not helping the KDE community at this event anymore. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Basket?
On 8 July 2014 14:18, Ben Cooksley bcooks...@kde.org wrote: The initial developer request also included a request for a repository on KDE infrastructure. I queried whether they had the support of the maintainer - Gleb - to which they said they would ask. Gleb subsequently informed this person he'd prefer for it to remain on Github. Upon being informed of this, I pointed out the Manifesto to them - which they said they would consider. I've yet to hear anything further. Thanks again, sounds perfectly handled. Sad if they choose to not join, but we can't force them, although they may not yet appreciate the full benefits of joining. Let us know the outcome, I guess you've set a time-out for a few weeks? Cheers! John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Proposal to change to kde.org/download text
Hi, [Posting to community rather than www or promo as it covers all 3 areas and this seems the best place for bike-shedding without spam cross-posting.] I spent a couple of hours on the weekend trying to walk someone through installing KDE on Windows. While there were several issues with the KDE Windows Installer, an initial problem came with just finding the installer. We started at http://www.kde.org/ and clicked on the prominent Get KDE Software which led to http://www.kde.org/download/ which is where we hit a solid wall of text over more than one page. Eventually we found the link at the bottom that took us to http://windows.kde.org/, and finally to http://windows.kde.org/download.php. That's 4 clicks and a lot of text to get through when we already knew what we wanted. The Download page seems to want to explain what KDE is before letting you download stuff, but most people going to that page will have decided they already want to try it and so we should just give them the info they need most. We can explain KDE elsewhere. We also need to use terminology that new users will understand, which means leaving out unnecesary and confusing details. I'd like to propose the following text instead (links marked as text): [Begins] The KDE Community produces Free Software that can to be used on a number of operating systems. This page details how to obtain KDE Software on each of those platforms, but for best results we recommend you run KDE Applications under KDE Plasma Workspace on Linux or BSD. To obtain support for using KDE Software please visit the KDE UserBase. [h1] Supported Platforms [h2] Linux and BSD KDE Workspaces and KDE Applications are available for most Linux and BSD distributions by using the distribution's software manager. For more information please consult your distribution documentation or user support forums. You can try out KDE Software on Linux without changing anything on your computer by using a Linux Live CD or USB stick. [h2] Windows Many KDE Applications are available for Windows XP, Windows Vista and Windows 7 using the KDE Windows Installer. Some KDE Applications are also available as individual downloads. The level of Windows support available may vary for individual applications. For more information visit the KDE on Windows home page. [h2] Mac OS X Most KDE Applications are only available for Mac OS X by using the MacPorts, Fink, or HomeBrew package managers. These installation methods are not recommended for most users. Some KDE Applications are also available as individual downloads. KDE hopes to provide more user-friendly installation methods in the future. For more information visit the KDE on Mac home page. [h2] Source Packages All KDE Software is Free Software with the source code freely available for anyone to download, modify, build, and distribute in accordence with the terms of our licences. You can obtain tarballs for any release from our download servers. For more information on building KDE Software from source visit the KDE TechBase. [h1] KDE Software [h2] KDE Applications The KDE Community develops a wide variety of applications which can run under any supported operating system or desktop environment. These may be released as part of the regularly scheduled KDE Applications releases, or may be released independently. The latest KDE Applications release is version 4.13.2 which was released on 10 June 2014. [h2] KDE Plasma Workspaces The KDE Community develops Desktop, Netbook and Tablet workspaces for use on Linux and BSD systems. The latest KDE Plasma Workspaces release is version 4.11 which was released on 14 August 2013. This is a Long Term Support (LTS) release that will be supported with bug-fixes until after the release of Plasma 5. The most recent LTS bug-fix release is version 4.11.10 which was released on 10 June 2014. [Add at Plasma 5] The Plasma 5.0 desktop was released on 7 July 2014. While this is a stable release, it is not yet recommended for general use. [h2] KDE Development Libraries The KDE Community develops many libraries and tools for software developers which are used to build the KDE Applications and KDE Workspaces. Other developers are free to use these for their own applications under the terms of our licences. See the KDE TechBase for more details. The latest KDE Development Platform for use with Qt4 is version 4.13.2 which was released on 10 June 2014. The latest KDE Frameworks for use with Qt5 is version 5.0.0 which was released on 7 July 2014. [Ends] This may still need editing down, as the intent should be to fit on a single page, or at least the platform download links section should. The Windows and Mac details may be better placed on a separate wiki pages where we can easily change the list of installers, but that increases the number of clicks required. The alternative is listing them all on this page (mostly Krita, Marble, Digikam?). The Package Policy page at
[kde-community] Applications in KDE Generation 5
Hi, It's time we talked about Applications. With the Frameworks and Plasma Tech Previews out the door we have applications starting to port to the hot new stuff, and we need to start discussing now how all the decisions being made around Frameworks and Plasma (such as the new Plasma naming scheme) will impact our Applications. What does it mean to be a KDE Application? How will we organise their development and release? How will we describe and promote them? The reason I'm raising this on the Community list rather than the Devel or Release or Promo lists is this really is a discussion about how we organise our community. I've talked about this with a few people at KDE events over the last year, and there seems a rough consensus that our current module organisation and the SC concept no longer reflects the way our community works both socially and technically, and so needs an overhaul to better reflect how we actually work today and to present our users a more compelling and co-ordinated vision for the future. At the core of everything are the modules. These are partially an artefact of our use of SVN to organise groups of people with similar interests to attack app domains that needed FOSS solutions. They usually revolved around a community mailing list and bugzilla category. Some modules were created simply because we had to have an SVN repo for code to go into. If we look at the modules now, while some are still thriving active communities with well-maintained apps, others are moribund or effectively dead with their apps slowly bit-rotting from lack of attention (and a lack of visibility to the wider community that this is an issue). Some hover somewhere between the two. This might not be so bad if the bit-rotting apps weren't also a part of the SC where they give users a poor impression of KDE Applications, as well as contributing to the sense of 'bloat' when people go to install a full KDE desktop experience and get a million-and-one small and mostly useless utilities. Some of these apps hardly seem relevant to a modern end-user experience, or integrate poorly with our modern workspace. We can do better than this. With all the work around KF5, Plasma 2, the separate git repos, and possible separate release cycles for Frameworks, Workspaces and Applications we have a chance to do a through review on the state of the modules and apps to ensure that our next major release is one that meets both the needs of our developer community and the needs of our users, today and for the next 5 years. What does a modern desktop/tablet/mobile *really* need? What is essential for a workspace, and what are just extras? How do we organise this all? And what the heck do we call it? The main points I think most people I talked to agreed on were: * A number of our apps and utilities really have had their day and need retiring, e.g. KsCD, Kppp, KFloppy. There's no point keeping low-quality or unmaintained apps around just to try ship a complete desktop experience, especially if there are other better apps out there (even if not KDE ones). Being part of the official release should be a stamp of quality: make apps work for it. Lets go through the existing apps and agree what needs dropping to Extragear or Unmaintained. * There are a lot of high-quality utils, apps and libraries in Extragear that better deserve to be in the main release, lets go through them and see what deserves to be promoted. Things like the NetworkManager plasmoid, Ktp, and KScreen are already on the list to move, but what else is there? Lets have a look and talk to their maintainers. * Can we have a clearer split between Workspace and Application? Perhaps it's time we moved Workspace essential tools like KMix from being the responsibility of a module to being part of Workspaces? (i.e. don't move the NetworkManager plasmoid from Extragear into the Network module, move it to Workspaces). This ensures the Workspaces community have better visibility and control of they things they really need, especially if they split release cycles. * Do we need small utilities like KCalc as stand-alone apps, or do they belong in Workspaces, perhaps as Plasmoids? Where do we draw the line between them? And if there's both a Plasmoid and an App for something, which goes in the main release? * Application domain-specific libraries such as libkipi or libkcddb may now be better organised under Frameworks rather than their modules, where they could gain a wider user base and a clearer maintenance viability. Can we have a Frameworks category for non-api stable libraries? * We have things like thumbnailers, kio slaves, dolphin plugins and strigi analyzers under each module, would these be better organised into meta-groups in Extragear so they're easier to find? * Can we create a proper KDE SDK? We have the SDK module which is really a mix of general development related apps and KDE-specific dev tools, and we have Examples, and we have a few
Re: [kde-community] Applications in KDE Generation 5
On 15 January 2014 22:15, Luigi Toscano luigi.tosc...@tiscali.it wrote: John Layt wrote: One other thing I would do is change our app lifecycle slightly. I'd introduce a new status of Deprecated that lies between Released and Unmaintained, for apps like Kopete and KPPP that are no longer relevant for most people or are being replaced, but may still have limited use and so need to be kept alive for a while. I'd envision a new lifecycle metadata attribute that looks something like Experimental - Incubator - Stable - Deprecated - Unmaintained, with only Stable apps eligible to be included in the regular Applications release cycle. Just my 2 cents here: I would be careful with this kind of lifecycle. An application with low activity (almost unmaintained) can be still stable for a long time, given our committment to binary compatibility. This is true especially for small applications, but it is something that should be considered. Yes, stable would have a fairly wide definition, but that's deliberate so it does include things like KCalc that really don't change much and don't need much work done to them. Perhaps an extra proviso of actively maintained would be needed to be included in the regular release cycle, where active means a named person as maintainer who triages any bugs. Also, I would be careful to use the word deprecated for applications like Kopete, where Ktp has not covered all the functionalities (yet); also Kopete receives changes/fixes. This is for the 4.x world, at least (if Kopete is not ported to 5 the problem is solved, but otherwise the problem still holds). Yeap, the terminology comes from me being a libraries person, deprecated api for us means still working and supported, we just think there's a better option so we won't put much effort into improving it. If there's a better word to use for normal people then that would be fine :-) One benefit from looking at the apps in this way will be to decide what does and doesn't get ported, labelling something as unmaintained says don't bother, deprecated would be port only if you really need it and don't make too much effort modernising it (use kde4support). Of course, if someone really wants to keep Kopete going they're welcome to do the work required and to take on maintainer status, and that would qualify for regular release status, but achieving that extra level of being included in Essentials would require wider community support, and I see that position in the future belonging to Ktp. That's really what this email is about, getting those sorts of conversations going about specific apps so we know where to start once KF5 goes final. Cheers! John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE Dinner at FOSDEM?
On 3 January 2014 03:46, Aleix Pol aleix...@kde.org wrote: On Fri, Jan 3, 2014 at 1:19 AM, Albert Astals Cid aa...@kde.org wrote: Hi there, I know lots of us KDE heads will be at FOSDEM so I was wondering if people is interested in an official KDE Dinner for saturday. If you're interested, do you have suggestions for the restaurant? It sounds like a good idea, we've done that before. The biggest problem I guess is that we'll end up being ~15 people and it's not easy to allocate that much people. Also, I'm clueless about restaurants :). Two lessons learned from previous times: organise place and time in advance so everyone knows where to go, and don't make the time too early as people take ages to leave FOSDEM and get into the city. If someone local(ish) can find/remember a decent restaurant and book it would be best. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
