Re: [kde-community] Updating list of Applications offered by the KDE community -- time sensitive
On 7 December 2015 at 02:38, Aleix Pol wrote: > On Mon, Dec 7, 2015 at 3:19 AM, Valorie Zimmerman > wrote: > > Hello folks, Nicolas had the excellent idea to improve the > > Applications part of the front page of our site, https://www.kde.org. > > Many if not most of the screenshots are out-of-date, which gives an > > inaccurate view to the casual visitor about our applications. He wants > > to mentor GCi students to take screenshots of our current software > > instead. ... Also there's some tasks that could be done in bulk, like updating the > icons to the Breeze style, which is the one we default to now: > https://github.com/NitruxSA/breeze-icon-theme/tree/master/Breeze/apps/48 > > Likewise, taking new screenshots for any of the applications but using > Breeze's look and feel would also be helpful. > > Might I suggest this be linked to using the existing AppData metadata file and screenshot that should be in every app repo? That way it will also keep the app installers with updated screenshots too? They could check every app has an updated AppData file and screenshot, which is then pulled into the website to be used. Where there isn't a file they will need to approach the app maintainer to offer to help create one, which should also indicate which ones are alive or dead. 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
So there seems to be some rough consensus here? * That while not ideal, it is pragmatic to mirror our code on Github as it could increase visibility and may help attract new developers or at least new users for Frameworks. * That we should do it in a co-ordinated, consistent, automated, officially sanctioned way as part of our infrastructure before others do it in an informal, inconsistent sub-standard way that might even accidentally breach their manifesto undertakings. * That it should be a one-way mirror by default, with issues and pull requests disabled. * That individual apps can choose to 'accept' pull requests via Github, but any patches have to be applied through the normal KDE infrastructure(using a standard documented method?). * That individual apps can choose to opt out entirely. * That all repos mirrored must have a standard README.md file that states the correct procedure for submitting bugs and patches. * That we probably shouldn't 'bless' Github as the only place we mirror our code but could mirror more widely So, is there a volunteer to project manage this? I can see a lot of background work needs doing first to design a workflow and check everything will actually work automatically. They will need to talk with the sysadmins and research how Github/Gitlab/Bitbucket/whatever works, then come back here with a detailed proposal, then see it gets implemented correctly. Some points off the top of my head: * How do other orgs like Gnome and Apace do this? * Given the size of our code base, do we need to talk to Github first to see if that might cause issues, or if they can make the process easier? * What will our organisation name be? * Do we want a single organisation for KDE Community with several hundred repos directly under it, or separate orgs for the main products, KDE Frameworks, KDE Plasma and KDE Applications (possibly split into modules or apps?) Or is some kind of org hierarchy possible? * Who will the Org and App admins be on Github? Do we need dedicated people, or just leave it to the official app maintainers if they can be bothered? Or only require separate app level admins where they opt-in to accepting pull requests? * How do we link repos and orgs and their official KDE maintainers to Github users to ensure the right people are managing the repos? Standard SysAdmins ticket workflow? * What repos do we want to mirror? Some may not be appropriate to have mirrored, e.g www. * Can we script the mirror creation process in a generic way? * Can we automate the mirror creation and update process based on a metadata flag for repos opting in/out and where does that flag live? (useful to to allow a staged implementation or exclude repos like www) * What repos do we want to trial this with, say the 5 most popular Tier 1 Frameworks? * How do we automatically turn off issues and merge requests? * What is the preferred procedure for dealing with merge requests and can this be scripted? * What other sites to mirror to? Gitlab? Bitbucket? Which are big enough to worry about? Do they have mirror-only features? Can issue tracking and pull requests be easily disabled? * What needs to go in the README.md? * Should the README.md be specific for the mirror and only in that mirror copy, or a single global file in the main repo? * Can we script the README.md creation as part of the initial mirror creation process? * Can we generate the README.md from one of the repo metadata files? If so which one, do we need extra metadata fields, and should there also be an automatic update hook for when the metadata file is changed? * What happens when a repo already has a README.md? * What git hooks will be needed and who will write them? Do generic ones already exist for the chosen services? * What new documentation do we need and who will write it? * What PR do we need to do around this, in particular emphasising it is merely a mirror and not a migration? Phew :-) I'm sure there's a lot more besides. 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 18:42, Albert Astals Cid wrote: > I think kdesrc-build is a bit of an overkill for the "Build an app only using > packaged Qt and KF5" scenario. > > I find it easier to just clone, cmake and make than having to learn how to use > kdesrc-build. Yeap, still thinking around that, want to try write it both ways and see what is easiest. However if they then want to do a second and third app, and then maybe mess with Plasma and Frameworks, then they already have the skills. I'm just wary of the big mess the old docs developed into with 23 different ways to build things and various scripts to put in your .bashrc and envvars to be set depending on where things were and... Yeah, so I want to try keep it a single very simple, easy, clean, repeatable way of doing things if possible. Just checkout this one repo, run this one command with this config file and these flags, you're done. And if we can identify an even easier workflow with simpler commands that wraps around kdesrc-build then that is just as cool. 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 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 10:25, Luigi Toscano 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 17:57, Alex Merry 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 09:58, David Edmundson wrote: > We have one for Plasma here. > > https://community.kde.org/Plasma/Building > > I'm happy for this to become a redirect and unifying them all. Perfect, I'm stealing that :-) Things like the kdesrc-buildrc file could probably go in the kdesrc-build git repo I think, as possibly could the actual scripts to run Plasma or Apps. That way when stuff changes it's one place to update and people can receive it, rather than changing the wiki page and hoping people check back (hint: they won't!). 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 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 14:42, Jeremy Whiting 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
[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
So some random thoughts, and I'm still on the fence. We clearly have a problem with discoverability, partly due to our infrastructure issues, partly due to the new generation of 'open source' developers thinking the world revolves around Github (*). One of those things we have the power to fix, the other we don't. For the latter a Github mirror would seem to make sense, but it would need to be carefully managed (by who?). For the former the SysAdmins are working hard and I look forward to the results. If we can offer a Github-like experience (**) while keeping our independent infrastructure that is easy to use and discover and ranks top in google then brilliant. But we need to think about this in terms of the entire new developer experience, and we've been failing badly on that for a while. (*) Actually they're nor Free or Open Source devs, they're just devs looking for code to use or to share their code, and don't care what the licence is or philosophy... (**) How much of the issue is just the poor state of FOSS hosting solutions? We're software devs, can't we fix that? How will having multiple mirrors affect google rankings? Will there be a page full of repos for a confused dev to choose from? Where do we stop, just Github, Gitlab and Bitbucket? Or more? The last thing we want is for google to send people off to github as first choice. What can we do to improve our own search rankings? I know the php frontends are bad performers, can we give search engines a more direct route that can be easily linked back to the main frontend? I would note from reading the Gnome wiki on Github that you can't globally turn off pull requests for an organisation, you need to do it for each repo. It would also appear they manually deal with incoming requests to transfer patches over? Ouch. There's two separate groups we need to target here, devs who just want to use our code (Frameworks mostly) and maybe offer the occasional patch, and devs who want to get involved on KDE development. For the former, being easy to find and build is primary. For the latter, not so much as they'll be more motivated to jump through our dev experience hoops, but they still need to find us in the first place and a difficult experience drives too many away. (and no, that's not a good thing, making it hard to get in does not guarantee you only get get smart people, just the stubborn ones). So, a proposal for a trial. Given how tricky it is to build KDE stuff, and we're not sure what impact it will have on linking and google ranking, how about we conduct an experiment. Open a kde_community organisation and only mirror our Tier 1 Frameworks there, seeing as they just need Qt and cmake stuff and so are easy to build and are the thing we most want to share with outside devs. Or schoose a small stable subset of Frameworks. Disable issues and pull requests, add readme's pointing to TechBase for info on how to build and how to submit patches, then sit back and see what the results are in terms of google ranking and code submissions. Perhaps do the same for Gitlab and Bitbucket as well. (We should nab kdecommunity or kde_community on all the hosts asap, regardless of what we do!) Any volunteers, because to be blunt the SysAdmins have enough on their plate in sorting out our own infrastructure! Regardless, we really should work on our own new developer story, both in tooling and documentation. I've started on the docs, but we need to improve the tooling too to make it easier and more convenient. It's a competition we're loosing to other projects that have better new dev experiences. Think of it as a UX problem and lets get to solving it. 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 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] Fundraising
On 10 July 2014 11:10, Jos Poortvliet wrote: > So, let me be bold and give a suggestion (that isn't new at all [2]): > lets use our *software* to reach out to our users and tell them how they > could help us. > > Right now, we depend on users actively reaching out to us, to read planet > KDE, our dot and kde.org, to find out how to help. Let's make it easier. > Let's reach out to them. > > I'm not suggesting a irremovable flashing banner on the panel and pink fluffy > bunnies running over the window decoration, carrying signs "donate to KDE". > Perhaps unicorns. Certainly no bunnies ;-) > > No, goal is to INFORM our users that they could participate, help us, in > various ways. In a decent way. With the simple option to ignore us. > > And yes, there are some technical difficulties, and we'd have to work with > the distributions. I'm sure we can have a conversation about that - but I'd > like to know first: do we *want* this in the first place? Because if we > *want* it, I am certain we can *do* it. We're KDE ;-) Not unexpectedly, I do have a few ideas of varying degrees of evil-ness and unicorn-potential :-) As I mentioned in the thread you linked to we currently have a "donate" link in the "About KDE" dialog under the "Support KDE" tab where absolutely no-one will see it. We need to put any donate links or buttons in places where the users are more likely to see it in as part of their regular workflow. Annoying as it may have been, being confronted with Jimmy Wales' pleading face at the top of every Wikipedia page for a month was surprisingly effective :-) There's several places we could insert a Donate link or text, each with varying degrees of visibility and annoyance. We'll probably want to try more than one of them so we could probably have a small library or group of classes to provide a consistent interaction model, i.e. provide a KDonateButton and KDonateDialog for use in gui's, etc. We could make this configurable so independent apps can run their own fund-raising campaigns, and have a single config option to turn all marketing messages off. Having a generic "Donate" link or text will be less effective than having targeted text and images, for example for Randa or for new servers or Join the Game. People are more likely to donate if there is a clear target with tangible benefits. We could have a method where-by the donate code can check a server to see what the current campaigns are, perhaps using an rss feed or json file. Whenever an app starts it could trigger a delayed check of this. If they cannot connect then a generic text and image is used. Such an update method could also be used to trigger the more annoying notification methods on a low-volume schedule. Of course, these marketing messages we're pushing out don't have to all be of the "give us money" type, they could also be more generic "Attend Akademy", "Try Krita" , "Oppose Software Patents" or "Magical Unicorns" type messages. Where we do put donate links in the software, we need to make sure that each channel and campaign has a different link or parameter to identify it so we can track which campaign the money is intended for and which channels are the most effective. So where to put these marketing messages? The simplest would be to add a "Donate to KDE..." item in the Help menu which would pop-up the donate dialog, which would display the latest campaigns. This is quick and easy and highly unlikely to annoy users or distros or app authors, but would still be easy for them to turn off if it did. However, it doesn't put the new campaigns under the users immediate attention. We could insert messages into the KTipsDatabase so that the tips dialog randomly shows the latest campaigns. On the first-run of an app we could show the generic donate text, and when new campaigns are launched we can make that the next tip to be shown. Again, this is a fairly low-annoyance method that can easily be disabled, and increases visibility, but only if the user keeps showing tips at start-up. Boud has mentioned that Krita donations increased when he put a donate button in the splash screen. We could automatically place a button in all KSplashScreen instances, or even have the normal splash replaced with newly launched campaigns. Again, easily disabled if unwanted, and with guaranteed visibility, but not all apps use it, and the annoyance factor is higher. Somewhere that people regularly look at is the configure settings dialog. We could insert a default panel in every config dialog that gives some of the generic "About KDE" or "About App" style info, like where to get help on UserBase, etc, with the marketing messages included in the layout. This would have the potential for high user exposure, but also high user annoyance at seeing it when all they want is to configure something. In the more annoying category, there are many apps that could have marketing messages subtly displayed on start-up, the non-modal notifications i
[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 ): [Begins] The KDE Community produces 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 . [h1] Supported Platforms [h2] Linux and BSD KDE Workspaces and KDE Applications are available for most 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 . [h2] Windows Many KDE Applications are available for Windows XP, Windows Vista and Windows 7 using the . Some KDE Applications are also available as . The level of Windows support available may vary for individual applications. For more information visit the . [h2] Mac OS X Most KDE Applications are only available for Mac OS X by using the , , or package managers. These installation methods are not recommended for most users. Some KDE Applications are also available as . KDE hopes to provide more user-friendly installation methods in the future. For more information visit the . [h2] Source Packages All KDE Software is with the source code freely available for anyone to download, modify, build, and distribute in accordence with the terms of . You can obtain tarballs for any release from our . For more information on building KDE Software from source visit the . [h1] KDE Software [h2] KDE Applications The KDE Community develops a wide variety of 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 release is 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 release is 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 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 for more details. The latest for use with Qt4 is which was released on 10 June 2014. The latest for use with Qt5 is 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 http://www.kde.org/download/packagepolicy.php page has a level of detail that should be on TechBase instead, and its FAQ section strikes me as rather unprofessional in places and should be removed. The CDROM page at http://www.kde.org/download/cdrom.php page seems archaic and is empty so should either be deleted or replaced with a list of Live Distros running off USB or CD. A wiki page may be a better option for such a page? The Distr
Re: [kde-community] Basket?
On 8 July 2014 14:18, Ben Cooksley 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
Re: [kde-community] Basket?
On 8 July 2014 13:43, Ben Cooksley wrote: > Hi all, > > Sysadmin received a developer account request from Mariusz Wojcik > around 11 days ago, at which point the violation of the Manifesto was > uncovered. Gleb is aware of this issue, however we've yet to hear back > anything further from him on the matter. > > Thanks, > Ben Thanks Ben, one step ahead as always :-) Was the offer of migrating to KDE put to them when they were contacted? Would it be beneficial for the Incubator people to contact them to try discuss it? Cheers! John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Basket?
Hi, Does anyone what's up with Basket? We appear to be hosting an old website for it at http://basket.kde.org/, which links to an incomplete and inactive KDE4 port in a code repo on Github by Kelvie Wong [1] (who is noted as the maintainer on basket.kde.org), and a mailing list on SourceForge [2] which was tumbleweeds for years until an email last month reporting a new Qt4 based beta release on LaunchPad [3] by a Gleb Baryshev. There's also broken links to other non-KDE infrastructure. As far as I can tell it's now a fork of a fork? I'm not very comfortable with our hosting on kde.org a very out-of-date website for a project that isn't actually part of KDE anymore (if it ever was?). How do we want to play this? Do we approach the new devs to see if they wish to fully migrate to the KDE infrastructure as a KDE incubator project? Do we request that they move the website elsewhere if they don't want to? Or do we update the website ourselves to reflect it is not a KDE Community project any more? Cheers! John. [1] https://github.com/kelvie/basket [2] http://sourceforge.net/p/basket/mailman/basket-devel/ [3] https://launchpad.net/basket/kde4/2.10b ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Applications in KDE Generation 5
On 15 January 2014 22:15, Luigi Toscano 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
[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 ha
Re: [kde-community] KDE Dinner at FOSDEM?
On 3 January 2014 03:46, Aleix Pol wrote: > On Fri, Jan 3, 2014 at 1:19 AM, Albert Astals Cid 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
Re: [kde-community] We urgently need more tasks for Google Code-in
On 3 December 2013 18:09, Lydia Pintscher wrote: > Heya folks :) > > We currently have only 12 tasks left over for the students and over > 100 were already done. We should always have at least 30 open. I will > now add a few more tasks but please everyone think about what you'd > like some 13 to 17 year-olds to work on in KDE and propose task for > that. We're not limited to coding. Other areas can be worked on too. > If you have questions please come to #kde-soc on freenode. One idea I did have was to have them review the current Holiday data files to firstly check the existing files are up-to-date and secondly to create new files for countries that don't yet have them. Reviewing a file might take only 15 minutes if there's been no changes, or 30 minutes if there have been, so I'm not sure if that would be a good task, but creating a new file should take a good couple of hours to do the research, code the data file and submit the code. Interested? John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
