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: MR Gardening - A discussion, please leave your input!
On donderdag 9 maart 2023 09:40:47 CET Méven wrote: > Maintainers' time is precious, requiring maintainers to follow up every > opened MRs in addition to the bugs and their own dev work is excessive. That is true, and it's why I have asked for Krita to be excluded from gardening. Every gardening action creates work, because I will need to check it and possibly do something about it. I don't have time for that. Halla
Re: RFC: KF (& other lib) consumers: want KFOO_VERSION macro definitions automagically available?
(cc:kde-core-devel only for heads-up, any reply please only to kde-devel)
Am Dienstag, 28. Februar 2023, 15:20:11 CET schrieb Friedrich W. H. Kossebau:
> TL;DR Would you fancy not having to always explicitly include a version
> header of a KFoo module to have the KFOO_VERSION variable available in your
> code? So is it worth it to add support for that on the KF side?
> (KF6-only, to keep your KF5 experience consistent)
>
> See for some discussion the description of
> https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/310
>
> Please voice your opinion on the use-case (not the implementation) either in
> that MR as comment or as reply in the ML.
>
> To adapt to the new use-case, two new feature variants of related ECM macros
> are currently up for consideration:
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/337
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/341
>
> Again curious which variant people might prefer in case they also work on
> public libraries, e.g. if there are other use-cases for the generic approach
> in 337 with the INCLUDE_FILES argument. Personally tend for 341 right now.
Thank you who took the time to give feedback so far :)
Seems having the *_VERSION macros implicitly available would be favoured by at
least some others than me, so I have continued work on the matter and locally
test-applied this to all KF6 modules and some other libraries.
Which as side-effect resulted already in some additions of missing version
header installations as well as include dir layout clean-ups with KF6 :)
Now some bits for those interested on the implementation side:
The current state of the proposed solution, using ECM MR 341
("ECMGenerateExportHeader: add USE_VERSION_HEADER arg (& related tune args)"),
requires for each library in ideal situations only this additional flag (by
example of KCoreAddons):
--- 8< ---
ecm_generate_export_header(KF6CoreAddons
+USE_VERSION_HEADER
)
--- 8< ---
And as result includes like "#include " will make all version
macros like "KCOREADDONS_VERSION" from kcoreaddons_version.h available without
further work.
For multi-library KF modules, where the module version header will then differ
in the base name from (most) library base names, an additional argument is
needed (by example of KIO's KIOCore):
--- 8< ---
ecm_generate_export_header(KF6KIOCore
+USE_VERSION_HEADER
+VERSION_BASE_NAME KIO
)
--- 8< ---
Additionally sometimes some adaption is needed in the internal buildsystem for
the version header to be seen during the internal build.
All in all this seems acceptable to me as overhead.
(though someone someday should deduplicate all the cmake code in all the KF
modules, so many patterns that shout "make me a central macro/function"...)
For non-KF libraries, which IMHO ideally also should support this developer
experience in the Qt6/KF6-based world, and which currently see to support both
Qt5 & Qt6 builds from the same branch and also cannot yet rely on latest ECM,
possible code is like this (by example of KDEGames):
--- 8< ---
+if (QT_MAJOR_VERSION STREQUAL "5")
+set(_generate_export_header_version_args)
+else()
+# For Qt6/KF6 world transitively include the version header
+if(ECM_VERSION VERSION_LESS "5.105")
+set(include_version_header_code "#include \n")
+set(_generate_export_header_version_args CUSTOM_CONTENT_FROM_VARIABLE
include_version_header_code)
+else()
+set(_generate_export_header_version_args USE_VERSION_HEADER)
+endif()
+endif()
ecm_generate_export_header(KF5KDEGames
+${_generate_export_header_version_args}
)
--- 8< ---
This is the path I will continue in related MR in the next days/weeks,
So if you want to participate please comment on ECM MR 341 & KCoreAddons MR
310.
(note to self: next time again use a phabricator task as central place for
tracking feature development discussion)
Cheers
Friedrich
PS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde-
devel or, better, on the MRs :)
Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
Hi, 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. It always seemed a bit illogical and possibly confusing to me to have e.g. KF5Cddb as CMake config file and KF5::Cddb as target name, because it's masquerading to be part of something (Frameworks), which isn't actually true. Especially since we market Frameworks as a common group of libraries, with common rules and policies, which may only be followed in part (or maybe not at all) by other projects. Changing that obviously involves some (temporary) compatibility concerns, but that doesn't play any role with the move to Qt6/KF6. So I suggest to use the chance and get rid of said prefix with the upcoming porting. One example where this was done already some time ago is libkgapi: https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888b7f924a49 Regards, Heiko
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
On Thursday, 9 March 2023 16:58:40 CET 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. > > It always seemed a bit illogical and possibly confusing to me to have e.g. > KF5Cddb as CMake config file and KF5::Cddb as target name, because it's > masquerading to be part of something (Frameworks), which isn't actually > true. > Especially since we market Frameworks as a common group of libraries, with > common rules and policies, which may only be followed in part (or maybe not > at all) by other projects. > > Changing that obviously involves some (temporary) compatibility concerns, > but that doesn't play any role with the move to Qt6/KF6. So I suggest to > use the chance and get rid of said prefix with the upcoming porting. > > One example where this was done already some time ago is libkgapi: > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888 > b7f924a49 ... and much more recently in a number of other PIM modules as well. My impression so far was that it's already largely consensus that using the KF prefix outside of Frameworks was a mistake we made in the early 5 days, and that should be corrected when the opportunity arises. There is one possible exception I can see for this, libraries with an imminent move to Frameworks. We have used the fact those were already using the KF prefix in several cases (e.g. KContact, KCalendarCore, KDAV) for a seamless switch from Gear to Frameworks. Many of the remaining users don't fall into that category though. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
On Donnerstag, 9. März 2023 16:58:40 CET 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. +1 > Changing that obviously involves some (temporary) compatibility concerns, > but that doesn't play any role with the move to Qt6/KF6. So I suggest to > use the chance and get rid of said prefix with the upcoming porting. > > One example where this was done already some time ago is libkgapi: > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888 > b7f924a49 This is a particular bad example because it changes the name of the Qt5 version breaking all existing Qt5-based users instead of just fixing the name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it doesn't hurt external users. But it has cost me many hours compiling libraries from source where I previously could always use the distribution packages). Please don't follow this annoying example. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
Am Donnerstag, 9. März 2023, 18:03:17 CET schrieb Ingo Klöcker: > On Donnerstag, 9. März 2023 16:58:40 CET 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. > > +1 +1 > > Changing that obviously involves some (temporary) compatibility concerns, > > but that doesn't play any role with the move to Qt6/KF6. So I suggest to > > use the chance and get rid of said prefix with the upcoming porting. > > > > One example where this was done already some time ago is libkgapi: > > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e248 > > 88 b7f924a49 > > This is a particular bad example because it changes the name of the Qt5 > version breaking all existing Qt5-based users instead of just fixing the > name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it > doesn't hurt external users. But it has cost me many hours compiling > libraries from source where I previously could always use the distribution > packages). Please don't follow this annoying example. +1 (as in, we should stick to what is proposed, use the 5->6 breakage to also funnel other nice-to-finally-do breakages into it) Did some related MRs now for libkmahjongg, for some other example: https://invent.kde.org/games/libkmahjongg/-/merge_requests/9 Adaption consumer side: https://invent.kde.org/games/kmahjongg/-/merge_requests/21 Cheers Friedrich
