Trac downtime for upgrades

[Erik Bray]

Hi all,

I have some long overdue updates for Sage's Trac that I've been
putting off deploying for several months, for various reasons.
However, I believe it *is* ready to deploy.

This upgrade will require a database migration, so it will require
taking the site down for a few minutes to perform a backup and do the
migration.

I would prefer not to do it on a weekend, so I was wondering if there
is a good time today to do it.. I would propose 17:00 GMT+2, as I
suspect not too many people will be working around that time (even in
the US). Is that alright for everyone? I believe the downtime should
be about 20 minutes.

Thanks,
E

[William Stein]

When it is down will it say why it is down?

--

---
You received this message because you are subscribed to the Google Groups "sagemath-admins" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sagemath-admi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- William Stein

[Jeroen Demeyer]

I wouldn't worry about it too much especially if you expect the downtime
to be relatively short. Just do the upgrade...

[Erik Bray]

Upgrade completed--only took about 5 minutes actually :)

The main difference you should notice, if anything, is that the links
to branches on tickets no longer directly contain an
https://git.sagemath.org URL. Now they go through
trac.sagemath.org/git-merger
This is part of a performance enhancement that delays creating merge
previews until the merge preview is actually visited.

Everything else should work more or less the same, but if anything
seems amiss let me know in this thread.

Thanks,
E

[Erik Bray]

It seems the "(Commit)" links next to branches in tickets are now
broken. I don't recall having a problem like this in testing. I'll
look into it.

[Erik Bray]

Okay, I pushed a patch release that should fix that issue. Don't know
why I didn't catch that before (other than the fact that the plugin
doesn't have a test suite :)

[Dima Pasechnik]

On 2018-05-11, Jeroen Demeyer <J.De...@UGent.be> wrote:
> I wouldn't worry about it too much especially if you expect the downtime
> to be relatively short. Just do the upgrade...

indeed.
>

[Dima Pasechnik]

On 2018-05-11, Jeroen Demeyer <J.De...@UGent.be> wrote:

> I wouldn't worry about it too much especially if you expect the downtime
> to be relatively short. Just do the upgrade...

indeed
>

[Jeroen Demeyer]

Thanks Erik!

After using it for just a few days, the git Trac plugin seems to work
very well and it's a clear improvement.

[Sébastien Labbé]

Sorry, I just can't see what is the improvement. Erik just said "This is part of a performance enhancement that delays creating merge
previews until the merge preview is actually visited." Before and after, the merge preview is done with the latest beta right? So what is the improvement?

Sébastien

[Erik Bray]

Well, if it's not *worse* at least then why even ask? :) (In fact I
have already found a few bugs in the new version of the plugin, but
thankfully I seem to have caught them myself and pushed patches before
anyone else bothered me about it :)

A lot of the improvement is internal and not immediately user-visible.
The caching of merge previews is more fine-grained in such a way that
cache invalidation leads to less overall performance degradation.

At the user-visible level you can see that you have to actually click
on the merge preview link before it gets generated--this means faster
page loads. As a second stage I was going to add some JS to still
asynchronously request the merge preview, so that by the time one
clicks the link it's already ready (or found to be me unmergeable).
That would still be better than the previous situation where page
loads of tickets were always slowed down by merge preview generation
any time some new changes were pushed to a branch, or the develop
branch was updated.

Also on the internal end the new version of the plugin laid the
groundwork for merge previews against different base branches (part of
the reason for the database upgrade; the other reason was a new schema
for storing SSH keys better which itself lays the groundwork for a
better UI for managing SSH keys). Those features will come in another
update soon, which will be quick an easy since I think all the
necessary database migration is done for now.

[Sébastien Labbé]

Thanks for the explanation.

Sébastien