Posts tagged with 'notifications'

On the 5th of October we’ll be ending our beta of Mercurial imports in Launchpad. On that day your existing Mercurial imports will cease and you won’t be able to create new ones.

This doesn’t affect Bazaar, Git, Subversion or CVS imports.

You’re probably wondering why. During the beta, we found that not many people wanted to import Mercurial branches into Launchpad. Today there are only around forty people using the facility. It’s also fair to say that our importer wasn’t of the quality we want for Launchpad.

So, with low demand for the feature we decided to focus engineering effort elsewhere rather than continue to maintain, or fix up, a less than satisfactory feature.

I’m sorry if you currently rely on Launchpad to import code from Mercurial into Bazaar. You can, though, still use the bzr-hg plugin locally.

The Launchpad builders are currently operating at reduced build capacity. We are aware of the issue and have raised this with IS who are investigating the situation. If you are having any issues with your builds please ask for help in #launchpad.

We apologise for the inconvenience and we’re sorry for the disruption to your service.

Launchpad’s code hosting will be unavailable, due to planned maintenance, for four hours starting 22.00 UTC on Friday the 17th August.

This will affect pushing to and pulling from branches, merge proposals, build from branch and translations activity involving code branches. It is in addition to the already announced disruption to Personal Package Archives for the same time.

Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-29, to allow us to open the translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).

We tried this last week but hit some problems. Rather than prolong the disruption, we decided to bring translations back online and delay the opening of Precise’s translations until after we’d fixed the issue.

While we’re opening Precise’s translations, Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.

Once this is done, imports will resume normally and any backlog should be processed quickly after that.

Launchpad translations was due to be unavailable from 10.00 UTC for around one hour this morning to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).

However, by about 10.15 UTC we encountered problems with data already in Precise’s translations. We weren’t sure how long it’d take to fix this issue, so decided it was better to reschedule the translations downtime for another day.

Sorry for the brief interruption to service. We’ll give you at least 24 hours notice before attempting this work again.

Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-22.

During this time Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.

We are suspending the service temporarily to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS). Once this is done, imports will resume normally and any backlog should be processed quickly after that.

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.

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.

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.

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.

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.