KDE Frameworks 5.94.0

[Ben Cooksley]

On Sat, May 21, 2022 at 8:38 PM Albert Astals Cid <aacid at kde.org> wrote:

> El dimarts, 17 de maig de 2022, a les 8:53:16 (CEST), Ben Cooksley va
> escriure:
> > On Tue, May 17, 2022 at 10:10 AM Albert Astals Cid <aacid at kde.org>
> wrote:
> >
> > > El dilluns, 16 de maig de 2022, a les 11:50:13 (CEST), Ben Cooksley va
> > > escriure:
> > > > On Mon, May 16, 2022 at 9:39 AM Albert Astals Cid <aacid at kde.org>
> wrote:
> > > >
> > > > > El diumenge, 15 de maig de 2022, a les 23:03:27 (CEST), David
> Faure va
> > > > > escriure:
> > > > > > On samedi 14 mai 2022 20:48:55 CEST Albert Astals Cid wrote:
> > > > > > > El diumenge, 8 de maig de 2022, a les 0:11:35 (CEST), David
> Faure
> > > va
> > > > > escriure:
> > > > > > > > On samedi 7 mai 2022 18:38:44 CEST Antonio Rojas wrote:
> > > > > > > > > El sábado, 7 de mayo de 2022 15:31:17 (CEST), David Faure
> > > escribió:
> > > > > > > > > > Dear packagers,
> > > > > > > > > >
> > > > > > > > > > KDE Frameworks 5.94.0 has been uploaded to the usual
> place.
> > > > > > > > > >
> > > > > > > > > > New frameworks: none this time.
> > > > > > > > >
> > > > > > > > > This should have been a reply to this mail of course
> > > > > > > > >
> > > > > > > > > >  tr tt ug uk and uz translations are missing from all
> > > tarballs.
> > > > > > > >
> > > > > > > > Thanks for noticing. My "update l10n" script did show an
> error
> > > about
> > > > > that
> > > > > > > > but I didn't see that error and moved on. I have now improved
> > > things
> > > > > so I
> > > > > > > > can't launch the next step if this step failed.
> > > > > > > >
> > > > > > > > I now uploaded new tarballs (also including
> > > > > > > > https://invent.kde.org/frameworks/
> > > > > plasma-framework/-/merge_requests/523)
> > > > > > > >
> > > > > > > > I hope it's all fine now, let me know otherwise.
> > > > > > >
> > > > > > > I've just realized that the packages dependencies have not been
> > > > > increased to
> > > > > > > 5.94 and they are just at 5.93. I guess that's not that bad,
> but
> > > just
> > > > > want
> > > > > > > to make sure that doesn't mean some other change may be also
> > > missing?
> > > > > >
> > > > > > Good catch. Fortunately nothing else should be missing. The
> reason
> > > this
> > > > > didn't happen is that I run
> > > > > >
> > > > > > cd ../src && ./kdesrc-build --src-only && cd ../release-tools &&
> > > > > ./list_frameworks.sh && ./update_l10n.sh &&
> > > > > ./increase_frameworks_version.sh step2
> > > > > >
> > > > > > and update_l10n failed because anonsvn threw me out in the
> middle of
> > > it.
> > > > > > I didn't notice, ran the next step (./make_rc_tag.sh) and this is
> > > how we
> > > > > got tags with missing languages.
> > > > > > Then I fixed l10n and tagged again, completely missing that
> > > > > "increase_frameworks_version.sh step2" was never done.
> > > > > >
> > > > > > Sigh, I wish svn.kde.org would work for the way we're using it
> at
> > > > > release time.
> > > > >
> > > > > One thing we may try is moving Frameworks to the "po injection"
> test
> > > group.
> > > > >
> > > > > "po injection" = scripty commits po files back to git
> > > > >
> > > > > Plasma Mobile Gear has been using it and as far as I understand it
> is
> > > > > working relatively well.
> > > > >
> > > > > Example:
> > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > > > >
> > > > > This way you can remove any special handling of l10n altogether
> from
> > > the
> > > > > KDE Frameworks release scripts
> > > > >
> > > >
> > > > Is there any particular reason why we can't rollout po injection to
> all
> > > > repositories?
> > >
> > > We need to adapt the release scripts not to fetch l10n, we also have
> > > various release scripts that inject ki18n_install/kdoctools_install
> when
> > > they do the fecth, so we need to properly add those calls to the root
> > > CMakeLists.txt
> >
> >
> > > Not a huge blocker, but it needs to be decided that we should do it and
> > > then do it.
> > >
> >
> > Given the number of benefits it has to release managers (no more tooling
> > needed to download translations and integrate them), as well as build
> > processes for nightly builds and for builds on developer systems I think
> > we've a fairly compelling reason to switch it on globally.
>
> I am not disagreeing and that's always been the plan, but someone needs to
> do the work for that to be possible :)
>
> I can only do so much, so help always welcome :)
>

What sort of work is required here?

My understanding is everything on the scripty/infrastructure side is in
place?


>
> Cheers,
>   Albert
>

Thanks,
Ben


>
> > It will also
> > ensure good CI coverage of the CMake files which should stop issues
> around
> > ki18n_install macros which have happened a few times.
> >
> > It'll also reduce the load on Leptone (the server for invent.kde.org and
> > svn.kde.org) at release time.
> >
> > Cheers,
> > Ben
> >
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > > >
> > > >
> > > > >
> > > > > Cheers,
> > > > >   Albert
> > > > >
> > > >
> > > > Cheers,
> > > > Ben
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > I have now added more error checking, including at the beginning
> of
> > > > > make_rc_tag.sh,
> > > > > > as well as a reminder to run "step2" after fixing the l10n
> problems.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20220521/01fdf073/attachment.htm>