Re: Website migrations
Hello Ben, 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 ? -- Best Regards, Jasem Mutlaq 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 >>> >>> >>> >>> >>> >>>
Re: RFC: an improved ki18n_install
El dimarts, 7 de març de 2023, a les 9:21:07 (CET), Milian Wolff va escriure:
> On Dienstag, 7. März 2023 02:51:06 CET Aleix Pol wrote:
> > On Mon, Mar 6, 2023 at 8:31 PM Milian Wolff wrote:
> > > Hey all,
> > >
> > > for context please see [1] and [2].
> > >
> > > [1]: https://bugs.kde.org/show_bug.cgi?id=460245
> > > [2]:
> > > https://discourse.cmake.org/t/feature-request-add-custom-command-all/760
> > > 9
> > >
> > > The gist is that me and Igor are annoyed by `ki18n_install` abusing
> > > `add_custom_target`, which makes the build always dirty. I.e. every time
> > > we
> > > run `ninja` we will, at the very least, run the two mo & ts generation
> > > targets. For kdevelop, these do non-trivial amounts of work that takes
> > > time
> > > even on a beefy laptop:
> > >
> > > ```
> > > $ ninja && time ninja
> > > [2/2] Generating mo...
> > > [2/2] Generating mo...
> > >
> > > real0m1,780s
> > > user0m5,742s
> > > sys 0m2,327s
> > > ```
> > >
> > > I would like to fix this, but first want to get feedback from the KDE
> > > developers at large.
> > >
> > > First of all: Are all projects using ki18n_install in the way we do? Why
> > > is
> > > no-one else complaining about this so far? Are your po files so small
> > > that
> > > this doesn't take a significant amount of time? Or are there potentially
> > > just so few of them in your project? KDevelop is heavily plugin based
> > > which means we have tons of po files. 2464 *.po files to be exact...
> > >
> > > Secondly: does anyone know how to best approach a solution to this
> > > issue?
> > > The problem is that I don't see an easy way to solve it: While Kyle
> > > Edwards was nice enough to show me a way to tell CMake to not make the
> > > custom target always-dirty, `k18n_install` suffers from another design
> > > deficiency: It uses globbing internally and has an undefined amount of
> > > inputs and outputs, which basically makes it impossible for us to
> > > leverage `add_custom_command(OUTPUT` here, or?
> > >
> > > As such, it seems like one would need a different approach to this
> > > problem
> > > anyways. Globbing is a known-evil in cmake land, and I would personally
> > > prefer to have the inputs explicitly listed, just like we do for source
> > > files etc. Because we have many languages though, listing all possible
> > > *.po or *.ts files is cumbersome. Instead, what about we maintain the
> > > list of known languages in the ki18n framework? Then we could have
> > > something like
> > >
> > > ```
> > > ki18n_target(
> > >
> > > # the target for which we are handling messages
> > > TARGET KF5I18n
> > > # the translation domain, added as compile_options and to find files
> > > TRANSLATION_DOMAIN ki18n5
> > > # the root po folder location, to look for the .po/.js files
> > > PO_FOLDER ${KI18n_SOURCE_DIR}/po
> > >
> > > )
> > > ```
> > >
> > > Internally, this would do what is currently done manually:
> > >
> > > ```
> > > target_compile_options(KF5I18n PRIVATE -DTRANSLATION_DOMAIN=\"ki18n5\")
> > > ```
> > >
> > > Then it would iterate over the list of known languages and try to find
> > > the
> > > .po or .js file. For every match, we would add_custom_target to generate
> > > the corresponding .mo/.ts file and add the reverse dependency.
> > >
> > > What do others say to this approach?
> > >
> > > Thanks
> > >
> > > --
> > > Milian Wolff
> > > http://milianw.de
> >
> > +1 to getting the problem solved. I've also been bothered by this and
> > thought about looking into this so thanks for stepping up! (also I'm
> > pretty sure this code is originally mine from a time when we didn't
> > generate translations on every single build ^^').
> >
> > Having ninja/make do this dependency generation can end up being more
> > work than worth it because then we need to have a static list and then
> > we need to re-run it when the po files change and it's all a mess.
>
> The only mess that I can see is having to maintain the static list.
> Otherwise, we would just piggy back on the underlying buildsystem to drive
> the generation for us. Meaning, we would get separate targets for every
> .po/.js, leading to proper parallelization too. And only new/changed files
> would get re-generated as needed.
>
> Anyhow, reaping those benefits is going to be hard due to the static list.
> As Albert said in his email, my proposal has no advantages over just using
> glob. As such, we have basically three options:
>
> a) status quo:
> + trivial to setup
> + will always correctly track changes to the .po/.js files
> - serial instead of parallel generation of .mo/.ts files
> - always dirty ALL target
>
> b) glob with separate targets:
> + trivial to setup
> + parallelized generation of .mo/.ts files
> + clean ALL target
> - detecting new .po/.js files requires manual re-run of cmake (changes to
> existing .po/.js files will be detected automatically)
>
> c) static list:
> + parallelized generation of
Re: Website migrations
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 >> >> >> >> >> >>
Re: MR Gardening - A discussion, please leave your input!
KDiff3 is in a similar position to GCompris and would not at this benefit from auto closing or extra messaging on MR's Mar 6, 2023 3:29:12 PM Johnny Jazeix : > Hi, > > 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. > > In a general manner, as said by Carl, MR should not be closed automatically. > > Cheers, > > Johnny > > Le dim. 5 mars 2023 à 11:14, AnnoyingRains a écrit : >> For a short amount of time now, there have been some small-scale >> trials of replying to old MRs with a reminder, and suggesting that the >> author closes the MR if it is either no longer needed or if it needs >> more work and the author does not have time for it. >> >> This has appeared to have a positive impact on the state of KDE >> software from this (albeit limited) trial. Some MRs have had renewed >> interest, others have admitted that they had forgotten that the MR >> even existed. >> >> We did consider closing MRs if there was no activity after our ping >> message. **We are no longer planning on doing this**, as it is more >> destructive than helpful. All decisions on if a MR should be closed >> will be left with the maintainers and the person who opened the MR. >> >> So, we need a proper discussion about this, should we send these >> reminder messages at all? If so, how old should an MR be before >> sending this reminder? Should closing the MR even be suggested in the >> message? >> >> If your specific project does not play nicely with this programme, >> please let us know and we can add it to the list of exclusions on our >> KDE Community page. >> >> I need your input, >> - Kye Potter, KDE Gardening signature.asc Description: PGP signature
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. > > > 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. > > Hi, It will be considered as noise and ignored. We have two use cases: * Either the person is following and if a MR is stalling it's because maintainers don't have enough time to handle it now. * Either the person is no more following (for multiple reasons) and maintainers already know it and they plan to handle the MR later. In both cases, no action will be taken. As there are not a lot of MR (6), it's an amount we can handle it by ourselves. I think what you propose is more important and has more values when there a lot of MR opened and it's more complicated to handle them (or more maintainers).² Cheers, Johnny > > 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. > > > > What i forgot is what i did to be notified of it by email ^_^ > > > > Cheers, > > Albert > > > > > > > > Cheers, > > > Carl > > > > > > > > > --- Original Message --- > > > > > > Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains < > annoyingra...@gmail.com> > > a écrit : > > > > For a short amount of time now, there have been some small-scale > > > > trials of replying to old MRs with a reminder, and suggesting that > the > > > > author closes the MR if it is either no longer needed or if it needs > > > > more work and the author does not have time for it. >
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. > > > 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. > > Hi, It will be considered as noise and ignored. We have two use cases: * Either the person is following and if a MR is stalling it's because maintainers don't have enough time to handle it now. * Either the person is no more following (for multiple reasons) and maintainers already know it and they plan to handle the MR later. In both cases, no action will be taken. As there are not a lot of MR (6), it's an amount we can handle it by ourselves. I think what you propose is more important and has more values when there a lot of MR opened and it's more complicated to handle them (or more maintainers).² Cheers, Johnny > > 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. > > > > What i forgot is what i did to be notified of it by email ^_^ > > > > Cheers, > > Albert > > > > > > > > Cheers, > > > Carl > > > > > > > > > --- Original Message --- > > > > > > Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains < > annoyingra...@gmail.com> > > a écrit : > > > > For a short amount of time now, there have been some small-scale > > > > trials of replying to old MRs with a reminder, and suggesting that > the > > > > author closes the MR if it is either no longer needed or if it needs > > > > more work and the author does not have time for it. >
Re: RFC: an improved ki18n_install
On 2023-03-07 13:12, Friedrich W. H. Kossebau wrote: Am Dienstag, 7. März 2023, 02:51:06 CET schrieb Aleix Pol: Having ninja/make do this dependency generation can end up being more work than worth it because then we need to have a static list Such static list could be generated by scripty when it updates the po/ folder and stored there, no? Which then could be sourced by the ki18n_install cmake code in some way. That sounds like a good solution, one could just emit some CMake file to include that contains the call to the ki18n_install helper with the right args, then on the outside one would just need to add the po dir and be done. Greetings Christoph I'd urge to use the existing tools like make/ninja as much as possible instead of reimplementing their logic partially and maintaining a non-integrated sub buildsystem, with all the shortcomings and fails. Thanks for working on this in any case, the current state is far from ideal. -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Website migrations
Hello Ben, 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. -- Best Regards, Jasem Mutlaq 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 > > > > > >
Re: RFC: an improved ki18n_install
Am Dienstag, 7. März 2023, 02:51:06 CET schrieb Aleix Pol: > Having ninja/make do this dependency generation can end up being more > work than worth it because then we need to have a static list Such static list could be generated by scripty when it updates the po/ folder and stored there, no? Which then could be sourced by the ki18n_install cmake code in some way. I'd urge to use the existing tools like make/ninja as much as possible instead of reimplementing their logic partially and maintaining a non-integrated sub buildsystem, with all the shortcomings and fails. Thanks for working on this in any case, the current state is far from ideal. Cheers Friedrich
Re: MR Gardening - A discussion, please leave your input!
KDiff3 is in a similar position to GCompris and would not at this benefit from auto closing or extra messaging on MR's Mar 6, 2023 3:29:12 PM Johnny Jazeix : > Hi, > > 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. > > In a general manner, as said by Carl, MR should not be closed automatically. > > Cheers, > > Johnny > > Le dim. 5 mars 2023 à 11:14, AnnoyingRains a écrit : >> For a short amount of time now, there have been some small-scale >> trials of replying to old MRs with a reminder, and suggesting that the >> author closes the MR if it is either no longer needed or if it needs >> more work and the author does not have time for it. >> >> This has appeared to have a positive impact on the state of KDE >> software from this (albeit limited) trial. Some MRs have had renewed >> interest, others have admitted that they had forgotten that the MR >> even existed. >> >> We did consider closing MRs if there was no activity after our ping >> message. **We are no longer planning on doing this**, as it is more >> destructive than helpful. All decisions on if a MR should be closed >> will be left with the maintainers and the person who opened the MR. >> >> So, we need a proper discussion about this, should we send these >> reminder messages at all? If so, how old should an MR be before >> sending this reminder? Should closing the MR even be suggested in the >> message? >> >> If your specific project does not play nicely with this programme, >> please let us know and we can add it to the list of exclusions on our >> KDE Community page. >> >> I need your input, >> - Kye Potter, KDE Gardening signature.asc Description: PGP signature
Re: RFC: an improved ki18n_install
On Dienstag, 7. März 2023 02:51:06 CET Aleix Pol wrote:
> On Mon, Mar 6, 2023 at 8:31 PM Milian Wolff wrote:
> > Hey all,
> >
> > for context please see [1] and [2].
> >
> > [1]: https://bugs.kde.org/show_bug.cgi?id=460245
> > [2]:
> > https://discourse.cmake.org/t/feature-request-add-custom-command-all/7609
> >
> > The gist is that me and Igor are annoyed by `ki18n_install` abusing
> > `add_custom_target`, which makes the build always dirty. I.e. every time
> > we
> > run `ninja` we will, at the very least, run the two mo & ts generation
> > targets. For kdevelop, these do non-trivial amounts of work that takes
> > time
> > even on a beefy laptop:
> >
> > ```
> > $ ninja && time ninja
> > [2/2] Generating mo...
> > [2/2] Generating mo...
> >
> > real0m1,780s
> > user0m5,742s
> > sys 0m2,327s
> > ```
> >
> > I would like to fix this, but first want to get feedback from the KDE
> > developers at large.
> >
> > First of all: Are all projects using ki18n_install in the way we do? Why
> > is
> > no-one else complaining about this so far? Are your po files so small that
> > this doesn't take a significant amount of time? Or are there potentially
> > just so few of them in your project? KDevelop is heavily plugin based
> > which means we have tons of po files. 2464 *.po files to be exact...
> >
> > Secondly: does anyone know how to best approach a solution to this issue?
> > The problem is that I don't see an easy way to solve it: While Kyle
> > Edwards was nice enough to show me a way to tell CMake to not make the
> > custom target always-dirty, `k18n_install` suffers from another design
> > deficiency: It uses globbing internally and has an undefined amount of
> > inputs and outputs, which basically makes it impossible for us to
> > leverage `add_custom_command(OUTPUT` here, or?
> >
> > As such, it seems like one would need a different approach to this problem
> > anyways. Globbing is a known-evil in cmake land, and I would personally
> > prefer to have the inputs explicitly listed, just like we do for source
> > files etc. Because we have many languages though, listing all possible
> > *.po or *.ts files is cumbersome. Instead, what about we maintain the
> > list of known languages in the ki18n framework? Then we could have
> > something like
> >
> > ```
> > ki18n_target(
> >
> > # the target for which we are handling messages
> > TARGET KF5I18n
> > # the translation domain, added as compile_options and to find files
> > TRANSLATION_DOMAIN ki18n5
> > # the root po folder location, to look for the .po/.js files
> > PO_FOLDER ${KI18n_SOURCE_DIR}/po
> >
> > )
> > ```
> >
> > Internally, this would do what is currently done manually:
> >
> > ```
> > target_compile_options(KF5I18n PRIVATE -DTRANSLATION_DOMAIN=\"ki18n5\")
> > ```
> >
> > Then it would iterate over the list of known languages and try to find the
> > .po or .js file. For every match, we would add_custom_target to generate
> > the corresponding .mo/.ts file and add the reverse dependency.
> >
> > What do others say to this approach?
> >
> > Thanks
> >
> > --
> > Milian Wolff
> > http://milianw.de
>
> +1 to getting the problem solved. I've also been bothered by this and
> thought about looking into this so thanks for stepping up! (also I'm
> pretty sure this code is originally mine from a time when we didn't
> generate translations on every single build ^^').
>
> Having ninja/make do this dependency generation can end up being more
> work than worth it because then we need to have a static list and then
> we need to re-run it when the po files change and it's all a mess.
The only mess that I can see is having to maintain the static list. Otherwise,
we would just piggy back on the underlying buildsystem to drive the generation
for us. Meaning, we would get separate targets for every .po/.js, leading to
proper parallelization too. And only new/changed files would get re-generated
as needed.
Anyhow, reaping those benefits is going to be hard due to the static list. As
Albert said in his email, my proposal has no advantages over just using glob.
As such, we have basically three options:
a) status quo:
+ trivial to setup
+ will always correctly track changes to the .po/.js files
- serial instead of parallel generation of .mo/.ts files
- always dirty ALL target
b) glob with separate targets:
+ trivial to setup
+ parallelized generation of .mo/.ts files
+ clean ALL target
- detecting new .po/.js files requires manual re-run of cmake (changes to
existing .po/.js files will be detected automatically)
c) static list:
+ parallelized generation of .mo/.ts files
+ clean ALL target
- hard to setup, to maintain the static list
I think c) would only be an option paired with some scripting. I.e. ideally we
would let scripty maintain the static list for us when it syncs translations?
If we do that, then I think it would be the best solution. What do others
think?
> How
> about changing
Re: RFC: an improved ki18n_install
On Dienstag, 7. März 2023 00:30:20 CET Albert Astals Cid wrote:
> El dilluns, 6 de març de 2023, a les 20:31:01 (CET), Milian Wolff va
escriure:
> > Hey all,
> >
> > for context please see [1] and [2].
> >
> > [1]: https://bugs.kde.org/show_bug.cgi?id=460245
> > [2]:
> > https://discourse.cmake.org/t/feature-request-add-custom-command-all/7609
> >
> > The gist is that me and Igor are annoyed by `ki18n_install` abusing
> > `add_custom_target`, which makes the build always dirty. I.e. every time
> > we
> > run `ninja` we will, at the very least, run the two mo & ts generation
> > targets. For kdevelop, these do non-trivial amounts of work that takes
> > time
> > even on a beefy laptop:
> >
> > ```
> > $ ninja && time ninja
> > [2/2] Generating mo...
> > [2/2] Generating mo...
> >
> > real0m1,780s
> > user0m5,742s
> > sys 0m2,327s
> > ```
> >
> > I would like to fix this, but first want to get feedback from the KDE
> > developers at large.
> >
> > First of all: Are all projects using ki18n_install in the way we do? Why
> > is
> > no-one else complaining about this so far? Are your po files so small that
> > this doesn't take a significant amount of time? Or are there potentially
> > just so few of them in your project? KDevelop is heavily plugin based
> > which
> > means we have tons of po files. 2464 *.po files to be exact...
> >
> > Secondly: does anyone know how to best approach a solution to this issue?
> > The problem is that I don't see an easy way to solve it: While Kyle
> > Edwards
> > was nice enough to show me a way to tell CMake to not make the custom
> > target always-dirty, `k18n_install` suffers from another design
> > deficiency:
> > It uses globbing internally and has an undefined amount of inputs and
> > outputs, which basically makes it impossible for us to leverage
> > `add_custom_command(OUTPUT` here, or?
> >
> > As such, it seems like one would need a different approach to this problem
> > anyways. Globbing is a known-evil in cmake land, and I would personally
> > prefer to have the inputs explicitly listed, just like we do for source
> > files etc. Because we have many languages though, listing all possible
> > *.po
> > or *.ts files is cumbersome. Instead, what about we maintain the list of
> > known languages in the ki18n framework? Then we could have something like
> >
> > ```
> > ki18n_target(
> >
> > # the target for which we are handling messages
> > TARGET KF5I18n
> > # the translation domain, added as compile_options and to find files
> > TRANSLATION_DOMAIN ki18n5
> > # the root po folder location, to look for the .po/.js files
> > PO_FOLDER ${KI18n_SOURCE_DIR}/po
> >
> > )
> > ```
> >
> > Internally, this would do what is currently done manually:
> >
> > ```
> > target_compile_options(KF5I18n PRIVATE -DTRANSLATION_DOMAIN=\"ki18n5\")
> > ```
> >
> > Then it would iterate over the list of known languages and try to find the
> > .po or .js file. For every match, we would add_custom_target to generate
> > the corresponding .mo/.ts file and add the reverse dependency.
> >
> > What do others say to this approach?
>
> How is globbing (checking what is in the filesystem) different from the
> checking against a known list that will check against the filesystem if a
> file exists?
>
> Seems the same thing but with extra steps to me.
You are totally right, it really is the same thing now that I think about this
again. The fundamental issue is finding a solution where we know the list of
inputs/outputs without having to rerun cmake. This is not possible without a
predefined list of inputs, which is very cumbersome.
So that means we have to live with the always-dirty all target? That seems to
be very unfortunate for me, but I don't have a better solution either :(
Thankfully Aleix's patch should make the pain less pronounced at least
Thanks
--
Milian Wolff
http://milianw.de
