Archive for the ‘Notifications’ Category

Ubuntu SSO and Launchpad service disruption 10.30 UTC 17th November 2011

Monday, November 14th, 2011

Ubuntu’s single sign-on service will be read-only for around 15 minutes starting at 10.30 UTC on the 17th November. At the same time, Launchpad will be offline.

This means that you should be able to log into websites that depend on the Ubuntu single sign-on service, but not make changes to your login or register a new account. It also means that anything involving Launchpad will be unavailable during that time.

Starts: 10.30 UTC 17th November 2011
Expected back by: 10.45 UTC 17th November 2011

We’re sorry for this service disruption. During this time we’ll be making a database upgrade.

Launchpad offline 08.30-08.45 UTC 10th November, single sign-on read-only

Tuesday, November 8th, 2011

Launchpad will be entirely offline and Ubuntu’s single sign-on service will be read-only for around 15 minutes from 08.30 UTC on the 10th November.

Goes offline: 08.30 UTC 2011-11-10
Expected back: 08.45 UTC 2011-11-10

This is to allow us to make a database upgrade. We’re sorry for the disruption that this will cause.

08.30 UTC is super fast down-time … time

Thursday, September 8th, 2011

Tomorrow, you may notice a blip in Launchpad’s availability around 08.30 UTC. Believe it or not, this is good news 🙂

Until tomorrow, we’d been rolling out database changes — schema updates, database server maintenance, etc — once a month, with a 90 minute period where Launchpad was read-only.

Now, we’re doing things a little differently: two or three times a week, we’ll be doing a fast database update at 08.30 UTC (weekdays only). To start with, it won’t quite be “blink and you’ll miss it”. We’re talking around two minutes but we’ve already identified ways to cut this time. During the update, Launchpad will be effectively unavailable. But it’ll be quick and at a predictable time each day that we do it.

So, other than the obvious bonus of not having Launchpad go read-only for a big 90 minute block every month, why’s this good news? As it’s always at the same and for a short time, we think it’ll be easier to work around. The down-time won’t even be long enough to make a decent cup of tea or coffee. Importantly, it also means you’ll get new Launchpad code faster: if a new feature or a bug fix requires a database schema change, we can now roll it out pretty much within 24 hours rather than waiting up to a month for the next big 90 minute read-only time.

There’s a bug we need to fix: right now, during the fast down-time you’ll get an OOPS when Launchpad tries to access the database. Once we’ve fixed the bug you’ll get a somewhat friendlier and more appropriate 503 error.

While we’re all getting used to it, we’ll still announce these fast database updates on the status feed. We’re hopeful, though, that they’ll be quick enough and predictable enough (08.30 UTC weekdays, two or three times a week) that eventually you’ll have to try hard to notice them.

Less mail for mailing list admins

Wednesday, July 27th, 2011

Many mailing lists in Launchpad are open teams – that is, anyone is welcome to join, or leave, as they choose.

Until today, every time that happened all the list admins were mailed when someone joined or left their team, even though there is no action to take : in an open team, you cannot kick someone out.

We’ve fixed this – now for open teams (and only open teams) when someone joins or leaves the team, the team admins will not be notified.

In future we will have a subscription facility for team admins that do want these emails, and at that point we will make them optional for all team types.

Launchpad offline 08.00-09.00 UTC 14th July 2011

Wednesday, July 13th, 2011

Launchpad will be fully offline (not read-only) for around one hour from 08.00 UTC on the 14th July 2011.

Launchpad goes offline: 08.00 UTC 14th July 2011
Launchpad expected back: 09.00 UTC 14th July 2011

We’re sorry for the very short notice of this down-time. Following this work, Launchpad’s performance will be back to normal.

Launchpad read-only 08.00 UTC 13th July 2011

Friday, July 8th, 2011

Launchpad’s web interface will be read-only, with aspects such as branch pushing and package uploading offline, for around 90 minutes from 08.00 UTC on the 13th July.

Starts: 08.00 UTC 13th July 2011
Ends before: 09.30 UTC 13th July 2011

This is to allow for an update to the structure of Launchpad’s database. Check our schedule of planned down-time.

Launchpad read-only June 8th 22.00 UTC

Thursday, June 2nd, 2011

Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 22.00 UTC on the 8th June 2011. This is to allow for our monthly database update.

Starts: 22.00 UTC 2011-06-08
Expected back by: 23.30 UTC 2011-06-08

Launchpad read-only 08.00 UTC 4th May

Friday, April 29th, 2011

Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 08.00 UTC on the 4th May 2011.

Starts: 08.00 UTC 4th May 2011
Expected to end by: 09.30 UTC 4th May 2011

This is to allow for a structural update to Launchpad’s database.

Automatic bug expiry working again

Thursday, April 21st, 2011

Back in February, Martin wrote that we’d re-enabled Launchpad’s bug expiry feature. This meant that, if a project had enabled bug expiry, Incomplete bugs that appeared to be abandoned would be automatically marked Expired after 60 days.

This worked for a while and then broke. Normally, our monitoring scripts would have have alerted us to the problem but, by an unfortunate coincidence, a separate bug meant that the alert for bug expiry was also broken.

Both bugs are now fixed and bug expiry is working again. Shortly after the fix went live, Launchpad expired roughly 2,000 bugs that would have expired anyway over the past few months.
The option to enable bug expiry for a project

From now on, Launchpad will expire bugs in the usual way. A bug is a candidate for expiry if:

  • it has the Incomplete status
  • the last update was more than 60 days ago
  • it is not marked as a duplicate of another bug
  • it has not been assigned to anyone
  • it is not targeted to a milestone.

If you run a project and you’d previously had bug expiry set to on, but have decided you no longer want it, follow the Configure bug tracker link on your project’s bug overview page and then de-select the Expire “Incomplete” bug reports when they become inactive check-box.

Another bug email improvement: no notification for quickly corrected mistakes

Friday, April 1st, 2011

A few weeks ago the Yellow Squad made another change to increase the relevance of the email you get from Launchpad by eliminating some noisy ones.  A while back, Matthew Paul Thomas noticed that a change to a bug that was subsequently reverted could be deemed a mistake and was an action no one really needed to know about.  As is his habit, mpt opened a bug (164196) with the suggestion that corrected actions not generate email.

So if Alice is assigned to a bug by mistake and then unassigned within five minutes no email is generated.  Likewise, if a tag is added but then quickly removed the action does not cause any email to be sent.

Note that avoiding email requires that the action be undone, not just fixed.  By that I mean the bug must be returned to the original state to be recognized as an undoing.  So if you assign Alice to a bug by mistake and then change that assignment to Bob then the action will not be seen as a mistake.  Email will be sent notifying about both assignee changes to Alice and then to Bob.

Thanks to Gary and Danilo for the fix.