branch page delay in showing writes to a branch

Well, I said it, so I may as well Confirm it :)

Did not fix it in time for 1.1.8. Un-targetting and un-assigning.

30 seconds? I just waited five minutes to see http://bazaar.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent/revision/3910 show up at the top of the list of revisions on https://code.edge.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent :-).

Had this conversation in IRC right afterwards, in which salgado explained what's going on:

<kfogel> So on
           https://code.edge.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent,
           the topmost change there (3910) took a while to show up.
           Is this normal?

<kfogel> I pushed it, and the push succeeded, and I could visit
           http://bazaar.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent/revision/3910
           manually and see the change.

<kfogel> But it did not show up in the list of changes at
           https://code.edge.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent
           for five or ten minutes; instead, 3909 stayed on top.

<salgado> kfogel, yes, that's normal. there's a script which scans
           branches for new revisions, which runs every few minutes,
           so it may take some time for revisions to show up on the
           web UI

<salgado> the web UI only reads that from the DB and the DB is
           populated by the branch scanner

<kfogel> salgado: ah. thanks. There's no other way to do this than
           by polling? I think (not sure yet, just suspecting) that
           it may be a typical use case to push a change and then want
           to point someone to it.

<salgado> kfogel, I guess it should be possible to tweak our bzr
           server to notify LP about the new revision when it's
           pushed, but I don't know how complicated that'd be

<salgado> kfogel, also, note that the revision doesn't show up in the
           UI, but if you pull/merge from the branch you'll see it

<salgado> you may have noticed that already

<salgado> abentley, would be the right man to talk about that. and
           even better, he seems to be today's help contact. :)

<kfogel> salgado: yup, it was there right away -- I was even able to
           see it via the web interface (if I manually guessed the
           URL).

<abentley> kfogel: There have been proposals to implement a messaging
           system. That would allow us to kick these processes off in
           a more event-driven manner. We also may eliminate the
           mirroring phase.

abentley's comment is correct, but out of scope for this bug.

The codehosting server *already* tells Launchpad that there's data to push, so Launchpad can display this information quite easily on the branch page.

Paul, let me know if you have any questions about this one.

This branch has been assigned to me since I started working here, but I'm not working on it. I think it makes more sense to not have an assignee, especially if there are no current plans to fix it.

There's a related bug or other aspect that the public view of the branch is not up to date for some time after the push completes:

mbp@lithe% bzr push && bzr pqm-submit -m "(mbp) better messages from bzr ignore"
Using saved push location: lp:~mbp/bzr/integration
Pushed up to revision 4099.
HPSS calls: 255 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x9f7ef6c>
bzr push 3.15s user 0.22s system 1% cpu 3:48.82 total
Checking the working tree is clean ...
Checking that the public branch is up to date at
    http://bazaar.launchpad.net/~mbp/bzr/integration
bzr: ERROR: Public branch "http://bazaar.launchpad.net/~mbp/bzr/integration" lacks revision "<email address hidden>".

The title of this bug may be incorrect. Ideally, there would be no perceptible lag at all. If there has to be lag, showing it in the page would be a bit better, but it's still going to cause problems:

 * bugs won't be linked straight away
 * merge proposals won't be update straight away
 * per comment 7, people won't be able to pull the branch over http straight away

That said it may still be most pragmatic to show a message. Doing so would at least make people aware that there can be a lag.

Bug 280578 addresses your penultimate commend and bug 85326 along with bug 280578 address your last one.

Changed the summary of this bug to include the word "delay" and to describe the symptom, not the cause (i.e., as far as the user is concerned, there is no such thing as a "pending write", there is simply a delay in writes becoming visible on the branch page). This should make the ticket more easily findable.

Not trivial because we are blocked on UI design. I have a branch that begins work on this.

Screenshot of a deliberately crummy first draft of the UI change

"This branch has been changed in the past few minutes. We’ll have the changes here for you shortly."

+1

Also, maybe indent the note and/or put it in italics and/or put "Note:" in front of it? Just thinking it would be good to give a visual indication that this is a non-standard informational message (i.e., one that usually won't be here when you visit the page, so when it's here you want to read it).

The actual message "Launchpad is processing new changes to this branch and will be available in a few minutes." is misunderstandable in my eyes.
To me it sounds like "Launchpad is processing new changes to this branch and [launchpad] will be available in a few minutes." - saying the whole launchpad site is down for processing the changes.

But what actually is meant "Launchpad is processing new changes to this branch. They [the new changes] will be available in a few minutes."

Is that what went live when the fix was released? I agree, that wording is confusing. Matthew Paul Thomas's suggested wording was great, as is Tiefflieger's. If the current message is "Launchpad is processing new changes to this branch and will be available in a few minutes", that's simply wrong: it means something different from what we're trying to say.

Bug 400393 has been filed to track the wording issue.