KDE Developer Documentation Support update
Greetings KDE Community! I'm Juan Carlos Torres (Jucato on IRC) and I've recently been hired as a contractor to get the ball rolling on updating our developer documentation. Over the years, our community has produced an incredible wealth of knowledge that now needs our attention and love. While the job description focuses on new contributors, improving the documentation can benefit even KDE veterans. I made a cursory survey of what I considered to be four important areas: 1. https://kde.org/develop - where most will probably start their search (if they didn't use Google) 2. https://api.kde.org/frameworks/index.html - the building blocks of all KDE software 3. https://techbase.kde.org/Development/Tutorials - where most of our tutorials still live 4. https://community.kde.org - various pages like https://community.kde.org/Get_Involved/development, or project-specific ones like https://community.kde.org/Plasma These present opportunities where we can make a significant impact just by updating tutorials or ensuring the apidocs meet the library documentation policy or having Project pages that contain information newcomers need to quickly become part of the team. This is something anyone and everyone can be involved in and I'm looking forward to making this journey with the community I've grown up with for 13 years now. Over the next few days, I will be knocking on some developers' and teams' doors to get your input and feedback on how we can work together towards this common goal. Let's make KDE rock not just for its software and for its community but also for having first-class developer documentation for new and old developers alike! -- Regards, Juan Carlos Torres Jucato
CI system maintainability
Hi all, We currently have a rather substantial issue, in that the CI system has been once again left in a position where it isn't possible to make any changes to the system. This means we can't update to newer versions of packages, add new packages or correct for binary incompatible changes which periodically get introduced to non-Frameworks. This issue has arisen because currently we have a recurring failure to build from source, within KDE PIM. Specifically, KContacts fails due to broken CMake logic. Despite this breakage having been in place for several days now, and the relevant mailing list being informed automatically by the CI system, the issue has not been corrected. While the most immediate fix is to correct this failure to build from source, that is only a short term fix and does not fix the underlying issue which makes the CI system difficult to maintain - and that is build failure reports being ignored, and people pushing broken code that doesn't even build. (For those wondering, the CI system uses OpenSUSE Tumbleweed, a rolling release distribution, for it's builds, so it isn't a case of old CMake or anything along those lines) We therefore need a long term fix for this. Note that pre-commit (as part of review) CI is not a solution in this instance, as the offending commits did not go through review. Does anyone have any ideas for a long term, proper fix to this? At this point given the amount of effort required to maintain a CI system vs. the amount of care actually being given by some developers (who are ignoring it's failure emails) it becomes questionable whether the effort is worth the return (and if not, we should just shut it down) Regards, Ben Cooksley KDE Sysadmin
Re: CI system maintainability
Il giorno Thu, 28 Mar 2019 19:40:09 +1300 Ben Cooksley ha scritto: > Does anyone have any ideas for a long term, proper fix to this? As I said on IRC, the current subjects for the CI are a little obscure especially if you do threading. It'd be better to have a prominent subject first, like "BUILD FAILURE", which immediately draws attention. Also, in openSUSE we have a bot that after a certain number of failed builds it will email the committer / maintainer directly informing them that the package has not been build successfully in a while. This might be useful to have in our CI here. -- Luca Beltrame GPG key ID: A29D259B pgpvYPwIgkWYv.pgp Description: Firma digitale OpenPGP
Re: CI system maintainability
On Чт, Mar 28, 2019 at 19:40, Ben Cooksley wrote: Hi all, We currently have a rather substantial issue, in that the CI system has been once again left in a position where it isn't possible to make any changes to the system. This means we can't update to newer versions of packages, add new packages or correct for binary incompatible changes which periodically get introduced to non-Frameworks. This issue has arisen because currently we have a recurring failure to build from source, within KDE PIM. Specifically, KContacts fails due to broken CMake logic. Despite this breakage having been in place for several days now, and the relevant mailing list being informed automatically by the CI system, the issue has not been corrected. While the most immediate fix is to correct this failure to build from source, that is only a short term fix and does not fix the underlying issue which makes the CI system difficult to maintain - and that is build failure reports being ignored, and people pushing broken code that doesn't even build. (For those wondering, the CI system uses OpenSUSE Tumbleweed, a rolling release distribution, for it's builds, so it isn't a case of old CMake or anything along those lines) We therefore need a long term fix for this. Note that pre-commit (as part of review) CI is not a solution in this instance, as the offending commits did not go through review. Does anyone have any ideas for a long term, proper fix to this? At this point given the amount of effort required to maintain a CI system vs. the amount of care actually being given by some developers (who are ignoring it's failure emails) it becomes questionable whether the effort is worth the return (and if not, we should just shut it down) Regards, Ben Cooksley KDE Sysadmin I don't know abut the current CI, but judging by recent discussion that is about KDE migrating to gitlab; quick search shows gitlab does allow prohibiting a merge if CI failed¹ Note however, in my experience of contributing to diffrent project CI often fails for reasons absolutely irrelevant to code being tested (e.g. errors in a CI script), in this case prohibiting a merge may worsen the situation. 1: https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds
