Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Fri, Aug 4, 2017 at 10:18 PM, Eike Hein wrote: > > It's kind of a daft request maybe, but could you take some good > screenshots of the system's screens before it's shut down and add > it somewhere to your sysadmin docs? > > I think it's nice to create some institutional memory when we retire > systems like this. The next time someone has to implement a commit > notification thingie for KDE, they have more old systems to look at > for inspiration. It was also in use a really long time and was part > of our dev culture; I can see historical value, e.g. a sysadmin > using them in a dfaure-style presentation of the history of our > infrastructure at some point. I think we can arrange that. It was intended for SVN so some bits of it don't really apply anymore in a Git era but we can certainly take some snapshots. > > Memory is important, without it we squander the advantages of being > a community with history :) Last chance for anyone with any objections - i'll be starting the dismantling process tomorrow morning (my time). > > > Cheers, > Eike > Cheers, Ben > > On 08/04/2017 06:39 PM, Ben Cooksley wrote: >> Hi all, >> >> Does anyone have any further feedback on this? >> >> If no objections are raised in the next 24 hours we'll be proceeding >> with the archival and shutdown process. >> >> Regards, >> Ben >>
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
It's kind of a daft request maybe, but could you take some good screenshots of the system's screens before it's shut down and add it somewhere to your sysadmin docs? I think it's nice to create some institutional memory when we retire systems like this. The next time someone has to implement a commit notification thingie for KDE, they have more old systems to look at for inspiration. It was also in use a really long time and was part of our dev culture; I can see historical value, e.g. a sysadmin using them in a dfaure-style presentation of the history of our infrastructure at some point. Memory is important, without it we squander the advantages of being a community with history :) Cheers, Eike On 08/04/2017 06:39 PM, Ben Cooksley wrote: > Hi all, > > Does anyone have any further feedback on this? > > If no objections are raised in the next 24 hours we'll be proceeding > with the archival and shutdown process. > > Regards, > Ben >
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Hi all, Does anyone have any further feedback on this? If no objections are raised in the next 24 hours we'll be proceeding with the archival and shutdown process. Regards, Ben
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Mon, Jul 31, 2017 at 9:38 AM, Albert Astals Cid wrote: > El diumenge, 30 de juliol de 2017, a les 17:44:31 CEST, Boudewijn Rempt va > escriure: >> Nah, it isn't that important. Just subscribe to the commits mailing list >> and add some rules to your email client to separate out the various >> repositories is easy enough. _If_ the commit filter were really important, >> someone would have maintained it, right? If there's no maintainer, there's >> no importance. > > I never felt the need to step up as maintainer as it simply works (for me) and > I did not see the calls for maintainership if they did happen. While not a full formal call for assistance, on March 14 on the kde-devel mailing list I asked for anyone interested in working on commitfilter to please contact me. There were some casual references in other communication as well I think. > > What is not clear is if the emails i'm getting when someone commits to e.g > Okular or kgeography come from here or from somewhere else. > > How do i know where they come from? This can be done by examining the email headers. How you access those is dependent on your specific mail client, but you'll see it passing through a system called "kdeget.osuosl.org" if it is coming from commitfilter. > > Cheers, > Albert Cheers, Ben > >> >> On Sun, 30 Jul 2017, Gilles Caulier wrote: >> > Hi all, >> > >> > Idem for me with digiKam. Commit filter is a main tool used to follow >> > all contributors and see if something is badly done with commits. It's >> > main rules for open source project with a large amount of code, and a >> > lots of coder (as students) >> > >> > Please reconsider to revival this important piece of software. It's >> > very important... >> > >> > Best >> > >> > Gilles Caulier >> > >> > 2017-07-30 13:34 GMT+02:00 Dominik Haumann : >> > > Hi, >> > > >> > > On Sat, Jul 29, 2017 at 1:28 PM, Ben Cooksley wrote: >> > >> Hi all, >> > >> [...] >> > >> Due to the age of the system and the limited use of the two services >> > >> hosted on the system (with SVN Commitfilter having very limited >> > >> application since our migration to Git) we've determined that the best >> > >> course of action is to archive both services and shutdown the machine. >> > >> [...] >> > > >> > > I am still using commit-filter to read all diffs for kate.git, >> > > syntax-highlighting.git, >> > > ktexteditor.git, and some dedicated authors. >> > > >> > > For me, commit-filter was always a very convenient way of tracking KDE >> > > development, and subscribing to some git on phabricator is not good >> > > enough >> > > for me (I like the current form of generated mails much more). >> > > >> > > Is the solution to subscribe to all kde-comm...@kde.org, and then do the >> > > filtering myself, or is there still another way / or any plans to get >> > > commit-filter >> > > back? >> > > >> > > Greetings >> > > Dominik > >
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
El diumenge, 30 de juliol de 2017, a les 17:44:31 CEST, Boudewijn Rempt va escriure: > Nah, it isn't that important. Just subscribe to the commits mailing list > and add some rules to your email client to separate out the various > repositories is easy enough. _If_ the commit filter were really important, > someone would have maintained it, right? If there's no maintainer, there's > no importance. I never felt the need to step up as maintainer as it simply works (for me) and I did not see the calls for maintainership if they did happen. What is not clear is if the emails i'm getting when someone commits to e.g Okular or kgeography come from here or from somewhere else. How do i know where they come from? Cheers, Albert > > On Sun, 30 Jul 2017, Gilles Caulier wrote: > > Hi all, > > > > Idem for me with digiKam. Commit filter is a main tool used to follow > > all contributors and see if something is badly done with commits. It's > > main rules for open source project with a large amount of code, and a > > lots of coder (as students) > > > > Please reconsider to revival this important piece of software. It's > > very important... > > > > Best > > > > Gilles Caulier > > > > 2017-07-30 13:34 GMT+02:00 Dominik Haumann : > > > Hi, > > > > > > On Sat, Jul 29, 2017 at 1:28 PM, Ben Cooksley wrote: > > >> Hi all, > > >> [...] > > >> Due to the age of the system and the limited use of the two services > > >> hosted on the system (with SVN Commitfilter having very limited > > >> application since our migration to Git) we've determined that the best > > >> course of action is to archive both services and shutdown the machine. > > >> [...] > > > > > > I am still using commit-filter to read all diffs for kate.git, > > > syntax-highlighting.git, > > > ktexteditor.git, and some dedicated authors. > > > > > > For me, commit-filter was always a very convenient way of tracking KDE > > > development, and subscribing to some git on phabricator is not good > > > enough > > > for me (I like the current form of generated mails much more). > > > > > > Is the solution to subscribe to all kde-comm...@kde.org, and then do the > > > filtering myself, or is there still another way / or any plans to get > > > commit-filter > > > back? > > > > > > Greetings > > > Dominik
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Nah, it isn't that important. Just subscribe to the commits mailing list and add some rules to your email client to separate out the various repositories is easy enough. _If_ the commit filter were really important, someone would have maintained it, right? If there's no maintainer, there's no importance. On Sun, 30 Jul 2017, Gilles Caulier wrote: > Hi all, > > Idem for me with digiKam. Commit filter is a main tool used to follow > all contributors and see if something is badly done with commits. It's > main rules for open source project with a large amount of code, and a > lots of coder (as students) > > Please reconsider to revival this important piece of software. It's > very important... > > Best > > Gilles Caulier > > 2017-07-30 13:34 GMT+02:00 Dominik Haumann : > > Hi, > > > > On Sat, Jul 29, 2017 at 1:28 PM, Ben Cooksley wrote: > >> Hi all, > >> [...] > >> Due to the age of the system and the limited use of the two services > >> hosted on the system (with SVN Commitfilter having very limited > >> application since our migration to Git) we've determined that the best > >> course of action is to archive both services and shutdown the machine. > >> [...] > > > > I am still using commit-filter to read all diffs for kate.git, > > syntax-highlighting.git, > > ktexteditor.git, and some dedicated authors. > > > > For me, commit-filter was always a very convenient way of tracking KDE > > development, and subscribing to some git on phabricator is not good enough > > for me (I like the current form of generated mails much more). > > > > Is the solution to subscribe to all kde-comm...@kde.org, and then do the > > filtering myself, or is there still another way / or any plans to get > > commit-filter > > back? > > > > Greetings > > Dominik > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Hi all, Idem for me with digiKam. Commit filter is a main tool used to follow all contributors and see if something is badly done with commits. It's main rules for open source project with a large amount of code, and a lots of coder (as students) Please reconsider to revival this important piece of software. It's very important... Best Gilles Caulier 2017-07-30 13:34 GMT+02:00 Dominik Haumann : > Hi, > > On Sat, Jul 29, 2017 at 1:28 PM, Ben Cooksley wrote: >> Hi all, >> [...] >> Due to the age of the system and the limited use of the two services >> hosted on the system (with SVN Commitfilter having very limited >> application since our migration to Git) we've determined that the best >> course of action is to archive both services and shutdown the machine. >> [...] > > I am still using commit-filter to read all diffs for kate.git, > syntax-highlighting.git, > ktexteditor.git, and some dedicated authors. > > For me, commit-filter was always a very convenient way of tracking KDE > development, and subscribing to some git on phabricator is not good enough > for me (I like the current form of generated mails much more). > > Is the solution to subscribe to all kde-comm...@kde.org, and then do the > filtering myself, or is there still another way / or any plans to get > commit-filter > back? > > Greetings > Dominik
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Hi, On Sat, Jul 29, 2017 at 1:28 PM, Ben Cooksley wrote: > Hi all, > [...] > Due to the age of the system and the limited use of the two services > hosted on the system (with SVN Commitfilter having very limited > application since our migration to Git) we've determined that the best > course of action is to archive both services and shutdown the machine. > [...] I am still using commit-filter to read all diffs for kate.git, syntax-highlighting.git, ktexteditor.git, and some dedicated authors. For me, commit-filter was always a very convenient way of tracking KDE development, and subscribing to some git on phabricator is not good enough for me (I like the current form of generated mails much more). Is the solution to subscribe to all kde-comm...@kde.org, and then do the filtering myself, or is there still another way / or any plans to get commit-filter back? Greetings Dominik
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Sun, Jul 30, 2017 at 6:35 PM, Martin Flöser wrote: > Am 2017-07-29 22:18, schrieb Ben Cooksley: >> >> On Sun, Jul 30, 2017 at 3:33 AM, Olaf Schmidt-Wischhöfer >> wrote: >>> >>> Ben Cooksley: I've checked and it appears that only a small handful of applications still use newstuff.kde.org: - KBlocks - KDiamond - KGoldRunner - Kigo - KSirk - KSnakeDuel - KSysguard These applications should all be ported to use store.kde.org. >>> >>> >>> How long will it take for users to get the updates? And are we planning >>> to ignore users on, for example, Debian? >> >> >> That is up to distributions. Unfortunately we need to break things >> from time to time on the server side. >> >> As I mentioned, the web server for newstuff.kde.org has been down for >> several months, so this just makes the current arrangements permanent. >> >> If we had to wait until all users were able to receive an update to >> change something like this we would never be able to make any changes >> to our systems. To give an example, the original GetHotNewStuff >> implementation as used by many KDE 3 and early KDE 4 applications >> still receives a large number of requests. > > > But that is a point for not breaking it! If we still have users, we > shouldn't break it! Then I can tell you that in some cases making any change would be absolutely impossible. I have to choose between maintainability of our infrastructure and compatibility, and in this case maintainability wins out. To give some examples... we would never have been able to upgrade to Bugzilla 4 if your above requirement had to remain true. DrKonqi until our conversion to Bugzilla 4 (which introduced the REST API) was reliant on scraping the web pages. The content and layout of those pages were changed by the upgrade. We kept compatibility measures in place within Bugzilla 4 for a good 2 years or so to avoid that breakage. There is a cost to that (modifications to the Bugzilla core code, along with tweaks to the theme - all of which had to be merged on each update including security updates). As another example, moving resources fetched by applications has caused us issues in the past. I can cause at least one application to crash simply by removing one line from an Apache config. In another case we had to put a cronjob in place to copy metadata files from one system (with lots of disk space) to the old location which older versions of an application reference to keep them working. These changes have to be maintained, taken into account when making changes to other systems, and carried over when we perform system migrations and upgrades. Both of those issues were due to developers using QNetworkAccessManager, which by default, doesn't enable redirects. The Qt Installer Framework uses QNetworkAccessManager to make HTTP requests, and crashes whenever it gets hit with a redirect (at least in it's Qt 4 variant). The reason the legacy gethotnewstuff system still works is because it uses static files (which have no maintenance cost) and it uses KIO on the client side - which handles redirects correctly. The maintenance cost to Sysadmin of it is basically nil. What you're essentially asking here is for Sysadmin to takeover maintenance responsibility for a set of scripts which we don't fully understand, which have been hardcoded to use Postgres (a system which isn't really used by us) and which may have other unknown dependencies. That seems a bit unreasonable to me. > > Seriously that is one of the points where we can significantly differ from > proprietary providers where random stuff breaks because services get shut > down. > > Is there no way to redirect it in a way that it can continue to work? Unfortunately no. >From what I can tell, newstuff.kde.org speaks the OCS protocol, which in applications is handled by the Attica library (through knewstuff). Unfortunately Attica uses QNetworkAccessManager and redirect handling was only added sometime last year, and only to the Qt 5 variant. KWin 4.11 is forever stuck using a Qt 4 version of Attica, which can't handle redirects. It might even crash if we try to do redirects. We can't even do upgrades to HTTPS (which is enforced on all the servers Sysadmin maintains with few exceptions). > > Cheers > Martin Regards, Ben
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Am 2017-07-29 22:18, schrieb Ben Cooksley: On Sun, Jul 30, 2017 at 3:33 AM, Olaf Schmidt-Wischhöfer wrote: Ben Cooksley: I've checked and it appears that only a small handful of applications still use newstuff.kde.org: - KBlocks - KDiamond - KGoldRunner - Kigo - KSirk - KSnakeDuel - KSysguard These applications should all be ported to use store.kde.org. How long will it take for users to get the updates? And are we planning to ignore users on, for example, Debian? That is up to distributions. Unfortunately we need to break things from time to time on the server side. As I mentioned, the web server for newstuff.kde.org has been down for several months, so this just makes the current arrangements permanent. If we had to wait until all users were able to receive an update to change something like this we would never be able to make any changes to our systems. To give an example, the original GetHotNewStuff implementation as used by many KDE 3 and early KDE 4 applications still receives a large number of requests. But that is a point for not breaking it! If we still have users, we shouldn't break it! Seriously that is one of the points where we can significantly differ from proprietary providers where random stuff breaks because services get shut down. Is there no way to redirect it in a way that it can continue to work? Cheers Martin
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Sun, Jul 30, 2017 at 5:38 AM, Martin Flöser wrote: > Am 2017-07-29 13:28, schrieb Ben Cooksley: >> >> Hi all, >> >> Last year sysadmin was given access to the system which hosts the SVN >> Commitfilter (which lived at commitfilter.kde.org) and the predecessor >> to the OCS network of sites (now store.kde.org). >> >> Earlier this year we started having some issues with that system >> courtesy of some bots. As a consequence of this the web server >> component of the machine was disabled then to limit issues it was >> causing for the hoster. >> >> Due to the age of the system and the limited use of the two services >> hosted on the system (with SVN Commitfilter having very limited >> application since our migration to Git) we've determined that the best >> course of action is to archive both services and shutdown the machine. >> >> I've checked and it appears that only a small handful of applications >> still use newstuff.kde.org: >> - KBlocks >> - KDiamond >> - KGoldRunner >> - Kigo >> - KSirk >> - KSnakeDuel >> - KSysguard >> >> These applications should all be ported to use store.kde.org. > > > Does that mean all those applications our users use will have GHNS broken? > New software does not magically get installed on users systems. The GHNS support in the above mentioned applications will be broken yes. Any older releases of other applications which relied on newstuff.kde.org (you can check your knsrc files to confirm this) will also be affected. As I mentioned in my earlier email, this is simply making current arrangements permanent, as they're already broken due to the web server being down. > > Could you please clarify what this will mean e.g. for users of KWin 4.11? > Will GHNS still work or will it be broken due to the service being shut > down. If KWin 4.11 uses newstuff.kde.org then GHNS will have ceased to work for those users several months back. If it used kde-look.org / store.kde.org or download.kde.org/khotnewstuff/ as the url in it's knsrc then it will not be affected. > > Cheers > Martin Cheers, Ben
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Sun, Jul 30, 2017 at 3:33 AM, Olaf Schmidt-Wischhöfer wrote: > Ben Cooksley: >>I've checked and it appears that only a small handful of applications >>still use newstuff.kde.org: >>- KBlocks >>- KDiamond >>- KGoldRunner >>- Kigo >>- KSirk >>- KSnakeDuel >>- KSysguard >> >>These applications should all be ported to use store.kde.org. > > How long will it take for users to get the updates? And are we planning to > ignore users on, for example, Debian? That is up to distributions. Unfortunately we need to break things from time to time on the server side. As I mentioned, the web server for newstuff.kde.org has been down for several months, so this just makes the current arrangements permanent. If we had to wait until all users were able to receive an update to change something like this we would never be able to make any changes to our systems. To give an example, the original GetHotNewStuff implementation as used by many KDE 3 and early KDE 4 applications still receives a large number of requests. The original GHNS system produced static files, which is why it can continue to function (it doesn't get any new updates). The implementation on newstuff.kde.org is dynamic and therefore can't be retained. > > Another question: The KDE website still uses SVN and used to auto-update > after commits. Will this continue to work? That will continue to work, our systems communicate directly to action that. > > Best regards, Olaf Cheers, Ben
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Am 2017-07-29 13:28, schrieb Ben Cooksley: Hi all, Last year sysadmin was given access to the system which hosts the SVN Commitfilter (which lived at commitfilter.kde.org) and the predecessor to the OCS network of sites (now store.kde.org). Earlier this year we started having some issues with that system courtesy of some bots. As a consequence of this the web server component of the machine was disabled then to limit issues it was causing for the hoster. Due to the age of the system and the limited use of the two services hosted on the system (with SVN Commitfilter having very limited application since our migration to Git) we've determined that the best course of action is to archive both services and shutdown the machine. I've checked and it appears that only a small handful of applications still use newstuff.kde.org: - KBlocks - KDiamond - KGoldRunner - Kigo - KSirk - KSnakeDuel - KSysguard These applications should all be ported to use store.kde.org. Does that mean all those applications our users use will have GHNS broken? New software does not magically get installed on users systems. Could you please clarify what this will mean e.g. for users of KWin 4.11? Will GHNS still work or will it be broken due to the service being shut down. Cheers Martin
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Ben Cooksley: >I've checked and it appears that only a small handful of applications >still use newstuff.kde.org: >- KBlocks >- KDiamond >- KGoldRunner >- Kigo >- KSirk >- KSnakeDuel >- KSysguard > >These applications should all be ported to use store.kde.org. How long will it take for users to get the updates? And are we planning to ignore users on, for example, Debian? Another question: The KDE website still uses SVN and used to auto-update after commits. Will this continue to work? Best regards, Olaf
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Ben Cooksley ha scritto: > On Sat, Jul 29, 2017 at 11:33 PM, Luigi Toscano > wrote: >> Ben Cooksley ha scritto: >> >>> I've checked and it appears that only a small handful of applications >>> still use newstuff.kde.org: >>> - KBlocks >>> - KDiamond >>> - KGoldRunner >>> - Kigo >>> - KSirk >>> - KSnakeDuel >>> - KSysguard >>> >>> These applications should all be ported to use store.kde.org. >> >> We have few days to fix most of them (the games part of Applications 17.08.0; >> KSysguard is Plasma). Can you wait please few days so that we can fix them >> properly (and compare the before/after)? > > The web interface for newstuff.kde.org has been down for the past > couple of months, so these applications should have been broken for a > while now. We certainly can wait for a couple of days though. Ben confirmed on IRC that the web server was up for few days by accident after a system restart. So when I tested the affected games few days ago during Akademy and everything worked, I thought that the issue was fixed. I requested the new categories for the games, including few answer on how to migrate the existing contents without contacting each of the old authors: https://phabricator.kde.org/T6675 I didn't create it the request for KSysguard because I'm not sure about the category, it's better if the Plasma team chimes in. Ciao -- Luigi
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
On Sat, Jul 29, 2017 at 11:33 PM, Luigi Toscano wrote: > Ben Cooksley ha scritto: >> Hi all, >> >> Last year sysadmin was given access to the system which hosts the SVN >> Commitfilter (which lived at commitfilter.kde.org) and the predecessor >> to the OCS network of sites (now store.kde.org). >> >> Earlier this year we started having some issues with that system >> courtesy of some bots. As a consequence of this the web server >> component of the machine was disabled then to limit issues it was >> causing for the hoster. >> >> Due to the age of the system and the limited use of the two services >> hosted on the system (with SVN Commitfilter having very limited >> application since our migration to Git) we've determined that the best >> course of action is to archive both services and shutdown the machine. > > (I think that the answer is "no", but): does it affect that IRC notifications? IRC Notifications are handled through a separate mechanism so they won't be affected by this. You can change the rules surrounding commit, bug and CI notifications by changing the appropriate notifications.cfg files in https://cgit.kde.org/sysadmin/irc-notifications.git > > It's worth noting that when we will switch to Phabricator for handling SVN > too, we could build something around it instead of some custom code. Indeed. Phabricator has an application called Herald which could conceivably do this (only it's much, much more powerful - if you see 'Restricted Application' in your review or task emails that's Herald). Unfortunately however there is a performance penalty to be paid of 1ms per Herald rule for each action taken in Phabricator - something that would impact on commenting on tasks and reviews among other things. This is why we have restricted it to only broader community wide actions (like adding project mailing lists) at the moment. > >> I've checked and it appears that only a small handful of applications >> still use newstuff.kde.org: >> - KBlocks >> - KDiamond >> - KGoldRunner >> - Kigo >> - KSirk >> - KSnakeDuel >> - KSysguard >> >> These applications should all be ported to use store.kde.org. > > We have few days to fix most of them (the games part of Applications 17.08.0; > KSysguard is Plasma). Can you wait please few days so that we can fix them > properly (and compare the before/after)? The web interface for newstuff.kde.org has been down for the past couple of months, so these applications should have been broken for a while now. We certainly can wait for a couple of days though. > > Ciao > -- > Luigi Cheers, Ben
Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Ben Cooksley ha scritto: > Hi all, > > Last year sysadmin was given access to the system which hosts the SVN > Commitfilter (which lived at commitfilter.kde.org) and the predecessor > to the OCS network of sites (now store.kde.org). > > Earlier this year we started having some issues with that system > courtesy of some bots. As a consequence of this the web server > component of the machine was disabled then to limit issues it was > causing for the hoster. > > Due to the age of the system and the limited use of the two services > hosted on the system (with SVN Commitfilter having very limited > application since our migration to Git) we've determined that the best > course of action is to archive both services and shutdown the machine. (I think that the answer is "no", but): does it affect that IRC notifications? It's worth noting that when we will switch to Phabricator for handling SVN too, we could build something around it instead of some custom code. > I've checked and it appears that only a small handful of applications > still use newstuff.kde.org: > - KBlocks > - KDiamond > - KGoldRunner > - Kigo > - KSirk > - KSnakeDuel > - KSysguard > > These applications should all be ported to use store.kde.org. We have few days to fix most of them (the games part of Applications 17.08.0; KSysguard is Plasma). Can you wait please few days so that we can fix them properly (and compare the before/after)? Ciao -- Luigi
Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems
Hi all, Last year sysadmin was given access to the system which hosts the SVN Commitfilter (which lived at commitfilter.kde.org) and the predecessor to the OCS network of sites (now store.kde.org). Earlier this year we started having some issues with that system courtesy of some bots. As a consequence of this the web server component of the machine was disabled then to limit issues it was causing for the hoster. Due to the age of the system and the limited use of the two services hosted on the system (with SVN Commitfilter having very limited application since our migration to Git) we've determined that the best course of action is to archive both services and shutdown the machine. I've checked and it appears that only a small handful of applications still use newstuff.kde.org: - KBlocks - KDiamond - KGoldRunner - Kigo - KSirk - KSnakeDuel - KSysguard These applications should all be ported to use store.kde.org. Does anyone have any comments before we begin actioning this change? Regards, Ben Cooksley KDE Sysadmin
