Phabricator: All repositories registered - upcoming workflow changes

Harald Sitter sitter at kde.org
Thu Feb 2 17:24:15 UTC 2017


On Thu, Feb 2, 2017 at 6:17 PM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Thu, Feb 2, 2017 at 11:51 PM, Harald Sitter <sitter at kde.org> wrote:
>> On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley <bcooksley at kde.org> wrote:
>>> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano <luigi.toscano at 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


More information about the Kde-frameworks-devel mailing list