launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Sat, Feb 18, 2012 at 3:58 AM, Deryck Hodge
<deryck.hodge@xxxxxxxxxxxxx> wrote:
> I'm worried that if we disable it, then we've taken the first step to
> removing it, whether we actually remove it now or not.
>
> I'm not personally plagued by the issues enough to be bothered by it
> in its current form.  AIUI, the current issue are connection starving
> for users of many tabs and some little js snafus we had in the combo
> loader migration. That latter should be fixed now and no longer an
> issue. If there are remaining js issues, I assure you we'll catch them
> all before we leave maintenance. These are not hard things to track
> down and fix, and in fact, disabling it will only hide the issues from
> us.

https://bugs.launchpad.net/launchpad/+bugs?field.tag=longpoll
3 criticals
4 highs (one of which can probably be shelved)

> If these are indeed the only issues, I don't think it's serious enough
> to disable longpoll now and would rather we as lp devs live with it a
> bit until we can get more attention to finish longpoll completely.
>
> It feels to me like we might as well agree to never have polling from
> the browser if we disable it now. That is a more serious issue to me
> than the few issues we've bumped up against. Maybe I'm being too
> pessimistic about the feature's chances if we turn it off, but I'd
> prefer we erred on the side of completing the work, rather than losing
> the work.

Then we *must* resource it. It *is* causing issues - just having three
tabs open is enough to make other code.lp.net pages load slower (due
to less concurrent requests). Noticable issues amongst 25 people is
pretty much a guarantee of disaster amongst thousands.

Please understand, I was and am a huge proponent of the project; but
its currently unfinished inventory; I find it hard to reconcile our
desire to only released polished work and where we are at with this.

-Rob