Re: MR Gardening - A discussion, please leave your input!
On Freitag, 10. März 2023 20:55:00 CET Ben Cooksley wrote: > On Sat, Mar 11, 2023 at 3:19 AM David Hurka wrote: > > > On Thursday, March 9, 2023 9:40:47 AM CET Méven wrote: > > > We could use a "stale" label for MR to allow maintainers to see the > > > script's results. > > > And even a "closing-soon" label, for MR not-update in the last 12 months. > > > > Is there a rule that all open merge requests need care? > > I would expect that it is enough to label an open merge request as “stale”. > > > > Merge requests are usually closed because they are bad. > > Stale merge requests are probably good, otherwise they would have been > > closed > > intentionally. > > > > I recall in the last few months someone mentioning a MR in #kde-devel that > had been approved and just never merged, and had been sitting like that for > months. > All it took to get merged was a reminder by way of comment on the MR to get > it merged as the original author of the change was no longer around. > > So yes, there is definitely value in reminders and caring for those MRs. > > I guess the difference here is between higher activity projects - whose MRs > are likely to be more well looked after - and those with lower activity. > Projects with lower activity tend to involve developers who look after many > different projects, and will therefore benefit from reminders. Those with > higher activity are much less likely to see value from it. > > Closing of MRs though is something that should only be done after review by > the developers who run the project. Maybe in a semi-automated way such that the developer can mark the MR in a specific way and which closes it after a grace period when there is no more activity. -- Regards Thomas Baumgart - A champion is defined not by their wins but by how they can recover when they fall. (Serena Williams) - signature.asc Description: This is a digitally signed message part.
Re: Website migrations
On Wed, Mar 8, 2023 at 8:49 PM Jasem Mutlaq wrote: > Hello Ben, > Hi Jasem, > > https://edu.kde.org/kstars still points to > https://apps.kde.org/categories/education/kstars which is 404 pages. > Shouldn't it point to https://apps.kde.org/kstars ? > This has all since been resolved. > > -- > Best Regards, > Jasem Mutlaq > Regards, Ben > > > > On Tue, Mar 7, 2023 at 9:13 PM Ben Cooksley wrote: > >> On Wed, Mar 8, 2023 at 4:04 AM Jasem Mutlaq >> wrote: >> >>> Hello Ben, >>> >> >> Hi Jasem, >> >> >>> >>> We need a permanent redirect from https://edu.kde.org/kstars to the new >>> address. Now users are reporting that KStars is unreachable from search >>> engines. There are numerous sites that are linked to >>> https://edu.kde.org/kstars and you can't expect thousands of websites >>> to update their URLs. >>> >> >> As mentioned in #kde-sysadmin this is now in place. >> >> >>> >>> -- >>> Best Regards, >>> Jasem Mutlaq >>> >> >> Regards, >> Ben >> >> >>> >>> >>> >>> On Mon, Feb 27, 2023 at 1:33 PM Ben Cooksley wrote: >>> Hi all, This is just a heads up that I have now completed the vast majority of the remaining site migrations from the old server (Nicoda) to the new server (Tyran). The below domains should now be showing their updated contents: rewrite zones/calligra-suite.org.zone (98%) rewrite zones/calligra.org.zone (98%) rewrite zones/commit-digest.com.zone (96%) rewrite zones/commit-digest.org.zone (96%) rewrite zones/desktopsummit.org.zone (96%) rewrite zones/digikam.org.zone (98%) rewrite zones/falkon.org.zone (96%) rewrite zones/frameworks.org.zone (98%) rewrite zones/inqlude.org.zone (98%) rewrite zones/k3b.org.zone (96%) rewrite zones/kaddressbook.com.zone (98%) rewrite zones/kaddressbook.org.zone (98%) rewrite zones/kate-editor.org.zone (96%) rewrite zones/kde-china.org.zone (96%) rewrite zones/kde-edu.org.zone (98%) rewrite zones/kde.be.zone (96%) rewrite zones/kde.ca.zone (96%) rewrite zones/kde.eu.zone (96%) rewrite zones/kde.gr.jp.zone (96%) rewrite zones/kde.in.zone (96%) rewrite zones/kde.it.zone (96%) rewrite zones/kde.org.pl.zone (87%) rewrite zones/kde.ru.zone (64%) rewrite zones/kdeedu.org.zone (98%) rewrite zones/kdeitalia.it.zone (96%) rewrite zones/kdenews.org.zone (96%) rewrite zones/kdenlive.org.zone (98%) rewrite zones/kdepim.com.zone (96%) rewrite zones/kdepim.org.zone (96%) rewrite zones/kexi-project.org.zone (96%) rewrite zones/kirogi.org.zone (95%) rewrite zones/kmymoney.org.zone (96%) rewrite zones/koffice.org.zone (96%) rewrite zones/konqueror.com.zone (99%) rewrite zones/konqueror.org.zone (98%) rewrite zones/kontact.org.zone (96%) rewrite zones/korganizer.org.zone (96%) rewrite zones/kphotoalbum.org.zone (98%) rewrite zones/krusader.org.zone (96%) rewrite zones/kstuff.org.zone (98%) rewrite zones/openraster.org.zone (98%) rewrite zones/planetkde.org.zone (98%) rewrite zones/plasma-active.org.zone (96%) rewrite zones/plasma-bigscreen.org.zone (96%) rewrite zones/plasma-desktop.org.zone (96%) rewrite zones/plasma-mobile.org.zone (96%) rewrite zones/qtcon.org.zone (97%) rewrite zones/rolisteam.org.zone (98%) rewrite zones/skrooge.org.zone (98%) Of all of our sites, that leaves only the following left to migrate: - kpdf.kde.org - kst-plot.kde.org - umbrello.kde.org - edu.kde.org - docs.kde.org I will be looking into refreshing the static copies made previously of KPDF and KstPlot tomorrow, after which they will be transferred, and will then do the necessary testing for docs.kde.org as well. Unfortunately umbrello.kde.org has a hard dependency on Capacity and is built in such a way that it is incompatible with being made static. That site will therefore be removed from DNS and discontinued. Likewise, from my understanding with one exception the entire contents of edu.kde.org are being replaced by redirects to apps.kde.org, so that site will not be cutover. KStars developers: you need to urgently resolve the site migration issues for edu.kde.org as I understand you are the blocker there, as the old server will not be kept online to serve edu.kde.org alone. Thanks, Ben
KDE Gear 23.04 branches created
Make sure you commit anything you want to end up in the KDE Gear 23.04 releases to them The Feature Freeze and Beta is next week Thursday 16 of March. More interesting dates March 30: 23.04 RC (23.03.90) Tagging and Release April 13: 23.04 Tagging April 20: 23.04 Release https://community.kde.org/Schedules/KDE_Gear_23.04_Schedule Cheers, Albert
Re: MR Gardening - A discussion, please leave your input!
On Sat, Mar 11, 2023 at 3:19 AM David Hurka wrote: > On Thursday, March 9, 2023 9:40:47 AM CET Méven wrote: > > We could use a "stale" label for MR to allow maintainers to see the > > script's results. > > And even a "closing-soon" label, for MR not-update in the last 12 months. > > Is there a rule that all open merge requests need care? > I would expect that it is enough to label an open merge request as “stale”. > > Merge requests are usually closed because they are bad. > Stale merge requests are probably good, otherwise they would have been > closed > intentionally. > I recall in the last few months someone mentioning a MR in #kde-devel that had been approved and just never merged, and had been sitting like that for months. All it took to get merged was a reminder by way of comment on the MR to get it merged as the original author of the change was no longer around. So yes, there is definitely value in reminders and caring for those MRs. I guess the difference here is between higher activity projects - whose MRs are likely to be more well looked after - and those with lower activity. Projects with lower activity tend to involve developers who look after many different projects, and will therefore benefit from reminders. Those with higher activity are much less likely to see value from it. Closing of MRs though is something that should only be done after review by the developers who run the project. > > David > > > Regards, Ben
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
Am Freitag, 10. März 2023, 05:24:40 CET schrieb Kevin Kofler: > Heiko Becker wrote: > > while looking at a MR for libkcddb (part of Gear) I wondered if the > > transition from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 > > prefix in target names and CMake config files for libraries that aren't > > acutally part of Frameworks. > > Huh? This kind of transition is exactly where the prefix is most valuable, > because it ensures that you get a compatible version of the library, i.e., > that you do not accidentally get, e.g., a version of KF5Cddb when you are > looking for KF6Cddb. That logic though applied consequently, we should have named all libraries Qt5Foo and now Qt6Foo, so one really can be sure that the libs are compatible with the respective Qt version. But we did not do that for a reason. Because the prefix most importantly hints to a product group. And that one comes with certain properties, e.g. versioning or maintainers. --- 8< --- find_package(KF5 REQUIRED COMPONENTS I18n Cddb AkonadiContact KMahjongglib ) --- 8< --- works (and I have seen variants of that in real life), but it is just wrong, even more when using version numbers. A number in a library name usually is used to denote the major version of the library itself. In case of libraries extending/using the Qt toolkit, like our KDE products, many products share the API cycle of Qt, and thus also see to align the version numbers, at least the major one. But that is just by chance. A number of libraries for reasons have shorter API cycles. So cannot keep their major version number in sync with the supported Qt version. So the library number as clue for the used Qt version is not possible, instead other means might be needed. Especially in case the same library version can be built with multiple major Qt versions and co-installed. In that case postfixes with "qtX" usually have been used (not sure I fancy that postfix, just describing a fact). So, "KFx" as generic prefix to express the aspect "library from KDE using Qt x" will not work across the board sadly. Rather risks people to have wrong expectations about full versions and other product properties for a given library. Instead "KFx" should stay a product identifier for KF modules, and any accidental misuses healed when possible. Other product libraries names would still try to match the Qt version of course where feasible, but by other patterns. Cheers Friedrich
Re: MR Gardening - A discussion, please leave your input!
Le mar. 7 mars 2023 à 00:15, AnnoyingRains a écrit : > > We should never close a MR automatically. Only a maintainer of a project > or the author itself should close a MR. > > I agree with not closing MRs automatically. As I stated in my original > message, we are no longer planning on doing that, it's not helpful and > is only destructive. > The decision to close an MR will be left with the specific project's > maintainers and the person who opened the MR. > > I would argue we should allow some degree of automated closing. Maintainers' time is precious, requiring maintainers to follow up every opened MRs in addition to the bugs and their own dev work is excessive. Contributors should be warned and have a say, but when they don't react, what to do then ? That's something that happens for dolphin or Kio, cases I know. Plus the longer the stale guests the more bit-rot the code gets. Every MRs gets either merged given enough time, or abandoned by its author(s). We can't expect every contributor to finish their MR and especially months or years later. Some will, some won't. I guess projects could have different needs, but it seems to me a large auto-close threshold of 18 or 24 months or so would hardly do any harm. We could use a "stale" label for MR to allow maintainers to see the script's results. And even a "closing-soon" label, for MR not-update in the last 12 months. > > The decision if a MR should be closed or not is often depending on a > context (e.g. a MR required another MR to be merged first > > and it is taking more time than expected, the author is busy with other > things but will eventually come back to it, ...) > > and a script is unable to see this. > > I would also argue that humans that are not a maintainer of that > specific project should not close an MR for similar reasons. There is > a lot here that the gardening team would need to know about every > project > > > for GCompris, we don't have a lot of MR and even if some are old, we > still plan to take over them at some point (we know which ones are > unmaintained) so I think it's preferable to not add messages. > > We can exclude Gcompris if you feel it is needed, but I am unsure how > labeling MRs as stale and reminding authors wouldn't be preferable. > > > but this should probably be done manually > > We are planning on doing this manually until all of the issues have > been ironed out perfectly and we know a foolproof way to ensure > nothing is ever poked that shouldn't be, which may never happen. > We will open another discussion before automating anything, due to the > potential disaster a bug could cause. > > > "Hi, I really like this work, do you intent to continue working > > on it or can I take over" than a generic message that feels fake. > > This is great, but not exactly what this inititive is about. > This is more for reminding people that the MR exists (even had one > case of "oh! I forgot I made this MR" in my small scale test!), and > labeling MRs so that contributors feel more free to request taking > over the project. > Basically, we cannot really take over every stale MR in the entirety of > KDE. > > - Kye Potter, KDE Gardening > > > On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid wrote: > > > > El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va > escriure: > > > Hi, > > > > > > We should never close a MR automatically. Only a maintainer of a > project > > > or the author itself should close a MR. The decision if a MR should be > > > closed or not is often depending on a context (e.g. a MR required > another > > > MR to be merged first and it is taking more time than expected, the > > > author is busy with other things but will eventually come back to it, > ...) > > > and a script is unable to see this. > > > > > > I do not mind poking people semi-regularly (every 6 months or so), but > again > > > this should probably be done manually and with a small personalized > message > > > for example: "Hi, I really like this work, do you intent to continue > > > working on it or can I take over" than a generic message that feels > fake. > > > > > > I really hate communicating with robots instead of with humans and I > really > > > see the trends of trying to automatize all our interaction with dumb > robots > > > and chat bots in our society really worrying. > > > > > > If we want to automatize, we should instead try to list the stale MRs > and > > > maybe send the list to the mailing list once a month so that people are > > > reminded about them and take a look at which one they may be able to > unlock. > > > > We already have that, they get posted to > > https://invent.kde.org/teams/gardening/gitlab/-/issues > > weekly. > This listing is great, could we add a label "stale" to the MR concerned so that's explicit for maintainers. -- Méven
Re: kf6 vs. kf5 conflict report
On Freitag, 10. März 2023 09:41:04 CET Ben Cooksley wrote: > On Thu, Mar 9, 2023 at 4:56 AM Aleix Pol wrote: > > On Wed, Mar 8, 2023 at 3:13 PM Nicolas Fella wrote: > > > On 3/8/23 14:02, Harald Sitter wrote: > > > > with kf6 progressing nicely here's a first conflict report of files > > > > that appear in both kf6 and kf5 under the same name. this largely > > > > affects translations and docs it seems. this list may not be entirely > > > > comprehensive, I've only thrown together a script in a couple minutes. > > > > > > Thanks Harald! > > > > > > > one question is whether ECM should be co-installable, not sure if that > > > > has been discussed > > > > > > It has come up, and the answer seems to be "No, it will not be > > > coinstallable". This implies that ECM master will continue to support > > > Qt5/KF5, but that should not be a huge burden. > > From my perspective this has been incredibly poorly communicated to the > point that it is not an actual valid decision. This isn't really a new decision, this goes back to ECM's original design in early KF5 times, and is due to ECM being largely independent of any major Qt version. It therefore never had a major version in its install path. > It is also not what was set in the branch-rules.yml files within the > metadata (which was committed by a Frameworks devel) and was not what was > confirmed by Frameworks developers when I put together the list of projects > to have KF5 master branch builds removed from the CI artifacts store. > > This state of affairs has been the source of a degree of CI breakage we > have been experiencing (things are a mess at the moment, I don't even want > to look at any of it) ECM having a kf5 branch was done precisely to avoid having to special-case it even more in the CI setup and the release automation. Yes this is messy, but the alternative was assumed to be even worse. Regards, Volker > > > > report for /usr: > > > > https://collaborate.kde.org/s/3gz2KfoGLsS4TF5 > > > > > > > > furthermore the following files outside /usr clash between kf6 and 5: > > > > '/etc/xdg/accept-languages.codes' > > > > '/etc/xdg/kshorturifilterrc' > > > > '/etc/xdg/autostart/baloo_file.desktop' > > > > '/lib/udev/rules.d/61-kde-bluetooth-rfkill.rules' > > > > > > > > HS > > > > If ECM master has to support KF5, why do we have a kf5 branch? In > > fact, I'm pretty sure I switched it eventually because there were > > regressions. > > > > Aleix > > Regards, > Ben signature.asc Description: This is a digitally signed message part.
Re: MR Gardening - A discussion, please leave your input!
On Thursday, March 9, 2023 9:40:47 AM CET Méven wrote: > We could use a "stale" label for MR to allow maintainers to see the > script's results. > And even a "closing-soon" label, for MR not-update in the last 12 months. Is there a rule that all open merge requests need care? I would expect that it is enough to label an open merge request as “stale”. Merge requests are usually closed because they are bad. Stale merge requests are probably good, otherwise they would have been closed intentionally. David
Re: kf6 vs. kf5 conflict report
On Thu, Mar 9, 2023 at 4:56 AM Aleix Pol wrote: > On Wed, Mar 8, 2023 at 3:13 PM Nicolas Fella wrote: > > > > On 3/8/23 14:02, Harald Sitter wrote: > > > with kf6 progressing nicely here's a first conflict report of files > > > that appear in both kf6 and kf5 under the same name. this largely > > > affects translations and docs it seems. this list may not be entirely > > > comprehensive, I've only thrown together a script in a couple minutes. > > > > Thanks Harald! > > > > > one question is whether ECM should be co-installable, not sure if that > > > has been discussed > > > > It has come up, and the answer seems to be "No, it will not be > > coinstallable". This implies that ECM master will continue to support > > Qt5/KF5, but that should not be a huge burden. > >From my perspective this has been incredibly poorly communicated to the point that it is not an actual valid decision. It is also not what was set in the branch-rules.yml files within the metadata (which was committed by a Frameworks devel) and was not what was confirmed by Frameworks developers when I put together the list of projects to have KF5 master branch builds removed from the CI artifacts store. This state of affairs has been the source of a degree of CI breakage we have been experiencing (things are a mess at the moment, I don't even want to look at any of it) > > > > > report for /usr: > > > https://collaborate.kde.org/s/3gz2KfoGLsS4TF5 > > > > > > furthermore the following files outside /usr clash between kf6 and 5: > > > '/etc/xdg/accept-languages.codes' > > > '/etc/xdg/kshorturifilterrc' > > > '/etc/xdg/autostart/baloo_file.desktop' > > > '/lib/udev/rules.d/61-kde-bluetooth-rfkill.rules' > > > > > > HS > > If ECM master has to support KF5, why do we have a kf5 branch? In > fact, I'm pretty sure I switched it eventually because there were > regressions. > > Aleix > Regards, Ben
