https://invent.kde.org/graphics/kuickshow and imlib1
Hello,
1. Can someone build kuickshow? If so, how?
2. Can we please archive https://invent.kde.org/graphics/kuickshow ?
Thanks.
Technical details:
Maybe I got something wrong, but.
https://invent.kde.org/graphics/kuickshow seems to depend on imlib1 . Which
is https://download.gnome.org/sources/imlib/1.9/ imlib-1.9.15.tar.bz2 667.2
KiB 2004-Sep-24 14:45
imlib1 is no longer packaged by Debian or Ubuntu. I cannot build it from
source code "load.c:579:3: error: too few arguments to function
'DGifCloseFile'", "load.c:194:21: error: invalid use of incomplete typedef
'png_struct' {aka 'struct png_struct_def'}".
In fact kuickshow is a wrapper around imlib1/imlibwidget.cpp.
https://docs.enlightenment.org/api/imlib2/html/ says "Imlib 2 is the
successor to Imlib. It is NOT a newer version - it is a completely new
library.", "Date: 1999-2004". So, Rasterman is trying to replace imlib1
with something better since 1999.
Re: Incubating app (Git Klient)
El dimarts, 23 d’agost de 2022, a les 23:11:52 (CEST), Hamed Masafi va escriure: > Thanks, what's the next step? Should I wait for someone to announce his > readiness to be sponsored? Yes, that's it. I will sponsor you since it seems no one else is willing. I'll send you an email in private tomorrow. Cheers, Albert > > On Tue, Aug 23, 2022, 13:28 Jeremy Whiting wrote: > > Tried to send this earlier, but used the wrong address, so it got stuck in > > moderation possibly: > > > > A sponsor is a KDE developer who will walk you through getting a developer > > account, getting code reviewed, going over the different release > > mechanisms, etc. to decide how best to become an official application. > > > > On Mon, Aug 22, 2022 at 3:20 PM samuel ammonius > > > > wrote: > >> From my current understanding, a sponsor is a KDE developer who works > >> with KDE's GitLab managers to make a new repo for your project and make > >> you > >> a KDE developer. > >> > >> On Mon, Aug 22, 2022 at 5:14 PM Hamed Masafi > >> > >> wrote: > >>> What is a sponsor and what does it do? > >>> > >>> On Mon, Aug 22, 2022, 21:00 Harald Sitter wrote: > Heya, > > You'll need a sponsor https://community.kde.org/Incubator ... not me. > I'm lazy :) > > On Sun, Aug 21, 2022 at 11:01 AM Hamed Masafi > > wrote: > > Hello > > As a longtime kde fan(since 3.4), I would love to contribute to this > > group. > > > I am developing a graphical client application for git. I think it is > > a good option to enter the world of kde. > > > Features of this program: > > - The icon displays the files in the Gate folder according to their > > status in Dolphin. > > > - For easier access to the right-click menu of files and folders, > > options such as pull, push, delete, ignore, etc. have been added. > > > - Graph display of commits. > > - General Git operations such as pull, push, fetch. > > - Show branches and distance of commits from the reference branch. > > - View files and file contents in each branch or commit. > > - Compare files, folders, branches and commits in a graphical > > environment. > > > - Merge conflicting files in git. > > - Management of remotes, tags. > > - Auto-completion when writing a commit message. > > - Markdown editor (written but not yet added to the main program) > > - And some extra features. > > > > The source is available here: > > https://github.com/HamedMasafi/GitKlient > > > > Currently, only I (Hamid Masafi) am working on the project. > > This project is currently on GitHub, but it can be moved to any other > > repository if approved by you. > > > Please take a look at this repository and let me know what you think. > > I look forward to hearing from you. > > > Best regards > > Hamed Masafi
Re: New releases for bugfixes
El dijous, 25 d’agost de 2022, a les 18:55:08 (CEST), Nate Graham va escriure: > Hello everyone, > Right now when we fix a significant bug in our software that may take a > while to reach users to to the release schedule of its repo, we contact > distros and ask them to backport it. This puts the burden on distros to > react to us. I'm wondering how people feel about KDE instead making > immediate point releases ourselves. Thus we would take responsibility > for releasing fixes for our own regressions, and distros that monitor > KDE infrastructure for new tarballs could be notified automatically. > > Thoughts? In theory it makes sense but there's some issues that need working out. a) Which version number to use if it's part of a (bigger release, Plasma, Frameworks, Gear). I guess the answer is to do x.y.z.k but we need to make sure all our tooling supports that b) Again, for repos that are part of a bigger release, this creates more work on the (from what i can see) relatively overloaded release folks so we may need to make sure this happens very seldom or recruit more releasers c) Who decides which bugs "are important" because for every bug, there's always a person out there that thinks it's the most important bug ever. d) What do we release? i.e. imagine we find one of those "important bugs" in dolphin and we have to release 22.08.0.1. Do we just release the 22.08 branch with any changes it may have had since the 22.08.0 release or do we create a special branch that only contains the new patch and release that? Cheers, Albert > > Nate
Re: libmediawiki release
El dijous, 25 d’agost de 2022, a les 22:25:50 (CEST), Jonathan Riddell va escriure: > Kipi plugins uses it, which we do still release. Fair enough, I hope no one will particularly object to a release of libmediawiki if we know it's in a releaseable state :) Cheers, Albert > > Jonathan > > On Thu, 25 Aug 2022 at 20:54, Albert Astals Cid wrote: > > El dijous, 25 d’agost de 2022, a les 14:11:31 (CEST), Jonathan Riddell va > > > > escriure: > > > libmediawiki release no longer compiles but there's fixes in git that > > > > make > > > > > it compile. Scarlett did the last release in 2017. Can I make a new > > > stable release from git? > > > > Does anything use libmediawiki ? Maybe it's better to just archive it? > > > > Cheers, > > > > Albert > > > > > Jonathan
Re: libmediawiki release
Kipi plugins uses it, which we do still release. Jonathan On Thu, 25 Aug 2022 at 20:54, Albert Astals Cid wrote: > El dijous, 25 d’agost de 2022, a les 14:11:31 (CEST), Jonathan Riddell va > escriure: > > libmediawiki release no longer compiles but there's fixes in git that > make > > it compile. Scarlett did the last release in 2017. Can I make a new > > stable release from git? > > Does anything use libmediawiki ? Maybe it's better to just archive it? > > Cheers, > Albert > > > > > Jonathan > > > > >
Re: libmediawiki release
El dijous, 25 d’agost de 2022, a les 14:11:31 (CEST), Jonathan Riddell va escriure: > libmediawiki release no longer compiles but there's fixes in git that make > it compile. Scarlett did the last release in 2017. Can I make a new > stable release from git? Does anything use libmediawiki ? Maybe it's better to just archive it? Cheers, Albert > > Jonathan
Re: New releases for bugfixes
Same here, I like the idea of point releases to fix impactful bugs. On Thu, Aug 25, 2022 at 6:56 PM Harald Sitter wrote: > make sense to me > > On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote: > > > > Hello everyone, > > Right now when we fix a significant bug in our software that may take a > > while to reach users to to the release schedule of its repo, we contact > > distros and ask them to backport it. This puts the burden on distros to > > react to us. I'm wondering how people feel about KDE instead making > > immediate point releases ourselves. Thus we would take responsibility > > for releasing fixes for our own regressions, and distros that monitor > > KDE infrastructure for new tarballs could be notified automatically. > > > > Thoughts? > > > > Nate >
Re: New releases for bugfixes
make sense to me On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote: > > Hello everyone, > Right now when we fix a significant bug in our software that may take a > while to reach users to to the release schedule of its repo, we contact > distros and ask them to backport it. This puts the burden on distros to > react to us. I'm wondering how people feel about KDE instead making > immediate point releases ourselves. Thus we would take responsibility > for releasing fixes for our own regressions, and distros that monitor > KDE infrastructure for new tarballs could be notified automatically. > > Thoughts? > > Nate
New releases for bugfixes
Hello everyone, Right now when we fix a significant bug in our software that may take a while to reach users to to the release schedule of its repo, we contact distros and ask them to backport it. This puts the burden on distros to react to us. I'm wondering how people feel about KDE instead making immediate point releases ourselves. Thus we would take responsibility for releasing fixes for our own regressions, and distros that monitor KDE infrastructure for new tarballs could be notified automatically. Thoughts? Nate
libmediawiki release
libmediawiki release no longer compiles but there's fixes in git that make it compile. Scarlett did the last release in 2017. Can I make a new stable release from git? Jonathan
Re: Loosening the commit limit for work branches
On Thu, Aug 25, 2022 at 9:27 PM Harald Sitter wrote: > On Wed, Aug 24, 2022 at 8:11 PM Ben Cooksley wrote: > > > > On Thu, Aug 25, 2022 at 2:16 AM Harald Sitter wrote: > >> > >> On Wed, Aug 24, 2022 at 3:31 PM Noah Davis wrote: > >> > > >> > A week ago, I ran into an unexpected issue while working on a QML port > >> > of Spectacle. There is an undocumented pre-receive hook that sets a > >> > 100 commit limit for all branches of official repos, including work > >> > branches. The error message it gave me told me to file a sysadmin > >> > ticket, so I did that. > >> > > >> > The sysadmin ticket link: https://phabricator.kde.org/T15683 > >> > > >> > I don't think I can make the ticket public, so here's the > conversation: > >> > > >> > --- Start of conversation > >> > > >> > ndavis (me): > >> > For normal branches, I would understand this since there were issues > >> > with spamming #kde-devel in the past. This isn't necessary for work > >> > branches, right? I thought the point of the work/ naming convention > >> > was to prevent this issue. > >> > > >> > bcooksley: > >> > Work branches weren't meant to be used for large feature developments > >> > with 100+ commits in them, which is why this is being blocked. > >> > In it's current state - even if rebased - the branch will not be able > >> > to be merged without Sysadmin intervention. > >> > Will this be squashed prior to being merged? > >> > > >> > ndavis: > >> > > Will this be squashed prior to being merged? > >> > > >> > Yes > >> > > >> > > Work branches weren't meant to be used for large feature > developments with 100+ commits in them, which is why this is being blocked. > >> > > >> > Is this documented anywhere? I don't understand why work branches > >> > would block this. The git message says notifications are the reason > >> > why the push was blocked, but I thought work branches didn't send > >> > notifications? > >> > > >> > bcooksley: > >> > The message is a little misleading, but that is mostly because this > >> > situation isn't supposed to really occur. You are correct that work > >> > branches don't send notifications. > >> > As such it is not documented anywhere. > >> > From a policy perspective the reason why we don't allow work branches > >> > to grow beyond 100 commits is because if we did then you would never > >> > be able to merge them in - not without squashing anyway. > >> > This therefore makes you "squash as you go". > >> > I would generally recommend that major features be developed in an > >> > ordinary branch to allow those that monitor kde-commits and other > >> > commit feeds to chime in with real-time reviews, and then merged using > >> > a traditional Git merge (vs. our more typical rebase) > >> > > >> > ndavis: > >> > > The message is a little misleading, but that is mostly because this > situation isn't supposed to really occur. You are correct that work > branches don't send notifications. As such it is not documented anywhere. > >> > > >> > If we are going to keep this limitation, we should document it so that > >> > nobody else makes the same mistake as me. We can't assume that > >> > something that isn't supposed to happen won't happen because there's > >> > no reason to assume this limitation would exist. > >> > > >> > > From a policy perspective the reason why we don't allow work > branches to grow beyond 100 commits is because if we did then you would > never be able to merge them in - not without squashing anyway. > >> > This therefore makes you "squash as you go". > >> > > >> > I don't understand why we have this policy. If we can't merge an MR > >> > with over 100 commits, why can't we just tell the person making an MR > >> > when they post the MR to squash it? I think it would make more sense > >> > for this policy to apply only when pushing to master or version > >> > branches. > >> > > >> > > I would generally recommend that major features be developed in an > ordinary branch to allow those that monitor kde-commits and other commit > feeds to chime in with real-time reviews, > >> > > >> > In my experience, nobody does that. Nobody has time to review unless > >> > you explicitly request help or you post an MR. > >> > I don't know the protocol for discussing these kinds of things, so let > >> > me know if this discussion should be moved elsewhere. > >> > > >> > --- End of conversation > >> > > >> > After this, I decided it would be better to discuss this with the > >> > broader KDE community and I closed the ticket. > >> > > >> > I did try to switch to a normal branch as Ben Cooksley suggested, but > >> > that had the same limitation. I have not tested using a fork, but some > >> > of the people I've talked to casually (I can't remember who) seemed to > >> > be saying that fork branches don't have this limitation, which I think > >> > would make the limit on work branches kind of pointless if it's true. > >> > > >> > I understand the concern about making unmergeable merge requests, but > >> > I don't think
Re: Loosening the commit limit for work branches
On Thu, Aug 25, 2022 at 7:13 AM David Hurka wrote: > On Wednesday, August 24, 2022 8:11:14 PM CEST Ben Cooksley wrote: > > The limitation is aligned with the maximum number of new commits you are > > allowed to introduce to a standard branch. > > We have those limits because the commit hooks carry out processing on a > per > > commit basis for all new commits introduced to standard branches - and > are > > there to protect all the other systems downstream from Gitlab. > > Do I understand it correctly like this? > > Standard branches have a merge hook. > The merge hook runs when commits are added to the branch. > (It is assumed that standard branches are not force pushed.) > The merge hook runs for every individual commit. > There is a limit that only 100 commits can be added at once, > to prevent system overloads caused by many merge hooks being ran at once. > It is a little simpler than that. For any push to a repository hosted on invent.kde.org, a Git hook known as "pre-receive" is invoked by Git on the server. This hook is provided by Gitlab itself and first carries out a number of checks needed for Gitlab itself to operate before it then invokes our pre-receive hook. Our pre-receive hook as part of it's setup determines whether it is on a mainline or personal repository and what in the repository is being modified (release branch, work branch, tag, etc). It checks the content of the push (an operation which is very streamlined) and then if necessary carries out the appropriate notification of our other systems. The systems themselves can handle the load fine, however the humans in the spaces they communicate to cannot as: a) Bugzilla receives an email for every single mention of BUG / CCBUG within every new commit (which notifies every person CCed on those bugs in turn) b) An email is sent to kde-comm...@kde.org for every new commit, which floods the list with excessive traffic c) A notification is sent to what used to be #kde-commits and #commits on Libera for each new commit (as well as some other channels for certain repositories) so those respective IRC/Matrix channels get flooded and rendered unusable by our announce bots. Further, as some email providers impose limits on the number of emails people can receive in short succession this can block delivery of email to people at certain providers (which affects all KDE.org mailing lists, as well as their personal KDE.org/KDEMail.net alias traffic). This essentially denies these people the ability to participate in the community for a period of time. Our hook can be found at https://invent.kde.org/sysadmin/repo-management/-/blob/master/hooks/invent.pre-receive for those curious as to what it does. Regards, Ben
KDE CI: Frameworks » kwayland » kf5-qt5 FreeBSDQt5.15 - Build # 190 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.15/190/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Thu, 25 Aug 2022 09:25:42 + Build duration: 6 min 2 sec and counting JUnit Tests Name: projectroot.autotests Failed: 13 test(s), Passed: 33 test(s), Skipped: 0 test(s), Total: 46 test(s)Failed: projectroot.autotests.client.kwayland_testCompositorFailed: projectroot.autotests.client.kwayland_testDataDeviceFailed: projectroot.autotests.client.kwayland_testDataSourceFailed: projectroot.autotests.client.kwayland_testRegionFailed: projectroot.autotests.client.kwayland_testShmPoolFailed: projectroot.autotests.client.kwayland_testSubCompositorFailed: projectroot.autotests.client.kwayland_testSubSurfaceFailed: projectroot.autotests.client.kwayland_testWaylandConnectionThreadFailed: projectroot.autotests.client.kwayland_testWaylandRegistryFailed: projectroot.autotests.client.kwayland_testWaylandSeatFailed: projectroot.autotests.client.kwayland_testWaylandShellFailed: projectroot.autotests.client.kwayland_testWaylandSurfaceFailed: projectroot.autotests.server.kwayland_testWaylandServerDisplay
KDE CI: Frameworks » kunitconversion » kf5-qt5 WindowsMSVCQt5.15 - Build # 133 - Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/kunitconversion/job/kf5-qt5%20WindowsMSVCQt5.15/133/ Project: kf5-qt5 WindowsMSVCQt5.15 Date of build: Thu, 25 Aug 2022 08:22:01 + Build duration: 1 hr 9 min and counting JUnit Tests Name: projectroot Failed: 4 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 4 test(s)Failed: projectroot.autotests.categorytestFailed: projectroot.autotests.convertertestFailed: projectroot.autotests.currencytableinittestFailed: projectroot.autotests.valuetest
Re: Loosening the commit limit for work branches
On Wed, Aug 24, 2022 at 8:11 PM Ben Cooksley wrote: > > On Thu, Aug 25, 2022 at 2:16 AM Harald Sitter wrote: >> >> On Wed, Aug 24, 2022 at 3:31 PM Noah Davis wrote: >> > >> > A week ago, I ran into an unexpected issue while working on a QML port >> > of Spectacle. There is an undocumented pre-receive hook that sets a >> > 100 commit limit for all branches of official repos, including work >> > branches. The error message it gave me told me to file a sysadmin >> > ticket, so I did that. >> > >> > The sysadmin ticket link: https://phabricator.kde.org/T15683 >> > >> > I don't think I can make the ticket public, so here's the conversation: >> > >> > --- Start of conversation >> > >> > ndavis (me): >> > For normal branches, I would understand this since there were issues >> > with spamming #kde-devel in the past. This isn't necessary for work >> > branches, right? I thought the point of the work/ naming convention >> > was to prevent this issue. >> > >> > bcooksley: >> > Work branches weren't meant to be used for large feature developments >> > with 100+ commits in them, which is why this is being blocked. >> > In it's current state - even if rebased - the branch will not be able >> > to be merged without Sysadmin intervention. >> > Will this be squashed prior to being merged? >> > >> > ndavis: >> > > Will this be squashed prior to being merged? >> > >> > Yes >> > >> > > Work branches weren't meant to be used for large feature developments >> > > with 100+ commits in them, which is why this is being blocked. >> > >> > Is this documented anywhere? I don't understand why work branches >> > would block this. The git message says notifications are the reason >> > why the push was blocked, but I thought work branches didn't send >> > notifications? >> > >> > bcooksley: >> > The message is a little misleading, but that is mostly because this >> > situation isn't supposed to really occur. You are correct that work >> > branches don't send notifications. >> > As such it is not documented anywhere. >> > From a policy perspective the reason why we don't allow work branches >> > to grow beyond 100 commits is because if we did then you would never >> > be able to merge them in - not without squashing anyway. >> > This therefore makes you "squash as you go". >> > I would generally recommend that major features be developed in an >> > ordinary branch to allow those that monitor kde-commits and other >> > commit feeds to chime in with real-time reviews, and then merged using >> > a traditional Git merge (vs. our more typical rebase) >> > >> > ndavis: >> > > The message is a little misleading, but that is mostly because this >> > > situation isn't supposed to really occur. You are correct that work >> > > branches don't send notifications. As such it is not documented anywhere. >> > >> > If we are going to keep this limitation, we should document it so that >> > nobody else makes the same mistake as me. We can't assume that >> > something that isn't supposed to happen won't happen because there's >> > no reason to assume this limitation would exist. >> > >> > > From a policy perspective the reason why we don't allow work branches to >> > > grow beyond 100 commits is because if we did then you would never be >> > > able to merge them in - not without squashing anyway. >> > This therefore makes you "squash as you go". >> > >> > I don't understand why we have this policy. If we can't merge an MR >> > with over 100 commits, why can't we just tell the person making an MR >> > when they post the MR to squash it? I think it would make more sense >> > for this policy to apply only when pushing to master or version >> > branches. >> > >> > > I would generally recommend that major features be developed in an >> > > ordinary branch to allow those that monitor kde-commits and other commit >> > > feeds to chime in with real-time reviews, >> > >> > In my experience, nobody does that. Nobody has time to review unless >> > you explicitly request help or you post an MR. >> > I don't know the protocol for discussing these kinds of things, so let >> > me know if this discussion should be moved elsewhere. >> > >> > --- End of conversation >> > >> > After this, I decided it would be better to discuss this with the >> > broader KDE community and I closed the ticket. >> > >> > I did try to switch to a normal branch as Ben Cooksley suggested, but >> > that had the same limitation. I have not tested using a fork, but some >> > of the people I've talked to casually (I can't remember who) seemed to >> > be saying that fork branches don't have this limitation, which I think >> > would make the limit on work branches kind of pointless if it's true. >> > >> > I understand the concern about making unmergeable merge requests, but >> > I don't think a hard 100 commit limit pre-recieve hook is the right >> > way to deal with that. That's something that should be handled by >> > reviewers, not automated systems, because sometimes info needs to be >>
KDE CI: Frameworks » kimageformats » kf5-qt5 WindowsMSVCQt5.15 - Build # 162 - Failure!
BUILD FAILURE Build URL https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20WindowsMSVCQt5.15/162/ Project: kf5-qt5 WindowsMSVCQt5.15 Date of build: Thu, 25 Aug 2022 08:06:36 + Build duration: 1 hr 7 min and counting CONSOLE OUTPUT [...truncated 233 lines...]remote: Compressing objects: 77% (149/193)remote: Compressing objects: 78% (151/193)remote: Compressing objects: 79% (153/193)remote: Compressing objects: 80% (155/193)remote: Compressing objects: 81% (157/193)remote: Compressing objects: 82% (159/193)remote: Compressing objects: 83% (161/193)remote: Compressing objects: 84% (163/193)remote: Compressing objects: 85% (165/193)remote: Compressing objects: 86% (166/193)remote: Compressing objects: 87% (168/193)remote: Compressing objects: 88% (170/193)remote: Compressing objects: 89% (172/193)remote: Compressing objects: 90% (174/193)remote: Compressing objects: 91% (176/193)remote: Compressing objects: 92% (178/193)remote: Compressing objects: 93% (180/193)remote: Compressing objects: 94% (182/193)remote: Compressing objects: 95% (184/193)remote: Compressing objects: 96% (186/193)remote: Compressing objects: 97% (188/193)remote: Compressing objects: 98% (190/193)remote: Compressing objects: 99% (192/193)remote: Compressing objects: 100% (193/193)remote: Compressing objects: 100% (193/193), done.[2022-08-25T09:14:12.000Z] Receiving objects: 0% (1/10930)Receiving objects: 0% (13/10930)Receiving objects: 0% (25/10930), 8.01 KiB | 1024 bytes/sReceiving objects: 0% (37/10930), 8.01 KiB | 1024 bytes/sReceiving objects: 0% (50/10930), 12.01 KiB | 1024 bytes/sReceiving objects: 0% (60/10930), 16.01 KiB | 2.00 KiB/s Receiving objects: 0% (70/10930), 16.01 KiB | 2.00 KiB/sReceiving objects: 0% (84/10930), 20.01 KiB | 2.00 KiB/sReceiving objects: 0% (102/10930), 24.01 KiB | 2.00 KiB/sReceiving objects: 1% (110/10930), 24.01 KiB | 2.00 KiB/sReceiving objects: 1% (122/10930), 28.01 KiB | 2.00 KiB/sReceiving objects: 1% (134/10930), 28.01 KiB | 2.00 KiB/sReceiving objects: 1% (150/10930), 32.01 KiB | 2.00 KiB/sReceiving objects: 1% (164/10930), 36.01 KiB | 2.00 KiB/sReceiving objects: 1% (178/10930), 40.01 KiB | 2.00 KiB/sReceiving objects: 1% (194/10930), 40.01 KiB | 2.00 KiB/sReceiving objects: 1% (212/10930), 44.01 KiB | 2.00 KiB/sReceiving objects: 2% (219/10930), 48.01 KiB | 2.00 KiB/sReceiving objects: 2% (228/10930), 48.01 KiB | 2.00 KiB/sReceiving objects: 2% (253/10930), 52.01 KiB | 2.00 KiB/sReceiving objects: 2% (276/10930), 56.01 KiB | 3.00 KiB/sReceiving objects: 2% (293/10930), 60.01 KiB | 3.00 KiB/serror: RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 10054[2022-08-25T09:14:12.000Z] Receiving objects: 2% (308/10930), 64.01 KiB | 3.00 KiB/sReceiving objects: 3% (328/10930), 68.01 KiB | 3.00 KiB/sfatal: the remote end hung up unexpectedly[2022-08-25T09:14:12.000Z] Receiving objects: 3% (375/10930), 76.01 KiB | 3.00 KiB/sfatal: early EOF[2022-08-25T09:14:12.000Z] fatal: index-pack failed[2022-08-25T09:14:12.000Z] [2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2450)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2051)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:84)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:573)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:802)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)[2022-08-25T09:14:12.000Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)[2022-08-25T09:14:12.000Z] at hudson.remoting.UserRequest.perform(UserRequest.java:211)[2022-08-25T09:14:12.000Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54)[2022-08-25T09:14:12.000Z] at hudson.remoting.Request$2.run(Request.java:369)[2022-08-25T09:14:12.000Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)[2022-08-25T09:14:12.000Z] at java.util.concurrent.FutureTask.run(Unknown Source)[2022-08-25T09:14:12.000Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)[2022-08-25T09:14:12.000Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)[2022-08-25T09:14:12.000Z] at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:98)[2022-08-25T09:14:12.000Z] at
Re: Loosening the commit limit for work branches
On woensdag 24 augustus 2022 17:12:51 CEST Milian Wolff wrote: > sooner or later you should hit a small mile stone that you can merge already Um, no? Like, no way, not at all? As in quite often, a rewrite is way bigger than that. I merged one this year that took three years of coding...
