Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
(On top of what Paul said, if this happens, should we also stop with the Reddit and Facebook management, since it’s a closed source software on for profit companies?) On Wed, 23 Aug 2023 at 03:41 Paul Brown wrote: > On Tuesday, 22 August 2023 22:08:34 CEST Albert Vaca Cintora wrote: > > KDE Connect has a Telegram group with 660 members (vs 100 on matrix). I > > don't know if we are the exception > > It's not. Kdenlive is another example where most users on both the Spanish > and > English channels are largely on Telegram. I think you will find that > developers > tend to gravitate towards IRC and maybe Matrix, but end users gravitate > towards Telegram and don't really want to open another account on yet > another > IM platform. > > But let me try to highlight some of the issues with this proposed plan (as > is) > with some questions: > > If we cut off hundreds of users from the rest of the community, will this > action help or damage KDE's relevancy among end users? Will it increase or > decrease the rate of adoption of our software? > > It has been mentioned that this was discussed at a BoF and on a mailing > list. > How many end users, say, from the KDE Connect and Kdenlive user channels > on > Telegram do you estimate attended the Bof and how many do you estimate > regularly read the mailing lists? > > Is it right to make this decision behind the backs of the people who will > be > most affected? > > How does this plan fit in with KDE's vision, mission and manifesto, all > three > of which insist we take into account the users and their needs over most > other > things? > > As a reminder: > > https://community.kde.org/KDE/Vision > https://community.kde.org/index.php?title=KDE/Mission > https://manifesto.kde.org/ > > If you have a healthy growing community of end users, already in the > hundreds, > probably surpassing a thousand users, is it sensible to cut it off? > > Moving on to the schedule, do you think, we, the channel mods and admins, > can > realistically migrate hundreds of people to a completely new platform they > probably even haven't heard of in less than a month? Do we get time to eat > and > sleep? > > Do you think cutting users off will be a convincing argument that will > encourage most of the people to migrate? > > Have you thought of other strategies we can use that will render better > results? If so, would you mind sharing them? > > How many of the links to Telegram peppered all through our web pages have > you > removed and changed to point to Matrix? > > If none (it is none, isn't it?), shouldn't have this been one of your > first > actions, to curb incoming new users away from Telegram to Matrix? Why did > you > not think of this? > > In view of your prior answers, do you think maybe this "plan" may not be > much > of a plan at all, that maybe it is simplistic, even harebrained, > unrealistic > and insensitive, and, if forced through, you may hurt the community in > ways > that will take years to repair? > > Cheers > > Paul > > > > > > with such a big group on Telegram, but > > this is going to be a hit to our community :( > > > > On Tue, 22 Aug 2023, 09:02 Joseph P. De Veaugh-Geiss, > > > > wrote: > > > Hello KDE community, > > > > > > apologies for cross-posting! > > > > > > The time has finally come: both Telegram <-> Matrix bridges will be > shut > > > down in 4 weeks on *Wednesday 20 September*. Let's start the > > > co-ordination process now so everything goes as smoothly as possible. > > > > > > For all KDE contributors: please read at least the "Five To-Dos" below > > > to be informed about what will happen and what needs to be done. > > > > > > Below that there is some additional information about the bridging > > > situation at KDE. Consult these notes if you want more background > > > information about why the Telegram bridge is being retired. > > > > > > Cheers, > > > Joseph > > > > > > _Five To-Dos_ > > > > > >1. *General*: On Wednesday 20 September the Telegram bridging to KDE > > > > > > Matrix rooms will be shut down. To make the transition go smoothly, > > > teams should start co-ordinating for the shutdown now. The Matrix room > > > for co-ordination is "Telegram shutdown co-ordination" at > > > https://go.kde.org/matrix/#/#telegram-shutdown:kde.org. > > > > > >2. *Co-ordination*: This includes: (i) migrating all contributors to > > > > > > Matrix, and (ii) deleting the Telegram rooms before the bridge is > > > shutdown or -- at most -- one day after the shutdown. Keeping Telegram > > > rooms open when they are no longer being used will cause unnecessary > > > confusion. Importantly, do not later add a non-KDE Telegram bridge to > > > KDE's Matrix rooms as that will not solve the problems from doubled > user > > > accounts and lack of control over Telegram; see below for operational > > > issues with Telegram bridging. > > > > > >3. *Action needed by Telegram room admins*: Due to the unexpected > > > > > > shutdown of the public Libera.Chat brid
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Mittwoch, 23. August 2023 09:34:04 CEST Tomaz Canabrava wrote: > (On top of what Paul said, if this happens, should we also stop with the > Reddit and Facebook management, since it’s a closed source software on for > profit companies?) The Telegram bridging is shut down because of unmanageable technical problems and not for political reasons. If it ran smoothly, then I don't think it would be shut down. Don't read more into this than there is. In particular, this isn't a conspiracy against Telegram users. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
Dear All,
Sorry for being a pain in the neck about this, but the more I read the plan to
migrate, the less it seems a plan at all. It just boils down to a deadline.
There is no contingency, nobody has considered what the people who use
Telegram to interact with us want, nobody has opened any kind of brainstorming
so we may come up with a way of nudging instead of forcing users to migrate.
Yes, we all want everybody to use FLOSS, but while some parts of the community
can avoid proprietary software and platforms completely, we ("we" being the
people carrying out promotional and outreachy tasks) can't.
Our main mission is to grow KDE's user base. This means we have to go where we
can find new users and communities we can grow into. That is why we still have
Facebook, Xitter, Reddit and Telegram.
When communities organically take hold on these platforms and start to grow,
we cannot afford to cut them off just because we don't like where they are
growing. Do that often enough and KDE and all its software becomes irrelevant
and loses what tiny portion of the market share it currently has.
Getting back to the topic at hand, there will be channels we will be able to
migrate in the time frame proposed (the Promo channel on Telegram itself can
probably be closed down within days, as can Atelier 3D Printing), there are
channels which will take much longer and need a much more tactful approach
(and I suggest we include "brainstorm ways we can facilitate the migration"
into the plans TODOs).
And then there are channels which we will never be able to migrate.
We will actively support Sysadmin in the task of migrating as many channels as
we can in the given time frame; but I believe it is only reasonable to expect
that we get some degree of support from others for our task of growing and
maintaining KDE's user base where we find it.
If that means coming up with a solution to the bridge problem, well, solving
technical problems to provide for users is KDE's thing, right?
We can figure it out.
Cheers
Paul
--
Promotion & Communication
www: https://kde.org
Mastodon: https://floss.social/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
Just to confirm: this means that if we find a more reliable way to bridge the channels we can avoid this? If so, I'd be happy to give it a shot. ~Nicco Il giorno mer 23 ago 2023 alle ore 10:27 Ingo Klöcker ha scritto: > On Mittwoch, 23. August 2023 09:34:04 CEST Tomaz Canabrava wrote: > > (On top of what Paul said, if this happens, should we also stop with the > > Reddit and Facebook management, since it’s a closed source software on > for > > profit companies?) > > The Telegram bridging is shut down because of unmanageable technical > problems > and not for political reasons. If it ran smoothly, then I don't think it > would > be shut down. Don't read more into this than there is. In particular, this > isn't a conspiracy against Telegram users. > > Regards, > Ingo -- Niccolò Venerandi
Re: Per project repository snapcraft files?
After some testing and various complicated options, the easiest I have found is importing our github mirror in launchpad ( this avoids the polling on kde servers ) and we can create our necessary snap recipes and KDE infrastructure is unaffected save the already in place github mirror. Launchpad does everything else ( building and uploading to store ) I see no reason not to move forward as KDE infrastructure will have much less involvement in the snap lifecycle aside from the snapcraft files being in the application repository. As mentioned before this will allow developers closer involvement with snap developers. Thanks, Scarlett On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel wrote: > > I think there is a lot of misunderstanding here. > > In GitLab CI only test builds are done and artifacts are kept so people > can test an AppImage or Flatpak without having to compile locally. > > Stable releases are done by the Release Team via scripts to tarballs. > Flatpaks are done via Flathub and are done (usually) automatically via > the Flatpak External Data Checker. > > Hopefully this clarifies the situation. > > On 21/8/23 08:48, Scarlett Moore wrote: > > > > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel > > wrote: > > > > To me it seems this discussion is quite abstract and there are > > several misunderstandings because not everybody knows every detail > > of snap packaging and/or the KDE infrastructure (me neither). > > > > I understand that from an organizational perspective most people > > like the idea of having the files in the repos, but have technical > > doubts. Hence, I wonder whether it would be a good idea to take > > one KDE app to try and showcase this suggestion? > > > > Cheers, > > Julius > > > > Sounds like a great idea to me. > > Scarlett > > > > > > > > > > 20.08.2023 17:55:24 Laura David Hurka : > > > > > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > > >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > > >> > > >> scarlett.gately.mo...@gmail.com> wrote: > > >>> Only on release! We will not be building from master! We don't > > want > > >>> unstable snaps. > > >>> Thanks, > > >>> Scarlett > > >> > > >> In that particular case the jobs should be manually triggered only. > > >> > > >> Gitlab CI is really made for building artifacts for a given > > commit rather > > >> than for a specified version though, so this is definitely > > going to be a > > >> case of things not fitting quite right. > > >> > > >> Cheers, > > >> Ben > > >> [...] > > > > > > This confuses me too. > > > It seems Scarlett wants to use a “deploy” stage [1] and a job > > rule [2] > > > to run snap build&release jobs automatically when the release is > > done. > > > > > > If you mean that Gitlab CI should not be used to automate > > release jobs, > > > you should elaborate more how binary-factory is meant to be > > replaced. > > > > > > Otherwise, do you just note that Gitlab CI is suboptimal, > > > or do you recommend to use something else? > > > Like: “Release build: automatic is fine. Release publish: please > > only manual”? > > > > > > Cheers, David > > > > > > > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > > > [2] like this: > > > snap-release-job: > > > rules: > > > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > > > [...] > > > see also: > > > > https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types > >
Re: Per project repository snapcraft files?
El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore va escriure: > After some testing and various complicated options, the easiest I have > found is importing our github mirror in launchpad ( this avoids the > polling on kde servers ) and we can create our necessary snap recipes > and KDE infrastructure is unaffected save the already in place github > mirror. Launchpad does everything else ( building and uploading to > store ) I see no reason not to move forward as KDE infrastructure will > have much less involvement in the snap lifecycle aside from the > snapcraft files being in the application repository. As mentioned > before this will allow developers closer involvement with snap > developers. Honestly I'm still a bit lost on what is you are trying to do regarding Snap and the KDE repos :D Are we going for CI or CD? CI -> snap is compiled on each commit and MR to make sure we don't break the snap build CD -> We have an almost-automated way of doing snap "release" builds. To give some examples: This is arianna's KDE flatpak CI https://invent.kde.org/graphics/arianna/-/jobs/1142328 It builds arianna using flatpak with each commit but the artifacts are "unused" This is Okular's KDE Windows CI https://invent.kde.org/graphics/okular/-/jobs/1142178 It builds each commit to make sure the Windows build doesn't get broken This is Okular's KDE Windows CD https://binary-factory.kde.org/job/Okular_Release_win64/ It builds release Okular nightly in a way that is a release build and can be easily uploaded to the Windows Store This is Okular flathub CD https://github.com/flathub/org.kde.okular https://buildbot.flathub.org/#/apps/org.kde.okular It is a convenient way to generate new builds each time a stable release happens I see you committed this https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml What is that going to give us? Cheers, Albert > Thanks, > Scarlett > > On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel wrote: > > I think there is a lot of misunderstanding here. > > > > In GitLab CI only test builds are done and artifacts are kept so people > > can test an AppImage or Flatpak without having to compile locally. > > > > Stable releases are done by the Release Team via scripts to tarballs. > > Flatpaks are done via Flathub and are done (usually) automatically via > > the Flatpak External Data Checker. > > > > Hopefully this clarifies the situation. > > > > On 21/8/23 08:48, Scarlett Moore wrote: > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel > > > > > > wrote: > > > To me it seems this discussion is quite abstract and there are > > > several misunderstandings because not everybody knows every detail > > > of snap packaging and/or the KDE infrastructure (me neither). > > > > > > I understand that from an organizational perspective most people > > > like the idea of having the files in the repos, but have technical > > > doubts. Hence, I wonder whether it would be a good idea to take > > > one KDE app to try and showcase this suggestion? > > > > > > Cheers, > > > Julius > > > > > > Sounds like a great idea to me. > > > Scarlett > > > > > > 20.08.2023 17:55:24 Laura David Hurka : > > > > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > > > >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > > > >> > > > >> scarlett.gately.mo...@gmail.com> wrote: > > > >>> Only on release! We will not be building from master! We don't > > > > > > want > > > > > > >>> unstable snaps. > > > >>> Thanks, > > > >>> Scarlett > > > >> > > > >> In that particular case the jobs should be manually triggered > > > >> only. > > > >> > > > >> Gitlab CI is really made for building artifacts for a given > > > > > > commit rather > > > > > > >> than for a specified version though, so this is definitely > > > > > > going to be a > > > > > > >> case of things not fitting quite right. > > > >> > > > >> Cheers, > > > >> Ben > > > >> [...] > > > > > > > > This confuses me too. > > > > It seems Scarlett wants to use a “deploy” stage [1] and a job > > > > > > rule [2] > > > > > > > to run snap build&release jobs automatically when the release is > > > > > > done. > > > > > > > If you mean that Gitlab CI should not be used to automate > > > > > > release jobs, > > > > > > > you should elaborate more how binary-factory is meant to be > > > > > > replaced. > > > > > > > Otherwise, do you just note that Gitlab CI is suboptimal, > > > > or do you recommend to use something else? > > > > Like: “Release build: automatic is fine. Release publish: please > > > > > > only manual”? > > > > > > > Cheers, David > > > > > > > > > > > > [1] http
Re: Per project repository snapcraft files?
On Wed, Aug 23, 2023 at 10:00 AM Albert Astals Cid wrote: > > El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore va > escriure: > > After some testing and various complicated options, the easiest I have > > found is importing our github mirror in launchpad ( this avoids the > > polling on kde servers ) and we can create our necessary snap recipes > > and KDE infrastructure is unaffected save the already in place github > > mirror. Launchpad does everything else ( building and uploading to > > store ) I see no reason not to move forward as KDE infrastructure will > > have much less involvement in the snap lifecycle aside from the > > snapcraft files being in the application repository. As mentioned > > before this will allow developers closer involvement with snap > > developers. > > Honestly I'm still a bit lost on what is you are trying to do regarding Snap > and the KDE repos :D The same as flatpak, minus the daily builds. > > Are we going for CI or CD? > > CI -> snap is compiled on each commit and MR to make sure we don't break the > snap build > > CD -> We have an almost-automated way of doing snap "release" builds. CD via launchpad. > > > To give some examples: > > This is arianna's KDE flatpak CI >https://invent.kde.org/graphics/arianna/-/jobs/1142328 > It builds arianna using flatpak with each commit but the artifacts are > "unused" > We could set set that up but I find it unnecessary. Launchpad can build and upload to edge channel. > > This is Okular's KDE Windows CI >https://invent.kde.org/graphics/okular/-/jobs/1142178 > It builds each commit to make sure the Windows build doesn't get broken > > > This is Okular's KDE Windows CD >https://binary-factory.kde.org/job/Okular_Release_win64/ > It builds release Okular nightly in a way that is a release build and > can be easily uploaded to the Windows Store > > > This is Okular flathub CD >https://github.com/flathub/org.kde.okular >https://buildbot.flathub.org/#/apps/org.kde.okular > It is a convenient way to generate new builds each time a stable release > happens > This will be the same, but with launchpad. > > I see you committed this > https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml > > > What is that going to give us? > Snaps. In this case launchpad will build master and upload to edge channel. I also commited to the stable branch in which launchpad will build and upload to the candidate/stable channel. > > Cheers, > Albert > Thanks, Scarlett > > > Thanks, > > Scarlett > > > > On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel wrote: > > > I think there is a lot of misunderstanding here. > > > > > > In GitLab CI only test builds are done and artifacts are kept so people > > > can test an AppImage or Flatpak without having to compile locally. > > > > > > Stable releases are done by the Release Team via scripts to tarballs. > > > Flatpaks are done via Flathub and are done (usually) automatically via > > > the Flatpak External Data Checker. > > > > > > Hopefully this clarifies the situation. > > > > > > On 21/8/23 08:48, Scarlett Moore wrote: > > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel > > > > > > > > wrote: > > > > To me it seems this discussion is quite abstract and there are > > > > several misunderstandings because not everybody knows every detail > > > > of snap packaging and/or the KDE infrastructure (me neither). > > > > > > > > I understand that from an organizational perspective most people > > > > like the idea of having the files in the repos, but have technical > > > > doubts. Hence, I wonder whether it would be a good idea to take > > > > one KDE app to try and showcase this suggestion? > > > > > > > > Cheers, > > > > Julius > > > > > > > > Sounds like a great idea to me. > > > > Scarlett > > > > > > > > 20.08.2023 17:55:24 Laura David Hurka : > > > > > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > > > > >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > > > > >> > > > > >> scarlett.gately.mo...@gmail.com> wrote: > > > > >>> Only on release! We will not be building from master! We don't > > > > > > > > want > > > > > > > > >>> unstable snaps. > > > > >>> Thanks, > > > > >>> Scarlett > > > > >> > > > > >> In that particular case the jobs should be manually triggered > > > > >> only. > > > > >> > > > > >> Gitlab CI is really made for building artifacts for a given > > > > > > > > commit rather > > > > > > > > >> than for a specified version though, so this is definitely > > > > > > > > going to be a > > > > > > > > >> case of things not fitting quite right. > > > > >> > > > > >> Cheers, > > > > >> Ben > > > > >> [...] > > > > > > > > > > This confuses me too. > > > > > It seems Scarlett wants to use a “deploy” stage [1] and a job > > > > > > > > rule [2] > > > > > > > > >
[ANNOUNCE] CMake 3.27.4 available for download
We are pleased to announce that CMake 3.27.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! Changes made since CMake 3.27.3: Brad King (5): cppdap: Update script to get version as of 2023-08-17 VS: Remove duplicate import in compiler id vcxproj Help: Document cmake_minimum_required deprecation of old versions FindZLIB: Fix extraction of two-component version number 1.3 CMake 3.27.4 Marc Chevrier (1): list(INSERT): restore old behavior Tarun Prabhu (1): LLVMFlang-Fortran: Add flags for build types cppdap Upstream (1): cppdap 2023-08-17 (cc2f2058)
Re: Per project repository snapcraft files?
El dimecres, 23 d’agost de 2023, a les 19:13:46 (CEST), Scarlett Moore va escriure: > On Wed, Aug 23, 2023 at 10:00 AM Albert Astals Cid wrote: > > El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore va escriure: > > > After some testing and various complicated options, the easiest I have > > > found is importing our github mirror in launchpad ( this avoids the > > > polling on kde servers ) and we can create our necessary snap recipes > > > and KDE infrastructure is unaffected save the already in place github > > > mirror. Launchpad does everything else ( building and uploading to > > > store ) I see no reason not to move forward as KDE infrastructure will > > > have much less involvement in the snap lifecycle aside from the > > > snapcraft files being in the application repository. As mentioned > > > before this will allow developers closer involvement with snap > > > developers. > > > > Honestly I'm still a bit lost on what is you are trying to do regarding > > Snap and the KDE repos :D > The same as flatpak, minus the daily builds. I don't see the similarities with what we have in KDE-flatpak land For KDE-flatpak we have: * CI, which you say this is not about CI * CD on flathub, which uses the released tarballs instead of git, and the description file is in github and not on invent * CD on binary factory, this one is based on git, but that's just master/ nightlies no one is suppose to use > > > Are we going for CI or CD? > > > > CI -> snap is compiled on each commit and MR to make sure we don't break > > the snap build > > > > CD -> We have an almost-automated way of doing snap "release" builds. > > CD via launchpad. Were can i check the status of a given app? i.e. the counterpart of https://buildbot.flathub.org/#/apps/org.kde.okular > > > To give some examples: > > > > This is arianna's KDE flatpak CI > > > >https://invent.kde.org/graphics/arianna/-/jobs/1142328 > > > > It builds arianna using flatpak with each commit but the artifacts > > are "unused" > We could set set that up but I find it unnecessary. Launchpad can > build and upload to edge channel. > > > This is Okular's KDE Windows CI > > > >https://invent.kde.org/graphics/okular/-/jobs/1142178 > > > > It builds each commit to make sure the Windows build doesn't get > > broken > > > > This is Okular's KDE Windows CD > > > >https://binary-factory.kde.org/job/Okular_Release_win64/ > > > > It builds release Okular nightly in a way that is a release build and > > can be easily uploaded to the Windows Store> > > This is Okular flathub CD > > > >https://github.com/flathub/org.kde.okular > >https://buildbot.flathub.org/#/apps/org.kde.okular > > > > It is a convenient way to generate new builds each time a stable > > release happens > This will be the same, but with launchpad. > > > I see you committed this > > https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml > > > > > > What is that going to give us? > > Snaps. In this case launchpad will build master and upload to edge channel. > I also commited to the stable branch in which launchpad will build and > upload to the candidate/stable channel. You're building stable snaps from git branch instead of tarballs, right? Does this mean a new snap is built [and distributed to the users?] for each commit we make to the stable branch? Cheers, Albert > > > Cheers, > > > > Albert > > Thanks, > Scarlett > > > > Thanks, > > > Scarlett > > > > > > On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel wrote: > > > > I think there is a lot of misunderstanding here. > > > > > > > > In GitLab CI only test builds are done and artifacts are kept so > > > > people > > > > can test an AppImage or Flatpak without having to compile locally. > > > > > > > > Stable releases are done by the Release Team via scripts to tarballs. > > > > Flatpaks are done via Flathub and are done (usually) automatically via > > > > the Flatpak External Data Checker. > > > > > > > > Hopefully this clarifies the situation. > > > > > > > > On 21/8/23 08:48, Scarlett Moore wrote: > > > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel > > > > > > > > > > wrote: > > > > > To me it seems this discussion is quite abstract and there are > > > > > several misunderstandings because not everybody knows every > > > > > detail > > > > > of snap packaging and/or the KDE infrastructure (me neither). > > > > > > > > > > I understand that from an organizational perspective most people > > > > > like the idea of having the files in the repos, but have > > > > > technical > > > > > doubts. Hence, I wonder whether it would be a good idea to take > > > > > one KDE app to try and showcase this suggestion? > > > > > > > > > > Cheers, > > > > > Julius > > > > > > > > > > Sounds like a great idea to me. > > > > > Scarlett > > > > > > > > > > 20.08.2023 17:5
Re: Per project repository snapcraft files?
I believe snaps has a similar github build setup as well. I will look into it. This completely defeats the whole purpose in which I wanted this in the first place though. Developers getting involved and helping with their snaps. Alas I digress. Scarlett On Wed, Aug 23, 2023, 3:27 PM Albert Astals Cid wrote: > El dimecres, 23 d’agost de 2023, a les 19:13:46 (CEST), Scarlett Moore va > escriure: > > On Wed, Aug 23, 2023 at 10:00 AM Albert Astals Cid > wrote: > > > El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore > va > escriure: > > > > After some testing and various complicated options, the easiest I > have > > > > found is importing our github mirror in launchpad ( this avoids the > > > > polling on kde servers ) and we can create our necessary snap recipes > > > > and KDE infrastructure is unaffected save the already in place github > > > > mirror. Launchpad does everything else ( building and uploading to > > > > store ) I see no reason not to move forward as KDE infrastructure > will > > > > have much less involvement in the snap lifecycle aside from the > > > > snapcraft files being in the application repository. As mentioned > > > > before this will allow developers closer involvement with snap > > > > developers. > > > > > > Honestly I'm still a bit lost on what is you are trying to do regarding > > > Snap and the KDE repos :D > > The same as flatpak, minus the daily builds. > > I don't see the similarities with what we have in KDE-flatpak land > > For KDE-flatpak we have: > * CI, which you say this is not about CI > * CD on flathub, which uses the released tarballs instead of git, and the > description file is in github and not on invent > * CD on binary factory, this one is based on git, but that's just master/ > nightlies no one is suppose to use > > > > > > Are we going for CI or CD? > > > > > > CI -> snap is compiled on each commit and MR to make sure we don't > break > > > the snap build > > > > > > CD -> We have an almost-automated way of doing snap "release" builds. > > > > CD via launchpad. > > Were can i check the status of a given app? > > i.e. the counterpart of https://buildbot.flathub.org/#/apps/org.kde.okular > > > > > > To give some examples: > > > > > > This is arianna's KDE flatpak CI > > > > > >https://invent.kde.org/graphics/arianna/-/jobs/1142328 > > > > > > It builds arianna using flatpak with each commit but the artifacts > > > are "unused" > > We could set set that up but I find it unnecessary. Launchpad can > > build and upload to edge channel. > > > > > This is Okular's KDE Windows CI > > > > > >https://invent.kde.org/graphics/okular/-/jobs/1142178 > > > > > > It builds each commit to make sure the Windows build doesn't get > > > broken > > > > > > This is Okular's KDE Windows CD > > > > > >https://binary-factory.kde.org/job/Okular_Release_win64/ > > > > > > It builds release Okular nightly in a way that is a release build > and > > > can be easily uploaded to the Windows Store> > > > This is Okular flathub CD > > > > > >https://github.com/flathub/org.kde.okular > > >https://buildbot.flathub.org/#/apps/org.kde.okular > > > > > > It is a convenient way to generate new builds each time a stable > > > release happens > > This will be the same, but with launchpad. > > > > > I see you committed this > > > https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml > > > > > > > > > What is that going to give us? > > > > Snaps. In this case launchpad will build master and upload to edge > channel. > > I also commited to the stable branch in which launchpad will build and > > upload to the candidate/stable channel. > > You're building stable snaps from git branch instead of tarballs, right? > > Does this mean a new snap is built [and distributed to the users?] for > each > commit we make to the stable branch? > > > > Cheers, > Albert > > > > > > Cheers, > > > > > > Albert > > > > Thanks, > > Scarlett > > > > > > Thanks, > > > > Scarlett > > > > > > > > On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel > > wrote: > > > > > I think there is a lot of misunderstanding here. > > > > > > > > > > In GitLab CI only test builds are done and artifacts are kept so > > > > > people > > > > > can test an AppImage or Flatpak without having to compile locally. > > > > > > > > > > Stable releases are done by the Release Team via scripts to > tarballs. > > > > > Flatpaks are done via Flathub and are done (usually) automatically > via > > > > > the Flatpak External Data Checker. > > > > > > > > > > Hopefully this clarifies the situation. > > > > > > > > > > On 21/8/23 08:48, Scarlett Moore wrote: > > > > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel > > > > > > > > > > > > wrote: > > > > > > To me it seems this discussion is quite abstract and there > are > > > > > > several misunderstandings because not everybody knows every > > > > > > detail > > > > > > of snap packaging and/or t
