Re: kf6 deconflictor progress
I've updated the deconflictor now https://build.neon.kde.org/job/test_kf6_deconflictor/lastSuccessfulBuild/artifact/conflict-report.json/*view*/ On Tue, 2 May 2023 at 09:35, David Edmundson wrote: > On Fri, Apr 28, 2023 at 5:59 PM Jonathan Riddell wrote: > > > > The deconflictor job we run in neon still has a bunch of files > overlapping between kf5 and kf6 > > > > https://build.neon.kde.org/job/test_kf6_deconflictor/ > > > > > https://build.neon.kde.org/job/test_kf6_deconflictor/9/artifact/conflict-report.json/*view*/ > > > > Is there any progress being made in fixing this? > > Any, yes. > Obviously it's not done yet. > > I'm not sure this report is up to date: > > "/usr/kf6/bin/kglobalaccel5", > "/usr/bin/kglobalaccel5" > > I can't see us installing that. > > > We'd like to move the neon packages into /usr which would break our > deconflicting report job. > > You know how to make progress faster :) > > > Jonathan > > >
Re: developer account set up
On Tue, 2023-05-09 at 10:57 +0200, Johnny Jazeix wrote: > > I remember when we were integrating Gitlab at work, people for some reason > > were > > attempting to create branches in the upstream repo rather than on their own > > fork. Had to do some explanation that this isn't the way to go, because > > after an > > year of such workflow upstream will end up with hundreds if not thousands of > > abandoned branches that serve no purpose, and who's gonna clean that up > > 路♂️ > > Especially given that people may come and go, and so in some cases you > > wouldn't > > even find an author of a branch (and in some cases it's hard to even figure > > out > > who could be the author in the first place). > > > > > The issues you mentioned are the same with forks. Instead of having abandoned > branches in the main repo where maintainers could know if they are active or > not, we will have abandoned branches in abandoned repositories without MR to > know they exist and they would need to be cleaned. A fork belongs to a user account though. That knowledge simplifies cleaning process as for example one could send to the user a notification saying that their fork has not seen any activity in months and asking if it's still needed. And then in absence of answer for some determined amount of time to delete the fork.
Re: developer account set up
Hi, Le dim. 7 mai 2023 à 17:54, Konstantin Kharlamov a écrit : > On Sun, 2023-05-07 at 17:21 +0200, Nate Graham wrote: > > There's also no reason anymore why they need to use a work branch in the > > main repo; a fork works just fine. I do nearly all of my development > > using personal forks; it's a 100% supported first-class citizen > experience. > > +1 > > Ok for me to go with forks for GSoC but as Ben said, we probably need to find something about abandoned forks. I remember when we were integrating Gitlab at work, people for some reason > were > attempting to create branches in the upstream repo rather than on their own > fork. Had to do some explanation that this isn't the way to go, because > after an > year of such workflow upstream will end up with hundreds if not thousands > of > abandoned branches that serve no purpose, and who's gonna clean that up > 路♂️ > Especially given that people may come and go, and so in some cases you > wouldn't > even find an author of a branch (and in some cases it's hard to even > figure out > who could be the author in the first place). > The issues you mentioned are the same with forks. Instead of having abandoned branches in the main repo where maintainers could know if they are active or not, we will have abandoned branches in abandoned repositories without MR to know they exist and they would need to be cleaned. Cheers, Johnny
