[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: AppStream Metadata with our releases
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2024-03-26 22:55:46
Message-ID: CA+XidOFk_Cz9eocm+5OQaYw_tbib=xBP=hdd84yTogayJVaKcw () mail ! gmail ! com
[Download RAW message or body]
On Wed, Mar 27, 2024 at 5:40 AM Volker Krause <vkrause@kde.org> wrote:
> On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote:
> > On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote:
> > > El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va
> > >
> > > escriure:
> > >> 22.03.2024 17:22:33 Albert Astals Cid <aacid@kde.org>: ...
> > >
> > > It is some extra work (not a lot, but some).
> > >
> > > You're asking for the workflow of creating to be releases to be
> changed by
> > > creating the entry in the file earlier, that alone is a bit of work,
> but
> > > it
> > >
> > > has several other consequences:
> > > * https://apps.kde.org/okular/ shows releases from the appstream
> file (i
> > >
> > > think) meaning that the code should learn to ignore releases in the
> > > future.
> > > Arguably we would need also now, but given the data is added
> > > just a few days
> > > before the actual release i think users can understand "this release
> will
> > > happen soon)" compared to a thing one month in the future
> > >
> > > * What happens if we have to change the release date or release
> version
> > >
> > > number (hasn't happened in a good while, but wouldn't be a bad thing to
> > > prepare for it). We would need to update the string or date of an
> existing
> > > entry, as far as I know we don't have tooling for that (because we only
> > > add
> > > the data to the file when we're almost sure abiyt it).
> >
> > In addition I'm a litte bit wary of conflicts when cherry-picking the
> > appstream changes between branches, which the script does after
> > incrementing the version. I saw at least conflicts in itinerary's
> releases
> > notes and e.g. kdeconnect's or okular's windows releases in the past,
> which
> > isn't that much of a problem but it could become one with the 245 modules
> > of gear (to be fair not all have appstream metadata (yet)).
>
> Sorry about that! I try to keep both branches in sync usually, if there is
> anything I can do/do differently to not impact your work I'm happy to do
> that
> of course.
>
> > Otherwise I'd just miss the opportunity to trigger a CI build for
> > everything again shortly before the release, but I'd guess that's easy to
> > get over.
>
> Albert seems to have an alternative way using API (?) for the weekly build
> status reports, I guess that could be reused/combined somehow?
>
Please see
https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline
I imagine he uses
https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline to
fetch the outcome of that.
Note that the above API is not suitable for building a public dashboard due
to the number of queries we would need, but it is fine for one off runs
like what Albert does.
>
> Regards,
> Volker
Cheers,
Ben
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Wed, Mar 27, 2024 at 5:40 AM Volker Krause <<a \
href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Dienstag, 26. März \
2024 08:59:29 CET Heiko Becker wrote:<br> > On Monday, 25 March 2024 23:23:01 CET, \
Albert Astals Cid wrote:<br> > > El dissabte, 23 de març de 2024, a les \
21:06:46 (CET), Julius Künzel va<br> > > <br>
> > escriure:<br>
> >> 22.03.2024 17:22:33 Albert Astals Cid <<a \
href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>>: ...<br> > > \
<br> > > It is some extra work (not a lot, but some).<br>
> > <br>
> > You're asking for the workflow of creating to be releases to be changed \
by<br> > > creating the entry in the file earlier, that alone is a bit of work, \
but<br> > > it<br>
> > <br>
> > has several other consequences:<br>
> > * <a href="https://apps.kde.org/okular/" rel="noreferrer" \
target="_blank">https://apps.kde.org/okular/</a> shows releases from the appstream \
file (i<br> > > <br>
> > think) meaning that the code should learn to ignore releases in the<br>
> > future.<br>
> > Arguably we would need also now, but given the data is added<br>
> > just a few days<br>
> > before the actual release i think users can understand "this release \
will<br> > > happen soon)" compared to a thing one month in the future<br>
> > <br>
> > * What happens if we have to change the release date or release \
version<br> > > <br>
> > number (hasn't happened in a good while, but wouldn't be a bad \
thing to<br> > > prepare for it). We would need to update the string or date of \
an existing<br> > > entry, as far as I know we don't have tooling for that \
(because we only<br> > > add<br>
> > the data to the file when we're almost sure abiyt it).<br>
> <br>
> In addition I'm a litte bit wary of conflicts when cherry-picking the<br>
> appstream changes between branches, which the script does after<br>
> incrementing the version. I saw at least conflicts in itinerary's \
releases<br> > notes and e.g. kdeconnect's or okular's windows releases in \
the past, which<br> > isn't that much of a problem but it could become one \
with the 245 modules<br> > of gear (to be fair not all have appstream metadata \
(yet)).<br> <br>
Sorry about that! I try to keep both branches in sync usually, if there is <br>
anything I can do/do differently to not impact your work I'm happy to do that \
<br> of course.<br>
<br>
> Otherwise I'd just miss the opportunity to trigger a CI build for<br>
> everything again shortly before the release, but I'd guess that's easy \
to<br> > get over.<br>
<br>
Albert seems to have an alternative way using API (?) for the weekly build <br>
status reports, I guess that could be reused/combined \
somehow?<br></blockquote><div><br></div><div>Please see <a \
href="https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline">https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline</a> \
</div><div>I imagine he uses <a \
href="https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline">https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline</a> \
to fetch the outcome of that.</div><div><br></div><div>Note that the above API is not \
suitable for building a public dashboard due to the number of queries we would need, \
but it is fine for one off runs like what Albert does.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Regards,<br>
Volker</blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic