Re: Proposal unify back our release schedules
i know quite a few have responded to this, but as the big warning on this, the fact that the three parts cant be released independently, is a big warning flag that a overhaul is needed of the overlapping architecture. i know this is a big issue, and the bigger the project, the bigger the workload. i saw someone was starting on a tool to graph architecture wise at https://invent.kde.org/sdk/codevis , its still in development, but i think this will highlight where the issue pinpoints are, break the cycles, and levelize everything. when stuff actually is decoupled, the frameworks would even be able to do staggered/piped deploys and the whole dev team would have less stress.. doing 3 releases a year or doing 12+ smaller ones, deploying from the base and going up, anything that depends on other parts will have to wait and since they still work against the last stable the friction will be less. i kept an eye on the mega release 6, and if that is viewed as a success i guess we got very different views on successes, from the mailing list it looked like at best organized chaos. On Fri, Apr 19, 2024 at 1:32 PM Carl Schwan wrote: > Hello Community, > > I know this might be a controversial idea, but I would like to propose > reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different > times but > are connected together. Apps and Plasma both need Framework, Plasma > needs some > packages from gear like kio-extra, Gear needs some package from Plasma > like > Breeze. Coordinating all these inter-groups dependencies is complex and > was one > the reason we had to do a megarelease for Plasma 6. Also for the end > user, one > product is a lot easier to understand. > here is a architecture bug list, the fact that there are circles like this is what needs to be dealt with before even thinking of feature development, its boring, and it will break stuff, but better take the bull by the horns and deal with it.. > * This results in very frequent releases which creates a lot of work for > distros > and talking with some distro maintainers they seems to agree that having > a big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > a stable release should support a known set say last 3 major releases for example. (this i due to the versioning scheme yy.mm counted as a major, then patches are the minors..) the released code used by downstream its the open source value chain.. 'master' is just work in progress until its released. distros themselves have the same issue with bad architecture, so to lessen their burden with dealing with broken stuff upstream they rather take a big release 'block' then a smaller one, its just a massive monolith they deploy then. big changes are always more risky then small ones.. problem is that features are more fun than doing maintenance on old stuff.. * We currently don't have a stable branch for Framework and it takes often > up to > one month for fixes to be deployed. The Framework releases is also not > in sync > with either Gear nor Plasma while these two modules heavily make use of > Framework > and contribute to Framework. > perfect candidate for automation.. deployment really should be automated, either by bots or other means. * We could have an unified LTS release including more than just Plasma. > This is > something that distros have been asking for some time already because > having > just Plasma receiving bug-fixes but not Framework nor the apps is not > that helpful. > i personally would prefer two release ways one feature release and one long term stable release, but this adds burden on the whole organization so i know its currently a utopia dream. mostly since KDE would have to do the Qt lts releases too since without a 'upstream' open source Qt LTS a KDE LTS is pretty useless since the dependency will have a lot faster churn than the dependency, its supposed to be the other way around.. the base is stable, the features and the churn happens a lot higher up in the structure. > * In term of promotion, it is very difficult to advertise the 3 releases > because > combined we have an important release of either Gear, Plasma or > Framework every > few weeks. This is too frequent and often while a combined announcement > would > have enough content to be published in a tech newspaper. When splitting > the content > accross 2 announcements (Gear and Plasma), we reduce the content per > announcement and this makes it less interesting for the journalists to > write > about us. This doesn't come from me, this is that some journalists > directly > told me. > this is not in my wheelhouse but i guess
Fwd: kio-gdrive changes needed to conform to new Google requirements
same as last mail, forgot to send to ML From: Björn Strömberg Date: Fri, Mar 29, 2024 at 7:01 AM Subject: Re: kio-gdrive changes needed to conform to new Google requirements To: Lydia Pintscher Hello Lydia Pintscher, sounds great that someone in the KDE board of directors is down here, i got an idea for you guys! google change the rules on gdrive! then the board will start figuring out how we're going to replace gdrive with kdrive! a solution that looks like gdrive from the users perspective, and is stored on a selfhosted and/or community hosted solution! best way to handle bullies like google is to replace them with something better! selfhosted or community hosted solutions are better than google 7 days a week... with kind easter regards from Sweden /Björn On Thu, Mar 28, 2024 at 8:07 PM Lydia Pintscher wrote: > Hi everyone, > > The board has gotten a reminder about this again and that the deadline > is looming in 21 days. > > On Fri, Feb 16, 2024 at 3:07 PM Carl Schwan wrote: > > I can probably help a bit with e.g. doing the video but starting the > process > > needs to be done by someone who has access to the google account > (probably the > > board). > > Awesome. Thank you. I can sit down with you and do that part. Poke me > when you have time please. > > > Cheers > Lydia > > -- > Lydia Pintscher - https://lydiapintscher.de - WD:Q18016466 > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org >
Fwd: kio-gdrive changes needed to conform to new Google requirements
and once again i forget to send direct to the ML. From: Björn Strömberg Date: Fri, Mar 29, 2024 at 6:51 AM Subject: Re: kio-gdrive changes needed to conform to new Google requirements To: Carl Schwan this is exactly the reason you don't use google for anything that you care about, they love to lure every one in to depend on them, then they change the rules when they get enough users, many of who would never accept the rules they change to if they had gotten them straight up front. ... classic bait and switch ... personally i would say f google, and mark the module as dead/defect due to google changed rules. if there really is someone who really needs it, they will pull it back through the invent process and becomes the maintainer of it. just my 0.02€ /Björn ps. yes I know I'm writing this from a gmail account... it's one of the main reason for the knowledge of the constant baiting and switching from google... On Fri, Feb 16, 2024 at 4:07 PM Carl Schwan wrote: > On Thursday, February 15, 2024 9:53:39 PM CET Nate Graham wrote: > > Hello folks, > > The KDE e.V. board received an email from Google about changes required > > for kio-gdrive. I've opened an Issue about it at > > https://invent.kde.org/network/kio-gdrive/-/issues/1 with more details. > > To my knowledge, kio-gdrive is maintainerless, so we're in need of a > > kind soul who will volunteer to make any needed changes to the software. > > > > :) Any takers? > > I just looked into it and I don't want to be pesimistic but it sounds like > Google is shutting us down. > > We are currently the 'drive' scope which allow us to access all the files > of > the users. This is the scope that google doesn't want us to use anymore. > > The alternatives proposed by google are: > > - drive.appdata: this allow only to access an app specific folder to store > app > specific data. It's fine if you want to sync app data between an app on > multiple > platforms but not much more. > > - drive.file: this is more a file picker API where the user can select a > file and > allow the application to use it. Again not helpful for a sync client > > See https://developers.google.com/drive/api/guides/api-specific-auth > > So we need to submit for re-verification and hope they allow us to > continue > using the API. We seen to be an allowed use-case according to their doc: > > > https://developers.google.com/workspace/workspace-api-user-data-developer-policy#appropriate_access_to_and_use_ofs > > But it still requires some non-technical work: > > - Create a video of the gdrive workflow including the login and oauth > process > - An annual security assessment (not sure how hard it is to pass and > hopefully > it is free...) > > See: > > https://support.google.com/cloud/answer/13464321?sjid=5292936327783040555-EU# > https://support.google.com/cloud/answer/13465431 > > I can probably help a bit with e.g. doing the video but starting the > process > needs to be done by someone who has access to the google account (probably > the > board). > > Cheers, > Carl > > > > > Nate > > > > >
Re: Interest in building an LLM frontend for KDE
just saw this thread, and thought i should comment in on it, hope it comes to the right place when replying direct to ml.. the most important thing about LLM's (private or public) is that they do not become a strong dependency integrated in other stuff, thinking mainly on the info about KTextAddons that still requires to configure a API key for it to work, that is acceptable solution. some people might want chatgpt, or a private LLM (intra corp, or intra kde community, or even private personal LLM etc) and it might be a nice addon, but only as long as the computer never sends anything to the LLM without the users explicit permission. freedom of choice is the most important thing here, preferably with a system (or user) wide choice to disable use of LLMs on current computer. Regards Björn
