On Thu, Feb 2, 2017 at 6:17 PM, Ben Cooksley <bcooks...@kde.org> wrote: > On Thu, Feb 2, 2017 at 11:51 PM, Harald Sitter <sit...@kde.org> wrote: >> On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley <bcooks...@kde.org> wrote: >>> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano <luigi.tosc...@tiscali.it> >>> wrote: >>>> Il 02.02.2017 10:09 Ben Cooksley ha scritto: >>>> >>>>> Hi all, >>>>> >>>>> As a starting point: keeping the software itself running is a >>>>> non-starting option from my perspective. It's going to be shutdown. >>>>> This is purely to reduce the amount of maintenance effort we have to >>>>> expend in keeping our systems running. >>>> >>>> >>>> Sorry Ben, but this is not the solution. See below. >>>> >>>>> There is an enormous amount of software and other systems deployed on >>>>> our infrastructure, and the value of continuing to maintain software, >>>>> including associated security updates, major upgrades to ensure we're >>>>> able to continue running it on modern distributions, etc for something >>>>> which is no longer in active use is questionable at best. Bitrot and >>>>> decay is almost guaranteed to erode the value of it as a historical >>>>> archive in the long run in any case. >>>>> >>>>> For those who dismiss decay as an issue - problems with previous >>>>> Reviewboard upgrades not taking cleanly have resulted in some reviews >>>>> being damaged, causing their diffs to become unavailable. These sorts >>>>> of problems do happen. >>>> >>>> >>>> If it is a resource problem, it can be addressed elsewhere as well. The >>>> e.V. >>>> can hire people. >>>> >>>>> Whether some kind of read only archive is retained is another topic >>>>> altogether. >>>>> >>>>> Reviewboard has a WebAPI which should be usable by anyone interested >>>>> to extract all the information regarding reviews, including their >>>>> comments and the diff itself. This could be used to create a static >>>>> snapshot of each review. >>>> >>>> >>>> Here I disagree, I think it is exactly the same issue. Without a read only >>>> archive, easily accessibile like the current reviewboard (for which a >>>> static >>>> copy will be the best solution), we need to keep the site up and it is not >>>> thinkable that anyone would go and extract single reviews. It should be >>>> available for all the content. >>> >>> The above point was giving an indication of how exactly someone with a >>> vested interest in creating a read only archive would go about it. >>> Whilst I haven't checked, I would imagine API exists to retrieve the >>> list of reviews (although it's an incrementing number, with a large >>> gap between the last number of SVN reviews and the first of the Git >>> reviews) >>> >>> This isn't a task which has to be done by Sysadmin - the Reviewboard >>> WebAPI is accessible (within reasonable usage of course) to anyone >>> with an Identity account. To be honest it would be better that it be >>> done by someone who works with the reviews, as they'll be more aware >>> of the issues surrounding various forms of presentation (threading, >>> etc) that needs to be taken care of. >> >> Come shutdown day, disable login and then dump the website with wget >> or something alike. Someone who's complaining can write a script so >> sysadmins don't have to spend time on this ... >> >> Here's your starting point >> wget --mirror --convert-links --backup-converted --adjust-extension >> --page-requisites https://git.reviewboard.kde.org >> >> Then use that to replace the php version. The builtin search won't >> work but such is life. > > Reviewboard is a Python application :)
All the same modern magic to me :P >> >> http://i.imgur.com/A9z0RYJ.png > > Interesting, I would have assumed that due to all the AJAX it uses > that a wget mirror wouldn't work... > We've used that a few times to shutdown things like old Akademy sites, > so if it works that's fine with me. Seems to work just fine. The proof of concept I did was with /etc/hosts setting git.reviewboard.kde.org to localhost for good measure btw. So a dump should do nicely without much effort. HS