Re: Blacklisting of PIM from the CI system
Harald Sitter wrote: > Random thought to make dependency problems more obvious: glue the git > sha into the cmake package version for frameworks (when built from > git) so it finds "5.65.0.abcd123" given us a lead on what is actually > available. The git SHA is not going to work for this, because it is not monotonic. What you really want to know is whether you have something >= 5.65.0.abcd123, and having a 5.65.0.commithash version is not going to tell you that. Kevin Kofler
Re: KTimeTracker in kdereview
Moved to extragear-pim. @Luigi, please move the translations. вт, 3 дек. 2019 г. в 13:45, Alexander Potashev : > > вт, 19 нояб. 2019 г. в 07:20, Alexander Potashev : > > KTimeTracker [1] has been moved to kdereview. > > > > The project is currently in playground-pim, destination would be > > extragear-pim. > > KTimeTracker had been in kdereview for two weeks already. It is enough > to assume everything is OK and we can move it to final destination > (extragear-pim), according to > https://community.kde.org/Policies/Application_Lifecycle#Releasing > > If no one objects, I will request the move to extragear-pim tomorrow. > > -- > Alexander Potashev -- Alexander Potashev
Re: Blacklisting of PIM from the CI system
On Tue, Dec 3, 2019 at 8:55 PM Volker Krause wrote: > > On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote: > > On Sun, Dec 1, 2019 at 10:17 AM Volker Krause wrote: > > > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote: > [...] > > > > Fixing the current set of failures will not prevent this blacklisting > > > > action from being carried out - as a recurring issue it needs a > > > > permanent solution. > > > > > > What do you envision this permanent solution to look like? > > > > It's hard to say. > > > > Given the current problem, which is changes being actively made that > > break the build, the ideal solution would be the developers who are > > making these breakages to actively keep an eye on their jobs on the CI > > system. > > That isn't an entirely fair statement IMHO, the changes triggering this were > perfectly fine with either the latest Frameworks release or a recent enough > master, just not the delayed master we had available on the CI at this point. > Seeing this hit other master-tracking builds too (e.g. OpenSuse in #kontact > this morning), I completely agree though this needs a better solution overall. > > Tracking the latest release would be one approach, but from direct discussion > I understand that's currently not a viable solution due to Plasma's needs. Not > allowing changes for master compatibility (with the corresponding version > #ifdefs) is also counter-productive though, as it prevents early testing of > Frameworks changes (even if just locally). So the best I can think of is > making sure this situation is widely enough understood, and we have a way to > find out which exact revisions of Frameworks are deployed. Then we can maybe > get to the point where we can defer such commits until a recent enough > revision is available, which IIUC would usually take 48-72h. Random thought to make dependency problems more obvious: glue the git sha into the cmake package version for frameworks (when built from git) so it finds "5.65.0.abcd123" given us a lead on what is actually available. https://phabricator.kde.org/D24641 would give us the foundation for that. Not sure how viable this is, or even if it adds much value. After all everyone still needs to know to check the specific in the build logs. Food for thought I guess. HS
Re: Blacklisting of PIM from the CI system
On Tuesday, 3 December 2019 22:13:43 CET Allen Winter wrote: > On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote: > > The complexity of the dependency graph is also a problem for onboarding > > new > > people, and with kdelibs4support gone IMHO the largest technical dept > > here. > > It's being worked on, albeit slowly, currently we are losing ~1 module per > > release I think. > > Silly questions > > Why do we need 50-60 repos to build kontact? > why not 1 repo for kontact and all its stuff? (I miss kdepim) > > do Krita or any of the other large applications have so many repositories > devoted to them? > > After all these years since the svn->git move I still understand why so many > repostitories for Kontact. For frameworks it makes sense, but I don't get > it for applications 50 repos for this is too much IMHO, I agree. There's reasons for not having this in a single one though, one being that various parts are used externally as well (former kdepimlibs basically). This is what we try to address with moving things to Frameworks. There's also things like Akonadi or Kleo being used externally though, that's much harder to Frameworkify. And then there are a few obsolete reasons, like the refactoring done for Kontact Mobile 10 years ago, or for Kube. Another aspect to look at is whether those repos have a well defined scope. Good examples are IMHO eventviews/incidenceeditor, bad ones are libkdepim/ kdepim-apps-libs/pimcommon/etc. The former hurt much less than the latter I think. The strategy discussed at the PIM meetings for this is two-fold: continue with Frameworkification of the well-scoped and externally used modules, and try to dissolve the libraries with undefined scope by moving stuff to more appropriate places. Especially the latter isn't exactly a fun job, therefore this is progressing very slowly. Going to a mono repo setup would make building easier for PIM contributors, but it would not solve the problem for new people to find their way through the various libraries with unclear scope, so IMHO this is a problem we have to address regardless of the repo layout. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Blacklisting of PIM from the CI system
On dinsdag 3 december 2019 22:13:43 CET Allen Winter wrote: > On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote: > > The complexity of the dependency graph is also a problem for onboarding new > > people, and with kdelibs4support gone IMHO the largest technical dept here. > > It's being worked on, albeit slowly, currently we are losing ~1 module per > > release I think. > > > Silly questions > > Why do we need 50-60 repos to build kontact? > why not 1 repo for kontact and all its stuff? (I miss kdepim) > > do Krita or any of the other large applications have so many repositories > devoted to them? Krita is just one repo. Of course, we've got our own little complications when it comes to building on binary factory , but for CI that's not relevant. > After all these years since the svn->git move I still understand why so many > repostitories for Kontact. > For frameworks it makes sense, but I don't get it for applications -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.
