[00:03]  * mwhudson afk for lunch
[00:04] <Ursinha> jtv, no I don't :/ I'm off for carnival
[00:04] <Ursinha> jtv: if you send me one email with the problem, I can take a look when around
[00:04] <jtv> Ursinha: hi!  Never mind, I found the cause.  Enjoy!
[00:05] <thumper> Ursinha: damn, you're off aren't you
[00:05] <thumper> Ursinha: when are you back?
[00:05] <thumper> poolie: we currently report format 2a badly on the branch pages
[00:05] <Ursinha> jtv: heyyy I thought you weren't here :)
[00:05] <thumper> poolie: what should we say?  Just "2a"?
[00:05] <jtv> Ursinha: libpqxx release tonight
[00:06] <poolie> yes
[00:06] <Ursinha> thumper: yes, I am, but should return on Wed.
[00:06] <Ursinha> jtv: oh, I see
[00:06] <thumper> Ursinha: your wed not mine right?
[00:06] <Ursinha> thumper: yes :)
[00:06] <thumper> hmm...
[00:06] <thumper> ok
[00:06] <Ursinha> thumper: what can I do
[00:06] <Ursinha> for you
[00:06] <thumper> I'll have another team lead thingy not done
[00:07] <thumper> Ursinha: I was going to talk to you about only marking things for qa when available on edge or staging
[00:07] <Ursinha> thumper: go ahead, what is it
[00:07] <Ursinha> hmm
[00:07] <thumper> Ursinha: rather than when in stable/db-stable
[00:07] <Ursinha> thumper: hm, right
[00:07] <Ursinha> thumper: so devel/db-devel, right?
[00:08] <thumper> Ursinha: no... but only tagging for qa when it is possible to qa
[00:08] <thumper> Ursinha: right now I see things that need to be qa'ed but can't because they aren't on edge or staging
[00:08] <thumper> Ursinha: it would be good to only get the notification to QA when you can
[00:09] <thumper> Ursinha: that way it is less likely to be put into the "later" basket, and done ASAP
[00:09] <Ursinha> thumper: I thought that when a branch reached stable, it could be QAed
[00:09] <thumper> right now I need to poll edge or staging to see if I can QA
[00:09] <thumper> Ursinha: no...
[00:09] <Ursinha> thumper: :/
[00:09] <thumper> Ursinha: it has to be rolled to edge
[00:09] <Ursinha> thumper: right
[00:10] <Ursinha> thumper: I'd have to find a way to check if the revision is already there
[00:10] <Ursinha> shouldn't be that hard..
[00:10] <wgrant> There's a script for that™
[00:11] <Ursinha> but it would demand some work, and I wonder how would I fit this in the way tagging script work
[00:11] <Ursinha> wgrant: yes
[00:11] <wgrant> utilities/on-edge
[00:11] <thumper> Ursinha: if your script grabbed the branch and opened it locally, you could use bzrlib to check the ancestry
[00:11] <Ursinha> wgrant: hmm
[00:12] <Ursinha> wgrant: cool, thanks
[00:12] <Ursinha> thumper: so I guess it's not hard to do
[00:12] <thumper> Ursinha: that would be really cool
[00:16] <Ursinha> thumper: I can do that when I return
[00:17] <thumper> Ursinha: I'll send you a chocolate fish when its done :)
[00:20] <Ursinha> thumper: hehe :)
[00:21] <Ursinha> thumper: I thought the script was behaving like that, only showing items to test already "testable"
[00:21] <Ursinha> I'll fix that
[00:21] <thumper> Ursinha: awesome, ta
[00:21] <Ursinha> jtv: I heard you're coming to visit me here :)
[00:21] <Ursinha> thumper: np :)
[00:22] <jtv> Ursinha: so it seems
[01:10] <wgrant> >>> sprb.buildstate
[01:10] <wgrant> <DBItem BuildStatus.FULLYBUILT, (1) Successfully built>
[01:10] <wgrant> Yay.
[01:23]  * mwhudson finally notices the icon screwage on edge
[01:24] <wgrant> mwhudson: Just the branch sprite, or something else too?
[01:24] <mwhudson> probably just the branch sprite
[01:24] <wgrant> It's odd that only that one has been hit.
[01:26] <wgrant> Do I want to call attributes source_package_recipe_build or sourcepackagerecipebuild?
[01:26] <wgrant> There is no consistency.
[01:27] <mwhudson> well
[01:27] <mwhudson> the old way is sourcepackagerecipebuild
[01:27] <mwhudson> the new way is source_package_recipe_build
[01:27] <mwhudson> soyuz is old
[01:28] <wgrant> That's what I thought. Thanks.
[02:17]  * thumper afk for a bit
[04:25] <thumper> mwhudson: I'd like to talk some more about recipe stuff if you are up to it
[04:25] <thumper> I find that talking helps clear my mind on the issue
[04:26] <thumper> or...
[04:26] <thumper> I could just finish that other branch...
[04:26] <thumper> hmm...
[04:26]  * thumper forgets about recipes for a bit
[04:31] <thumper> ...
[04:31] <thumper> mwhudson: I could do with a mid-impl call if you have some time :)
[04:32] <mwhudson> thumper: mid-imp sounds fine
[04:32] <mwhudson> thumper: skype me up
[05:05] <mwhudson> thumper: http://jcalderone.livejournal.com/tag/sixty%20seconds
[06:41] <wgrant> stub: Regarding the patch to drop SourcePackageRecipeBuildUpload, I get a test failure in the person visibility consistency checker. If I drop the foreign key from SPRBU -> Person.id, it's all OK. Can I do that?
[06:41] <stub> wgrant: Yes, that is good.
[06:42] <wgrant> stub: Thanks.
[07:38] <mwhudson> noodles775: hello again (!)
[07:38] <noodles775> Hi mwhudson :)
[07:40] <wgrant> Morning noodles775.
[07:43] <noodles775> Hiya wgrant.
[08:00] <thumper> hi noodles775
[08:00] <thumper> noodles775: is your birthday in july?
[08:01] <noodles775> thumper: nope - august... why so?
[08:01] <thumper> noodles775: I was wondering about the 775
[08:01] <thumper> noodles775: and I though July '75
[08:01] <thumper> t
[08:01] <jml> good hello
[08:01] <noodles775> Ah, just noodles was already taken, not sure why I added th eextra 7.
[08:01] <noodles775> Morning jml
[08:02] <jml> a truck with flatpack bookshelves is arriving any minute now.
[08:03] <noodles775> Yay.
[08:05] <lifeless> hi jml
[08:05] <jml> lifeless, hello
[08:08] <wgrant> Hmm, is Björn doing DB reviews now?
[08:08] <jml> wgrant, yes. was the email not sent to the public list?
[08:08] <wgrant> jml: Not that I saw.
[08:09] <jml> wgrant, sure. anyway, yes, Björn is doing db reviews.
[08:10] <wgrant> jml: OK, thanks. Was just a bit confused by the extra review request that sprung up on one of my MPs a couple of days ago.
[08:12] <jml> wgrant, np.
[08:22] <adeuring> good morning
[08:24] <jml> good morning
[08:24]  * jml has flatpack shelves now
[08:25] <wgrant> But can you put them together?
[08:25] <jml> well, first step is getting them upstairs
[08:26] <jml> putting them together... I've done it before
[08:38] <thekorn> allenap, hi, have you seen the test failures? I would like to help fixing them, but I've no clue about the correct fix (implementing this method by returning an empty list vs. moving this method to something like IHasTags)
[08:58] <mrevell> Morning
[09:03] <jml> mrevell, good morning
[09:04] <mrevell> Guten morgen jml
[09:10] <wgrant> Why doesn't +activereviews show the number of pending reviews?
[09:36] <jml> don't know.
[10:46] <noodles775> Do we have any examples of where we've presented disabled form widgets on LP? I can't find any...
[10:47] <noodles775> I can see that zope.scheme items can take an optional constraint, but that is validation related, whereas I'd like to present a checkbox that is disabled in some situations.
[10:47] <noodles775> (setting readonly=False causes the field to render as a normal text field, rather than a checkbox).
[10:48] <noodles775> If not, I can create a new widget to do so, but just wanted to check first.
[10:53] <jml> noodles775, I can't think of any.
[10:54] <wgrant> The only disabled widgets I can think of are the textboxes on the code import registration view, but that uses BeautifulSoup...
[10:55] <noodles775> OK, thanks guys.
[10:55] <wgrant> Is this for the Archive.private restriction?
[10:55] <noodles775> wgrant: yep.
[10:56] <noodles775> wgrant: just for the ui presentation of it of course - it needs to be read only on the model with a validator there.
[10:57] <wgrant> Right.
[11:02] <deryck> morning, all.
[12:32] <adiroiban> danilos: hi, can you please advise my how I should process with bug 516317 ? Should I fix it together with bug 127171, create a new branch, or wait for you to fix it?
[12:32] <mup> Bug #516317: Product:+changetranslators should become +settings <ui> <Launchpad Translations:In Progress by danilo> <https://launchpad.net/bugs/516317>
[12:32] <mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
[13:27]  * jml offline
[13:39] <danilos> adiroiban, hi, I have a branch which fixes it and a few other issues at the same time, it's almost ready
[13:39] <danilos> adiroiban, I believe it fixes 127171 as well :)
[13:39] <adiroiban> danilos: ok. I'll wait for that
[13:39] <adiroiban> :)
[13:40] <danilos> adiroiban, I am renaming it 'translation-settings' because I am also moving 'official_rosetta' setting there so it's easier to configure a project for translation in one place
[13:41] <danilos> adiroiban, if you are impatient and have a mostly ready branch, you can land it and let me worry about solving all the conflicts and everything else :)
[13:41] <adiroiban> no problem
[13:41] <adiroiban> I don't think it is worth landing it
[13:42] <danilos> adiroiban, if it's done, it's worth landing it because I haven't ran the full test suite on my branch yet :)
[13:42] <adiroiban> but maybe you can reuse some of the tests
[13:42] <danilos> adiroiban, and, it's a work you invested time in, and I always appreciate that :)
[13:42] <adiroiban> i think that landing it will only create more work for you
[13:43] <adiroiban> so maybe you can reuse some of the tests from there
[14:01] <adiroiban> danilos: it is OK if I will assing you the bug 127171 ? It is now assigned to me and targeted for the next milesone.
[14:01] <mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
[14:02] <danilos> adiroiban, yeah, it'll probably help
[14:03] <danilos> adiroiban, iow, just go ahead and land it :)
[14:05] <adiroiban> danilos: I'm confused. Should I land it, or assing it to you and leave you the task of fixing this bug?
[14:05] <danilos> adiroiban, land it :)
[14:05] <danilos> adiroiban, I'll worry about other things
[14:05] <adiroiban> ok
[14:06] <jtv> adiroiban: shame we didn't have time to talk more at fosdem...  I introduced Milo to a new snack, and if you don't know them yet, I'll get you one next time.  :)
[14:06] <adiroiban> :)
[14:09] <jtv> abentley: is there a way to get a branch URL, but with a preference to (say) a read-only http URL?
[14:09] <jtv> a preference *for
[14:10] <abentley> jtv, you can, but you might have to hand-craft it.
[14:11] <jtv> abentley: this is for hosted branches btw... alternatively, can I predict what protocol I'll get?
[14:12] <jtv> (and will read-only URLs go away completely?  This is untrusted access so read-only would be a nice touch)
[14:12] <abentley> jtv, the protocol you get is entirely up to you.
[14:12] <jtv> abentley: me the branch owner or me the script that wants to read the branch contents?
[14:13] <abentley> you, a launchpad developer.
[14:14] <jtv> So rewriting the branch URL could be messy.  (BTW I just realized: the branch may well be mirrored instead of hosted)
[14:15] <abentley> jtv, I don't understand what you're trying to do.
[14:15] <abentley> jtv, I don't understand whether you're writing a cron script or a script that accesses Launchpad over the API
[14:16] <abentley> jtv, so I really don't understand what answers are relevant to you.
[14:17] <jtv> abentley: I'm writing the code that produces a BuildFarmJob for a given Branch object from the db.  Based on that BuildFarmJob, the slave will have to export the branch contents and operate on them.
[14:18] <jtv> The thinnest interface I can think of for doing that is to pass a branch URL to the slave, after which the slave can read branch contents from that URL.
[14:19] <jtv> I'm not sure the warehouse URL would be good to expose to a slave; the slave is not trusted.
[14:19] <abentley> jtv, this will only work for branches which support anonymous access.  Is that acceptable?
[14:19] <jtv> abentley: yes
[14:20] <abentley> jtv, so you can just use the http URL.
[14:20] <jtv> abentley: yes, that's what I was thinking; makes it easier to set up the firewall rules.
[14:20] <jtv> abentley: is there a reliable way to get that url?
[14:21] <abentley> jtv, over http, there's no distinction between mirrored and hosted branches, and the URL rewriting happens elsewhere.
[14:22] <abentley> jtv, I don't know if there's a way to construct an http url directly, but if not, you can just prepend "http://bazaar.launchpad.net" to the bzr_identity.
[14:23] <jtv> abentley: would it make sense to add, say, an http_url property to IBranch?
[14:24] <abentley> jtv, I don't think so.  Branches have lots of URLs, even multiple http URLs.  A public_url method might make sense, though.
[14:25] <jtv> abentley: as a compromise, public_http_url?  I know it seems overly specific but the "http" part matters for our firewall setup.
[14:25] <danilos> jtv, abentley: you'd definitely want to involve someone who knows our production config into this discussion, since I know we'll at least have to open firewall rules for this
[14:25] <jtv> danilos: yes, we know, thank you  :-)
[14:25] <abentley> jtv, no, our API is fat enough.  I'd want a method that can produce sftp, bzr+ssh, or http URLs.
[14:26] <jtv> abentley: so... a method that takes a protocol parameter, and which for now only supports http?
[14:27] <abentley> jtv, I can't think of a reason to only support http.
[14:27] <jtv> abentley: just that I don't want to write, and you don't want to maintain, something that nobody uses yet.  :)
[14:29] <abentley> jtv, I am quite happy to maintain something like that, considering it's a 7-character difference at most.
[14:29] <abentley> jtv, I would even be willing to update our existing code that generates URLs to use it.
[14:30] <jtv> abentley: in that case, how about you tell me the URL patterns, I write a branch, and you review it?
[14:30] <jtv> Or is that too incestuous?
[14:30] <abentley> jtv, works for me.
[14:30] <jtv> Actually, if you just tell me other places that compose URLs like this, I'll have the patterns too :-)
[14:31] <abentley> jtv, looking.
[14:36] <abentley> jtv, lp.code.xmlrpc.branch is the bit that actually converts an lp: URL to a public URL.
[14:38] <jtv> (the "os.path.join" is going to do funny things with the URLs if we ever port to Windows :)
[14:38] <abentley> jtv, that may be the only place we do this conversion.
[14:38] <jtv> _getUniqueNameResultDict?
[14:39] <abentley> jtv, yes.
[14:39] <jtv> so we can push the core of that method down into the model code.
[14:40] <abentley> jtv, yes, that would make sense.
[14:41] <jtv> abentley: thanks, I'll get to work on that then.  At last a good opportunity to start playing with pipelines.
[14:41] <abentley> jtv, cool.
[14:43] <abentley> jtv, I recommend avoiding reconfigure-pipeline for launchpad developers.  Instead, just create a branch as you normally would, then make a lightweight checkout and work in that.
[14:45] <jtv> abentley: do I push the lightweight checkout to bzr separately to set up an MP?
[14:45] <jtv> *to launchpad
[14:45] <jtv> not to bzr
[14:46] <abentley> jtv, no, pushing a lightweight checkout is the same as pushing its branch.
[14:47] <abentley> jtv, you can also use lp-submit to set up the MP.
[14:48] <jtv> abentley: I've already got a branch with committed changes; does this approach still help in that case?  Or would I have to merge my existing branch into the new one?
[14:48] <abentley> jtv, still works.  Just create a lightweight checkout of your existing branch, and you can start using pipelines.
[14:49] <jtv> abentley: oic
[15:00] <jtv> abentley: the plugin complains about an API version mismatch.
[15:01] <abentley> jtv, which version of bzr are you using?
[15:01] <jtv> 2.0.4
[15:02] <abentley> jtv, and you're using bzr-pipeline from source?
[15:02] <jtv> abentley: yes, did a "bzr branch" into my plugins dir & renamed to bzr_pipeline
[15:03] <abentley> jtv, you need to use lp:bzr-pipeline/stable
[15:07] <abentley> jtv, that version of pipeline doesn't contain the lp-submit command.
[15:08] <jtv> bzr: ERROR: No module named pipeline.commands
[15:08] <jtv> You may need to install this Python library separately.
[15:10] <abentley> jtv, you should rename it to pipeline, not bzr_pipeline.
[15:10] <noodles775> intellectronica: did we ever standardise on a way to ensure that model validation can be re-used in browser views?
[15:10] <jtv> abentley: thanks, that works... how do I submit when ready?
[15:10] <noodles775> I have a memory of you bringing it up at one point.
[15:11] <intellectronica> noodles775: i must admit i'm not sure what exactly you're on about
[15:11] <noodles775> intellectronica: sorry. So you've got a model validation that storm uses to ensure a new value is consistent before it adds it to the db.
[15:12] <noodles775> And you want to do a very similar check in your views form validation.
[15:12] <abentley> jtv, use the web UI, and if there's a previous pipe, specify it as the prerequisite branch.
[15:12] <jtv> abentley: right ho
[15:12] <noodles775> intellectronica: perhaps I mis-remembered, I thought you had brought this up once before (related to API validation checks).
[15:13] <intellectronica> noodles775: is this a check you can do without storm? if it is, then you can use a validator with the interface attribute, and use the interface (or specializations of it) for both the model object and the form
[15:14] <noodles775> intellectronica: yep, we're using the same IFace for the form schema and the model, but I'm not sure what you mean by a validator with the interface attribute.
[15:16] <noodles775> Currently the model validation is done via the storm_validator attribute of BoolCol.
[15:16] <intellectronica> noodles775: iirc you can pass validator function to the constraint argument of zope interface fields
[15:17] <intellectronica> let me see if i can find an example
[15:17] <noodles775> Thanks.
[15:18] <intellectronica> noodles775: see some validators in lib/canonical/launchpad/interfaces/validation.py
[15:18] <noodles775> Thanks intellectronica.
[15:19] <noodles775> I did look at constraints earlier, but from memory it was only allowing a constraint on the new value... whereas I need to compare it with the old. But I'll check there.
[15:23] <noodles775> intellectronica: right, so the fact that I need storm to my check means I can't use a constraint. I'll keep looking, ta.
[15:26] <sinzui> mars: target questions to launchpad-registry because we have answer contacts. Assigning them to the registry-team does not generate a notification.
[15:27] <mars> sinzui, will do, thanks
[15:27] <leonardr> flacoste, do you think it's okay to change client.js so that the launchpad website uses the 'devel' version of the web service when making ajax requests?
[15:28] <mars> flacoste, leonardr, fwiw I think it is OK for the JS to use the latest webservice.
[15:28] <flacoste> leonardr: agreed
[15:28] <mars> we can decouple them later if (and only if) we have problems with API drift
[15:29] <mars> err, problems with rapid API change
[15:29] <leonardr> cool
[15:29] <mars> (and we would be trading rapid API change for API drift problems.  Anyway, I'll take the former for now)
[15:30] <leonardr> flacoste: as i was telling mars and gary, my only concern is that our test coverage might not be good enough to detect ajax failures caused by api changes
[15:30] <leonardr> but i don't truly know how good it is
[15:33] <mars> leonardr, I think it is good enough
[15:33] <gary_poster> flacoste: I feel this is a call for BjornT, ideally, but he is not around.  I asked leonardr to ping you because, as he says, this is an assertion that our Windmill tests are pretty good, or that we are willing to experience pain until they are.
[15:33] <gary_poster> I don't know the Windmill tests.
[15:33] <flacoste> windmill tests are fine
[15:34] <gary_poster> flacoste: ok, good enough. leonardr ^^^ that's explicit :-)
[15:34] <leonardr> all right
[15:34] <leonardr> we'll do it
[15:34] <gary_poster> thanks
[15:37] <leonardr> mars, do i have to do anything special to rebuild the *-min.js files?
[15:39] <jtv> abentley: do I need to check whether the branch is public?
[15:40] <jtv> abentley: also, is it appropriate to use the same list of accepted schemes that the url field accepts?
[15:40] <abentley> jtv, I think that's a nice-to-have.
[15:40] <jtv> abentley: when it's not public, there's basically no public URL right?  I could return None, or raise, or just pretend things will work.
[15:41] <abentley> jtv, I don't know what list of schemes the URL field accepts.
[15:41] <jtv> abentley: it's in IBranch: BranchURIField(..., allowed_schemes=['http', 'https', 'ftp', 'sftp', 'bzr+ssh'],
[15:42] <jtv> OTOH that doesn't include lp, so maybe it's not quite the same thing..?
[15:42] <abentley> jtv, that list is not the list of schemes we support for codehosting.
[15:42] <sinzui> mars: answers have history, you do not need to write dates in white boards: https://answers.edge.launchpad.net/launchpad-registry/+question/101172/+history
[15:43] <jtv> abentley: it'd be easiest for me to accept any protocol string at all.  Maybe I'll just do that.
[15:43] <abentley> jtv, I think raising an exception would make sense for non-public branches.
[15:44] <abentley> jtv, I think accepting any scheme is okay.  We can tighten it later if needed.
[15:45] <abentley> jtv, but it only makes sense to raise an exception for http, when the branch is private.
[15:46] <jtv> abentley: pidgin died.  You said the non-private check only makes sense for http.
[15:46] <abentley> jtv, yes, that was the last thing I said.
[15:46] <jtv> abentley: https..?
[15:48] <abentley> jtv, either the API generates URLs that work with LP, in which case, https should be forbidden altogether, or it generates whatever URL you request, and the private check doesn't make sense.
[15:51] <jtv> abentley: for my use case, either kind of function would do.  Right now I'm thinking "does whatever you want, but asserts that you're not making obvious mistakes."
[15:52] <abentley> jtv, to my mind, requesting an https URL is an obvious mistake.
[15:53] <jtv> abentley: that's fine; I just wanted to know if that was something that was supported.
[15:53] <abentley> jtv, at present, only http, sftp and bzr+ssh are supported.
[15:54] <jtv> abentley: so that's the ones the public codehosting API supports, plus sftp.
[15:55] <abentley> jtv, yes.  sftp is basically a legacy service now.
[15:56] <jtv> abentley: so it may make sense to crib my list from PublicCodeHostingAPI with sftp in a "grandfather clause" appendix?
[15:57] <abentley> jtv, yes, that would make sense.
[15:59] <danilos> jtv, abentley: I am again jumping into the discussion, but have private branches been considered? atm, we just need to be careful not to expose data from them publicly
[15:59] <danilos> abentley, ah, I see it has
[15:59] <danilos> jtv, abentley: ok, ignore me, thankyouverymuch :)
[15:59] <jtv> danilos: and this affects our existing plans how..?  :-p
[16:04] <james_w> jelmer: hey, did your delete branches API ever land?
[16:04] <jelmer> james_w: yep, last cycle
[16:05] <james_w> jelmer: I don't see it on https://edge.launchpad.net/+apidoc/#branch
[16:05] <james_w> or is it implicit?
[16:05] <jelmer> Hmm, I don't see it either
[16:25] <abentley> rockstar, chat?
[16:26] <rockstar> abentley, sure, lemme find my headset in this mess.
[16:29] <rockstar> abentley, I don't see you on skype.
[16:29] <rockstar> abentley, I heard you at first, then I didn't anymore.
[16:30] <abentley> I'm here
[16:30] <rockstar> abentley, I heard you again, and then you dropped off.
[16:30] <abentley> rockstar, making a test call.
[16:31] <abentley> rockstar, test call worked.
[16:31] <rockstar> abentley, yeah, as did mine.
[16:32] <abentley> rockstar, grr.  Maybe xmpp chat...
[16:36] <kfogel> adeuring: mystery... when I view source for (say) https://bugs.edge.launchpad.net/gwibber, the bugfilters-portlet stats box on the right (which says there are "489 Open bugs", according to my browser) doesn't contain the string 489 anywhere.  That number appears nowhere in the HTML source.  I do see where the "Open bugs" is, but... what's going on?  Where are the numbers?
[16:37] <kfogel> adeuring: where I expect the number 489 to be, there is just this: <td class="bugs-count"></td>
[16:37] <kfogel> it's empty
[16:37] <adeuring> kfogel: that's pulled in via an extra HHTP request
[16:38] <kfogel> adeuring: cool (because we'll want to do that for patches count too, I think)
[16:38] <adeuring> kfogel: we had lots of timeouts, when this data was directly in the HTML data, so we get the data for some portlets later
[16:38] <kfogel> but how does this work?
[16:38]  * kfogel looks
[16:38] <adeuring> kfogel: are you sure that conting patches is also so slow?
[16:39] <adeuring> s/conting/counting/
[16:39] <kfogel> adeuring: well, no I'm not sure... but if the rest of the portlet already does things this way, it would seem like a good idea to do that here too
[16:39] <kfogel> adeuring: (I also have a good guess that it is as slow as any other thing in that box, though I could be wrong)
[16:39] <adeuring> kfogel: ah, right.
[16:41] <kfogel> adeuring: I'm puzzled by how the content is fetched asynchronously, though.  There doesn't appear to be any unique ID in the HTML identifying the particular <td>...</td> where (say) the open bugs count goes, or the critical bugs count, or any of the others.
[16:41] <kfogel> How does the content get put in the right place?
[16:42] <adeuring> kfogel: the portlet data is pulled from LP via Javascript. Look for lines like "Y.on('domready', function()"
[16:42] <adeuring> kfogel: or "Y.one('#bugfilters-portlet-content').set(..."
[16:42] <kfogel> adeuring: oh, it replaces the *whole table* ?
[16:43] <adeuring> kfogel: I think the portlets are empty without the JS generated stuff
[16:43] <kfogel> adeuring: well, according to the source they would have the names, just not the counts.  let me try turning off js to see
[16:44] <kfogel> yup
[16:44] <kfogel> adeuring: yup -- try it.  the field names are still there, just no data (which makes sense -- because even without the data, at least you can click the link to get to all open bugs or whatever)
[16:44] <kfogel> so it's robust: even when no js, it's still useful
[16:45] <kfogel> this is great, I think I know what to do then
[16:45] <kfogel> thanks
[16:45] <adeuring> kfogel: just add your data to the prortlet "page"
[16:46] <kfogel> adeuring: yup
[16:47] <adeuring> the URL is gwibber/+bugtarget-portlet-bugfilters-stats for your example
[16:47] <adeuring> kfogel: that's plain JSON data; tehre is probably not even a template for it.
[16:48]  * adeuring is talking nonsense. This is HTML data, not JSON...
[16:48] <kfogel> adeuring: lib/lp/bugs/templates/bugtarget-portlet-bugfilters-content.pt
[16:49] <adeuring> kfogel: right
[16:51] <kfogel> adeuring: I'm noticing that some of the other items in that box are conditional, but in a weird way.  For example:
[16:51] <kfogel> <tr tal:condition="view/pending_bugwatches_url">
[16:51] <kfogel> adeuring: why would something be conditional on the... URL?
[16:52] <kfogel> I could understand being conditional on the pending_bugwatches_count, but on the url??
[16:52] <kfogel> I mean, the URL is true no matter what, right?
[16:53] <adeuring> kfogel: well, yes... but it is generated in the view class, and for whichever reason, it seems that it can be None the empty string or whatever. Don't ask me why ;)
[16:54] <kfogel> adeuring: Okay, I won't ask you why, but I'm not going to imitate it either (seeing no reason to).
[16:54] <adeuring> kfogel: yeah, that sounds sane ;)
[16:57] <adeuring> kfogel: the docstring in the view class has a bit of an explanation: For certain bugtarget, we don't want to or cannot show this sort of data.
[16:57] <adeuring> I am not sure if it is that much better to use the numbers insteand as a flag...
[16:58] <adeuring> We may want to show the number zero
[17:00] <kfogel> adeuring: I think I'm going to go with showing zero.  UI-wise, that's a bit less confusing to users who are expecting the item to be there.
[17:01] <adeuring> right
[17:01] <kfogel> adeuring: you're in class BugsStatsMixin in bugtask.py, right?
[17:01] <adeuring> kfogel: i think it is BugsInfoMixin
[17:03] <kfogel> adeuring: hmm, right below that is BugsStatsMixin which inherits from BugsInfoMixin
[17:03] <kfogel> the former has the URLs, the latter has the counts
[17:03] <adeuring> kfogel: ah, right
[17:03] <kfogel> adeuring: but for the URL, I'm just appending "+patches" to the context url already
[17:03] <kfogel> adeuring: no need for a specialized url function here, right?
[17:04] <adeuring> kfogel: no, I dont't think so. Unless the portlet is displayed for some sort of bug target where we don't have the +patches view.
[17:05] <kfogel> adeuring: AFAIK that is not the case
[17:05] <adeuring> kfogel: right
[17:05] <kfogel> (and if it were the case, the right fix would probably be to implement +patches there anyway!)
[17:07] <kfogel> adeuring: I'm removing the "story-patch-report" tag from https://bugs.edge.launchpad.net/malone/+bug/172501
[17:07] <kfogel> does that seem reasonable?
[17:07] <mup> Bug #172501: reject non-code patch attachements <patch-tracking> <story-patch-report> <Launchpad Bugs:Fix Committed by adeuring> <https://launchpad.net/bugs/172501>
[17:07] <kfogel> adeuring: that will leave the "patch-tracking" tag there
[17:07] <adeuring> kfogel: that's OK. I also wnated to checkk if I indeed fixed that bug already. Cant remeber....
[17:07] <kfogel> adeuring: fix committed
[17:07] <adeuring> kfogel: argh, right...
[17:08] <adeuring> confised it woth another bug...
[17:08] <adeuring> ...confused it...
[17:08] <kfogel> adeuring: doing the same thing with other bugs that aren't about the +patches view per se.  for example
[17:08] <kfogel> https://bugs.edge.launchpad.net/malone/+bug/283941
[17:08] <mup> Bug #283941: Upstream report should show which reports have patches <patch-tracking> <story-patch-report> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/283941>
[17:08] <adeuring> kfogel: sure, np
[17:10] <kfogel> deryck: I just ran across this tag "story-patch-report-external" on bug https://bugs.edge.launchpad.net/malone/+bug/403443
[17:10] <mup> Bug #403443: bug watch should notify when a patch is attached to an upstream bug <bugwatch> <patch-tracking> <story-patch-report-external> <ubuntu-upstream-relations> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/403443>
[17:10] <kfogel> deryck: is that a tag we're trying to use consistently?
[17:11] <deryck> kfogel, on phone.  will explain shortly.  sorry
[17:11] <kfogel> deryck: I might change to "patch-tracking-external", and put it on bug 283941 as well.
[17:11] <mup> Bug #283941: Upstream report should show which reports have patches <patch-tracking> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/283941>
[17:11] <kfogel> deryck: okay, will wait, np
[17:14] <deryck> kfogel, off now. sorry again.
[17:14] <deryck> kfogel, so the history there...
[17:14] <kfogel> deryck: listening :-)
[17:15] <deryck> kfogel, was that jorge had two lines of development he was wanting -- exposing patches LP knows about and getting data about patches in other places (i.e. "external") into the LP patches reports....
[17:15] <deryck> kfogel, so that tag was my way of trying to store those kind of second phase, external-related bugs and not lose them
[17:15] <deryck> kfogel, you can use or discard it as you see fit now.
[17:16] <kfogel> deryck: I'm going to change it to patch-tracking-external
[17:16] <kfogel> deryck: and reserve "story-patch-report" for stuff related to the +patches view, which is 90% of how we were already using that tag.
[17:16] <deryck> kfogel, sounds good
[17:17] <kfogel> deryck: tagging question: in a bug that's really just an XXX cleanup bug related to an existing story (story-patch-report), do we give it the story-patch-report tag?  I'm thinking of https://bugs.edge.launchpad.net/malone/+bug/515584
[17:17] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <story-patch-report> <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
[17:18] <deryck> kfogel, in that case, yes, because I think that bug should be fixed before leaving this work.
[17:18] <deryck> kfogel, that's not hard to do so we shouldn't let that debt linger.
[17:18] <kfogel> deryck: *nod*
[17:20] <kfogel> deryck: and you want to keep all our "story-foo" tags unofficial, right?
[17:21] <deryck> kfogel, yes.
[17:21] <kfogel> deryck: ok
[17:21] <deryck> kfogel, though don't get me started on the official/unofficial distinction and how I hate it. ;)
[17:21] <kfogel> deryck: :-)
[17:25] <kfogel> deryck: final tagging philosophy question: most bugs are cleaned up now, but some have *both* the "patch-tracking" tag and the "story-patch-report" tag.  My feeling is, they only need the latter, since we're working on that story right now.  Should I make it so?
[17:27] <deryck> kfogel, yeah, I think that's fine.  But there's certainly no harm in multiple-overlapping tags.  it is tagging after all.  anyone can put whatever tag they like.
[17:28] <kfogel> deryck: I'm just trying to get unwanted bugs out of people's faces in search results, more than anything else, but yeah, it's no huge harm either way
[17:29] <deryck> kfogel, gotcha
[17:35] <kfogel> deryck: ok, all bugs that ever had "patch-tracking", "story-patch-report", or "story-patch-report-external" are now consistified into a grand system that, if y'all are lucky, I might explain to you someday.
[17:35] <kfogel> no bugs had "patches-view" or "patch-report" AFAICT
[17:55]  * jml offline for a while.
[17:55] <adiroiban> is the last line a valid Python code http://paste.ubuntu.com/377709/ ?
[17:57] <salgado> adiroiban, yes, it is
[18:04] <mrevell> night all
[18:39] <kfogel> adeuring: very puzzling phenomenon: in this diff http://paste.ubuntu.com/377792/ , if I remove the "|nothing" from the tal:content, then when I visit https://bugs.launchpad.dev/patches-view-test I get an OOPS.  But when I leave the "|nothing" in, everything works fine and it shows "6 Bugs with patches" as it should.  If the count is returning 6 (which is correct), then why would the "|nothing" matter at all?
[18:44] <kfogel> deryck: (you might be able to answer above question I aimed at adeuring)
[18:45] <deryck> kfogel, you know I don't know.  the is a tal mystery to me.
[18:45] <kfogel> deryck: ok :-)
[18:46] <deryck> kfogel, what OOPS do you get without nothing?
[18:47] <kfogel> deryck: http://paste.ubuntu.com/377800/  (slightly different diff now, but not in any important ways)
[18:47] <kfogel> It's like bugs_with_patches_count() doesn't exist.
[18:47] <kfogel> I wonder if this has to do with the double load -- first the
[18:48] <kfogel> page load and then the javascript to fetch the contents for the stats box.
[18:48] <kfogel> maybe the view is defined differently each time
[18:49] <deryck> kfogel, ah, right.  That's likely it.  In one context the method exists, in another it doesn't.
[18:49] <kfogel> deryck: the only reason I care is that I wanted to do something fancy whereby if it was one patch, it would say "Bug with a patch" instead of the plural "Bugs with patches".  But that's hard to do now because I can't set a tal:condition on a number we don't have yet.  On the other hand, none of the other stats do that, so maybe this new item will just have to sink to the level of its surroundings :-).
[18:50] <deryck> kfogel, I vote sink. :-)  It will be uniform, too, unless you see a nice way to do it.
[18:50] <kfogel> deryck: if we did do it, we'd want to do it for everything.  sigh -- I really like plural polish, but it's gonna cost too much right now.  Oh well.
[18:51] <deryck> kfogel, working back through your statement, I'm not sure I get "a number we don't have yet."  The view rendering the portlet has the number, no?
[18:53] <kfogel> deryck: well, I'm a little mystified by how this code is succeeding right now.  As you can see, the text "Bugs with patches" (and now "Bug with a patch") is in the .pt file.  That text is still there after the portlet is rendered.  But all tests indicated that there is at least evaluation of the portlet during which the view does not contain the method in question.
[18:53] <kfogel> then later, it does (because the method returns the correct answer)
[18:54] <kfogel> but at the time when I do the conditional to evaluate plurality, the method apparently does not exist
[18:55] <kfogel> whoa
[18:55] <kfogel> deryck: never mind -- test-o or sometihng on my part
[18:55] <kfogel> my plurality thing *is* working now
[18:55] <deryck> ah, ok.  Nice :-)
[18:55] <kfogel> deryck: so does that mean I get to commit it? :-)
[18:55] <deryck> kfogel, if it passes review and ec2.... sure. :-)
[18:55] <kfogel> http://paste.ubuntu.com/377809/  just fyi
[18:57] <deryck> kfogel, looks good at a glance to me.  I worry about adding another query to this page, but that's not your code's fault.
[18:57] <kfogel> deryck: ah, just as an aside: this is not something we necessarily want to abstract out either.  Do 'find lib/lp -name "*.pt" -print | xargs grep plural' and you'll see many different ways we handle plurals, and they are often context-specific.
[18:58] <deryck> kfogel, I was wondering if there was a particular tal'ism for handling this.
[18:58] <kfogel> deryck: well, the whole point is the portlet loads separately, so the user doesn't really pay the full cost -- they can start using the page before the portlet is done loading.
[18:58] <kfogel> (responding to your earlier comment)
[18:59] <deryck> ah right
[18:59] <kfogel> deryck: lib/lp/app/templates/base-layout-macros.pt:  <tal:plural
[18:59] <deryck> stupid me
[18:59] <kfogel> but it wouldn't help me much here, because I have to change the whole phrase
[18:59]  * deryck looks
[18:59] <kfogel> oh wait
[18:59] <kfogel> it might work
[18:59]  * kfogel reading moer
[18:59] <kfogel> moer
[18:59] <kfogel> dang it
[18:59] <kfogel> "more"
[19:00] <kfogel> deryck: I think maybe I can use that
[19:00] <deryck> ok, cool
[19:01] <deryck> in Django, this is so simple. ;)  {patches_count|pluralize}  and done. ;)
[19:01] <kfogel> hah, lib/lp/registry/templates/distroseries-needs-packaging.pt is like the *only* place that uses it right now
[19:03] <kfogel> not even
[19:03] <kfogel> hmm
[19:07] <kfogel> deryck: for your entertainment: http://paste.ubuntu.com/377818/  (works)
[19:09] <deryck> kfogel, nice
[20:01] <leonardr> flacoste: i just commented on https://code.edge.launchpad.net/~leonardr/launchpadlib/multiversion/+merge/19343 . do you agree?
[20:02] <flacoste> leonardr: well, an alternative would be to use edge/devel by default, no?
[20:03] <leonardr> flacoste: do you want devel to be the edge default permanently?
[20:03] <flacoste> leonardr: that might actually be a good idea
[20:03] <flacoste> leonardr: anyway, i think this is best decided in conjunction with the Ubuntu release team, they may have sorts of policy that i'm unaware of
[20:04] <leonardr> flacoste: i'm talking with the release team now. i just came over here to confer with you about this
[20:04] <thumper> morning
[20:07] <kfogel> deryck: UI reviews to beuno still, or someone else?
[20:09] <deryck> kfogel, no beuno is gone now
[20:10] <deryck> kfogel, noodles is our only ui reviewer now.
[20:10] <kfogel> deryck: *sob*
[20:11] <deryck> I know
[20:11] <leonardr> flacoste: slangasek says "integration with web apps is a small enough use case in the distro that it's not something there's a policy for :)"
[20:11] <kfogel> deryck: meaning michael.nelson in launchpad, not "noodles" (who is Jonathan McDowell)
[20:11] <kfogel> deryck: that almost messed  me up for a moment :-)
[20:12] <adeuring> kfogel: sorry for the late answer.I have not yet a clue why you got the OOPS. But hiding it is via "| nothing" is not the best idea. It hides "serious" exceptions as well, and that makes debugging quite difficult.
[20:13] <kfogel> adeuring: oh.  I just took my hint from the other code in that .pt... Do you have a recommendation?
[20:13] <kfogel> I have working code right now; I'm reluctant to break it unless I know how to make it work again :-).
[20:14] <deryck> kfogel, yeah noodles775 is michael's nick here, I believe.
[20:14] <adeuring> kfogel: yes, we have places in the templates where "| nothing" is used. But your reviewer might ask you for a good justification to use it in tis case ;)
[20:16] <adeuring> kfogel: but carping aside, can you tell me the branch where you get this odd OOPS?
[20:16] <kfogel> adeuring: right now my justification is "because it breaks if I don't do that".  I *think* the reason is that the method doesn't even exist in the view the first time the portlet template is loaded, it only exists the second time (the javascript reload).
[20:16] <kfogel> adeuring: lp:~kfogel/launchpad/255868-patches-view-from-bugs-page
[20:16] <adeuring> kfogel: OK. So, then you don't need to load it at all the first time?
[20:17] <kfogel> adeuring: ...maybe that's what that tal:condition was for, that I was puzzled about earlier!
[20:17] <kfogel> it's all coming back to me now...
[20:17] <kfogel>   ...the sunken ship, the diamonds...
[20:17] <leonardr> flacoste: ok, i have two plans
[20:17] <deryck> have a nice afternoon/evening all.... I'm out.
[20:17] <leonardr> flacoste: i've spoken with slangasek and i have two plans
[20:18] <flacoste> which are?
[20:18] <leonardr> the plans differ depending on whether we want 'devel' to be the permanent default for the edge service
[20:18] <leonardr> the restriction placed on my by slangasek is that if there is code (rather than changing defaults) it needs to be in by thursday
[20:19] <flacoste> ok
[20:19] <flacoste> and by in, that means an ubuntu upload
[20:19] <flacoste> can we make this?
[20:19] <leonardr> if the ec2 test i'm running now succeeds, definitely
[20:20] <flacoste> ok, you'll need to ping Lucio, the guy that james_w said was maintaining this now
[20:20] <flacoste> i don't know his irc nick though
[20:20] <flacoste> or was it Luca
[20:21] <kfogel> adeuring: no, those tal:conditions are slightly different -- they are to url instead of to count.  (If it sounds like I'm a little mystified by how this thing works, it's because I am.  Trying to figure it out.)
[20:21] <leonardr> so, plan #1 is to change the launchpadlib trunk so that the default is "beta" instead of "devel" and give that to slangasek/lucio/luca
[20:22] <leonardr> plan #2 is to do a little more work so that different instances can have different defaults, set the default for edge to 'devel' and the default default to 'beta', and give *that* to the packagers
[20:23] <leonardr> i like plan #2 but i don't think we have to do it for lucid
[20:23] <leonardr> in either case, after the freeze, once 1.0 is deployed, we'll change launchpadlib so that the default (global default or everything-but-edge default) is "1.0" and do another release
[20:37] <adeuring> kfogel: the usage of that template is quite confusing. It is used for +bugtarget-portlet-bugfilters-info and for +bugtarget-portlet-bugfilters-stats. In one case, the view class BugListingPortletInfoView is used, in the other case BugListingPortletStatsView. And only the latter defines the .*count properties.
[20:37] <adeuring> so you must use this ugly "|nothing" variant.
[20:39] <flacoste> leonardr: sounds good
[20:40] <kfogel> adeuring: oooooooooooh
[20:40] <kfogel> adeuring: I think this maybe wasn't designed for a newcomer to understand immediately
[20:40] <kfogel> :-)
[20:41] <adeuring> kfogel: yes; I needed also some time to understand what is going on.
[20:41] <adeuring> And I think we should file a bug about this craziness.
[20:42] <kfogel> adeuring: May I ask you to file that one?  I think you will be better able to articulate what is going on (and I will understand better after reading the bug).
[20:42] <adeuring> kfogel: sure
[21:06] <leonardr> flacoste, i'm still getting windmill test failures when i run the ec2 tests
[21:08] <leonardr> not a good sign for my chance of landing this branch soon
[21:08] <leonardr> but, i have another idea for cheating a little bit
[21:09] <leonardr> if i make the 'beta' change to launchpadlib, i can verify that it works against a stock launchpad
[21:09] <leonardr> and do it that way
[21:10] <leonardr> it doesn't actually require launchpad to be multiversion, only to support 'beta'
[21:46]  * thumper caffeinates
[21:50]  * jelmer thinks thumper is onto something
[22:06] <EdwinGrubbs> sinzui, bac: ping
[22:06] <sinzui> hi EdwinGrubbs
[22:06] <EdwinGrubbs> sinzui: hi, I was looking at https://dev.launchpad.net/Registry/UpstreamLinkUbuntu#Project community services (New)
[22:07] <EdwinGrubbs> and it seems to overlap heavily with the application tabs and with the "Get Involved" sidebar links.
[22:07] <sinzui> Edwin yes, it does, I think I mentioned that in my notes.
[22:08] <sinzui> EdwinGrubbs: bac and I are calling this Contributor Connections at the moment
[22:08] <sinzui> EdwinGrubbs: It is different from Involvement, because the former is about getting information upstream, the other is for hosted features only
[22:11] <EdwinGrubbs> sinzui: it seems like the tabs should indicate whether that application is active for a project, instead of having to click on the tab or having to look inside a portlet
[22:12] <sinzui> EdwinGrubbs: There are a lot of bugs about that. How do you intend to resolve the conflict between many communities: off-site-upstream, hacker using a mirror, translators, answer contacts?
[22:12] <sinzui> EdwinGrubbs: Even if I host my project on launchpad, another user may choose to use answers and translate my app
[22:13] <sinzui> Do I have the right to tell this person to go away?
[22:14] <sinzui> In the case of Ubuntu, the answer is No, All the the project maintainer can do is state what he officially uses.
[22:18] <EdwinGrubbs> sinzui: that sounds like a permission issue, which doesn't seem to help decide where to display the LP/offsite info and edit buttons.
[22:21] <sinzui> EdwinGrubbs: No, we are still at an impass. The problem is really in the mind of users who choose to host their project in launchpad. Launchpad is not a project hosting service. It is a set of community services that are attracted to projects and teams
[22:22] <lifeless> errr
[22:22] <lifeless> someone should tell our staff and users that then
[22:23] <sinzui> EdwinGrubbs: if there was no barrier between reporting a bug and lp sending it upstream automatically, then we Launchpad would include Bugs in the Involvement portlet when ever it knows where the bug tracker is
[22:25] <EdwinGrubbs> sinzui: that seems to say, if it is easy to submit a bug, look over here in the UI, but if it is hard, look for that info someplace else.
[22:26] <sinzui> EdwinGrubbs: Yes. that is fair statement.
[22:27] <sinzui> EdwinGrubbs: launchpad is successful when it is moving data, when ubuntu bugs do not go upstream, it is a failure. The same is true for bugs in my projects that do no flow upstream
[22:29] <sinzui> EdwinGrubbs: We offer the Involvement portlet so that maintainers can promote the features that use launchpad for.
[22:29] <lifeless> surely 'report a bug' should link to the upstream bug tracker if its not tracking in lp
[22:30] <sinzui> EdwinGrubbs: but communities still need to know where the crucial services are hosted.
[22:30] <EdwinGrubbs> sinzui: I guess what I'm getting at is that the Involvement portlet could indicate when information is missing that could be filled in.
[22:30] <sinzui> lifeless: If the bugs team can make that happen, we should
[22:31] <sinzui> EdwinGrubbs: that is a change in focus. How do you propose to resolve it?
[22:34] <EdwinGrubbs> sinzui: the involvement portlet could either have grayed out links or it could just have a little warning at the bottom of it. I'm not sure if that is what you are asking.
[22:36] <thumper> EdwinGrubbs: hi
[22:36] <thumper> EdwinGrubbs: are you aware of the branch sprite issue?
[22:37] <sinzui> EdwinGrubbs: I am asking you to reconcile the demand of one community who want to host  a service offsite against another community that want to host it on launchpad
[22:37] <EdwinGrubbs> thumper: nope, what is that issue?
[22:38] <thumper> EdwinGrubbs: they aren't showing
[22:38] <sinzui> EdwinGrubbs: I can say support is offered on a forum, and anther person can offer support using Answers. Someone can say the code is in GNOME's git, but Ubuntu needs the code in bazaar.launchpad.net
[22:39] <sinzui> EdwinGrubbs: solve that in the involvement portlet and you will be a hero.
[22:41] <EdwinGrubbs> thumper: are you just talking about the yellow bzr icon? On which page is it not showing up?
[22:42] <thumper> EdwinGrubbs: https://code.edge.launchpad.net/ubuntu/+source/autoconf-nonfree
[22:42] <thumper> EdwinGrubbs: and proposing a merge
[22:42] <thumper> EdwinGrubbs: and a merge proposal page
[23:03] <EdwinGrubbs> thumper: that was definitely removed in the branch that updated all the sprites so that they could be automated. Sorry about that. I will work on fixing the 4 missing css classes and get that landed today.
[23:04] <thumper> EdwinGrubbs: awesome, ta