Package branch freshness

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...
> I grabbed lp:bzr and played with it a little bit.  In general, I really
> appreciate you adding this.  Package import failures will probably never be
> exactly zero, and the less users expects an import to be out of date, the more
> important I think it will be to warn them when that does happen.  (If you
> agree, that could influence the default output choices.)
> 
> I tried it with ubuntu: branches, and it works the same way as lp:ubuntu
> branches (as expected).  Yay!
> 
> I also tried it with debianlp: branches and it kicks in there too.  Yay!
> 
> The output could be a little clearer I think, and here are just some random
> thoughts based on quick tests.
> 
> - The output is a little too verbose.
> - the version numbers are a bit difficult to pick out in the output.
> 
> Suggestions follow.
> 
> Case 1: everything is up-to-date
> 
> 1.4.1-4 is CURRENT in Oneiric
> 
> Case 2: packaging branch is out-of-date
> 
> 1.0.2-0ubuntu1 is OUT-OF-DATE (Ubuntu Oneiric has: 1.0.4-0.1)
> 
> If you want to expose a configuration/cli knob, then the above would be less
> verbose output, with more verbose output possibly being:
> 
> Case 1:
> 
> Most recent Oneiric version: 1.4.1-4
> Packaging branch status: CURRENT
> 
> Case 2:
> 
> Most recent Oneiric version: 1.0.4-0.1
> Packaging branch version: 1.0.2-0ubuntu1
> Packaging branch status: OUT-OF-DATE
> 

I think there are different users for this, and I definitely want to
support the "Barry" user. I don't know that we want it to be the
default, though, because not everyone is nearly as awesome as you. At
least, not nearly as comfortable thinking about what the packaging
branch is, and what up-to-date means, etc.

> I thought about not even printing a status report in case 1 for less verbose
> output, but I think it's still useful to print the version number and status
> in that case.  I suppose a "quiet" option would only print a warning when the
> published version isn't available.

I felt that especially with the transition, you'd really want feedback
having bzr tell you "yes, I really did check, this is up to date."

> 
> I noticed a *very* slight additional delay for `bzr branch` but I can
> certainly live with it for the additional information!

I think there are a couple of factors:

1) You're on a pretty impressive link. For me, the bzr+ssh handshake
takes about 2.8s. (time echo hello | ssh bazaar....) So adding even 1s
to that isn't terrible.

2) debian was *much* slower than Ubuntu branches. This is because
apparently Launchpad doesn't track "Published" for debian. So when
making an api request for "ubuntu/bzr" we can ask for what the single
most recent Published state is. For Debian we have to ask for the
Pending list. Now, we limit the list to 1 entry, and Launchpad sorts in
newest-first. However, I imagine at the app/DB level, Launchpad has to
read in all the rows and sort them.

3) The API request is a lot slower today than when I was testing it
during development. I don't have any idea why that would be. But pulling
out the setup code into:

$ cat latest_version.py
import sys, time
from bzrlib import initialize, plugin; initialize()
plugin.load_plugins()
from bzrlib.plugins.launchpad import lp_api_lite
t = time.time()
archive, series, project = sys.argv[1:]
if series == 'None':
    series = None
v = lp_api_lite.get_latest_publication(archive, series, project)
t = time.time() - t
print '%.3fs %s' % (t, v)

I'm seeing 0.969s for cold "debian sid bzr" vs 0.770s for "ubuntu
oneiric bzr". However, last week I was seeing 100-200ms.

I don't feel like I have much visibility into Launchpad API performance,
but I'm asking around to see if there is something obvious.

> 
>> I'm a little worried it will be too verbose, or ignored or confusing, so
>> any feedback is useful. Even better if you can use it for a while and
>> see how it feels. This landed as bzr.dev 6033, so it should get built
>> into the dailies soon.
> 
> I'll continue to use lp:bzr for the next few days packaging work.
> 
> Cheers,
> -Barry
> 

Great. I think it would certainly be reasonable to have a knob that
issues short form for people who know what everything means and what it
to be as easy to parse as possible.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4lOGkACgkQJdeBCYSNAAOfyACeK/VttQcVu1pXdKFIMSWLHkpP
RK0AnjIApM1fO4RYdOTJRGy/vR+mX/A7
=vMKn
-----END PGP SIGNATURE-----