[13:24] <gmb> bac: Do you know where the "Subscribe to bug mail" link that appears on a Product's +index is defined in devel?
[13:26] <bac> gmb: yes, let me look
[13:27] <bac> gmb: are you talking about the one in bugs/browser/structrualsubscription.py?
[13:28] <gmb> bac: I don't know. Am I? I ask because in the accordionoverlay branch we have a subscribe_to_bug_mail link defined for the Product context menu, but we don't have that in devel and yet the link still appears (albeit with the name "subscribe" rather than "subscribe_to_bug_mail") and I'm rather confused because there seem to be several "subscribe" links defined around the place.
[13:29] <gmb> bac: Ah.
[13:29] <gmb> But you're right.
[13:29] <bac> gmb: the one you are referring to (i think) is the *old* one that points to the +subscribe page
[13:29] <gmb> bac: Why shouldn't the new one point there too?
[13:29] <gmb> Our JS will override that behaviour
[13:29] <bac> as i update IStructuralSubscriptionTarget pages I am getting rid of the old one
[13:30] <gmb> Ah, ok.
[13:30] <bac> gmb: my understanding was we were not going to support non-JS for this effort
[13:30] <gmb> bac: Ah, my understanding was that it wasn't our first concern... I'm not sure that it actually matters though.
[13:30] <gary_poster> benji bac gmb (danilos you are not here right?) mumble/kanban asap.  sorry about that
[13:31] <gmb> bac: Thanks for the pointer anyway. That makes life easier.
[14:04] <bac> gmb: would you know why distributionsourcepackages, which are IStructuralSubscriptionTargets, don't currently have a 'subscribe' link?
[14:05] <gmb> bac: Er. No. That seems odd to me. Deryck might know.
[14:05] <bac> ok
[14:06] <bac> i could ask tom on fb i guess.  :)
[14:06] <gmb> :)
[14:11] <gmb> bac: lp:~gmb/launchpad/feature-flag-overlay-bug-739549
[14:12] <gmb> Diff here: http://pastebin.ubuntu.com/583807/
[14:14] <bac> gmb: at line 29 of your diff you define the 'subscribe' link.  is that necessary or will it come from the one defined in the structural subscription mixin?
[14:15] <gmb> bac: Oh. Dur. That would work too (and better). But that menu doesn't use the Mixin ATM.
[14:16] <bac> yeah, that would be too easy
[14:16] <gmb> :)
[14:16] <gmb> bac: No reason it couldn't, though. Let me give it a shot...
[14:24] <bac> gary_poster: we have a problem with the overlay styling with narrow browsers (not so narrow, though) and long descriptions:  http://people.canonical.com/~bac/overlay-overrun.png
[14:24] <gary_poster> bac, yeah, LP production has similar issues with existing functionality :-/
[14:25] <gary_poster> I suspect there is some more attractive CSS to be had
[14:25] <gary_poster> Suggestion/thought: could you keep a "Huw punchlist" doc somewhere?  Maybe on the kanban backlog, or the wiki
[14:26] <gary_poster> I think this is something he could help with
[14:26] <gary_poster> I vaguely recall seeing relatively attractive CSS solutions for this sort of thing in the past
[14:27] <benji> for the time being we could use a constant title (e.g., "Add a mail subscription") and either leave off the target name or put the target name in the smaller, free running text of the form.
[14:28] <benji> re. CSS: there is an ellipsis mechanism, but it's not the most standard thing in the world; I do seem to recall that FF does it well, so that may be all we need
[14:28] <gary_poster> I'd prefer to stick to the design for now and see what Huw comes up with.  solutions like that one tend to stick, and I'd honestly prefer for it not to unless necessary.
[14:28] <gary_poster> ellipsis is an option
[14:29] <gary_poster> but breaking with a border underneath the whole thing might also be an option
[14:29] <gary_poster> and at least look better than what we have
[14:30] <gmb> bac: Relying on the mixin seems to work fine. I've pushed that change up. Do you want me to merge it into ~yellow too?
[14:30] <bac> gmb: sure
[14:31] <gmb> Cool
[14:32] <gmb> bac: Merged and pushed.
[14:32] <gmb> I'm heading out to run some errands; I'll be back in an hour or thereabouts.
[14:32] <bac> gmb: thanks.  i'll merge it as soon as possible
[14:42] <bac> gary_poster: i created 'design tweaks' in the backlog
[14:42] <gary_poster> great bac, thanks
[14:42] <bac> the details has a list of items.  it can be decomposed later
[14:42] <gary_poster> sounds good
[14:42] <bac> was there something else that needs to be added to that list?
[14:43]  * gary_poster looks
[14:43] <gary_poster> yes, I can think of one category off-hand.  I'll add what I think of.
[16:36] <gary_poster> bac, this is currently part of the server branch that I am about to submit for review.  Is it problematic for merging into devel, or is it alright?
[16:36] <gary_poster> http://pastebin.ubuntu.com/583858/
[16:45] <gary_poster> benji, maybe you could review this MP draft?  You are the other person with significant work in the server branch.  http://pastebin.ubuntu.com/583864/plain/
[16:45] <benji> gary_poster: sure
[16:45] <gary_poster> thanks
[16:51] <gary_poster> oh meh.
[16:51] <gary_poster> "Add a function to efficiently get a user's structural subscriptions for a bug" should be deleted
[16:51] <gary_poster> and I need to describe "Add a function to efficiently get a user's structural subscriptions for a bug target"
[16:52] <gary_poster> I'm going to go lunch; hopefully I will feel more energized afterwards
[16:55] <benji> gary_poster: I think we can kill expose_user_subscription_status_to_js/userHasBugSubscriptions I can't find any place that we actually use it.  Of course, we need to make sure no one is adding such a place at the moment.
[16:57] <benji> re. the "person_is_team_admin should maybe be preceded with an underline" question: I don't think so; since we're strict about importing only things listed in __all__, there's no need to do the semi-private leading underscore thing.
[16:59] <benji> that's the end of my thoughts on the MP
[16:59]  * benji lunches as well.
[17:28] <bac> gary_poster: the paste you have above should not be included
[17:28] <bac> gary_poster: it needs to be feature flagged
[18:06] <bac> hi benji, question about feature flags
[18:06] <benji> 'sup?
[18:06] <bac> is there an easy way to enable them for lp.dev interactive testing?
[18:07] <benji> you should be able to edit them, let's see what is the url...
[18:07] <bac> oh, yeah, right
[18:07] <benji> https://launchpad.dev/+feature-rules
[18:13] <bac> benji: so i tried adding:
[18:13] <bac> advanced-structural-subscriptions.enabled	default$	10	true
[18:14] <bac> but it does not appear in the list at https://launchpad.dev/+feature-info
[18:14] <bac> and appears inactive
[18:17] <benji> +feature-info only lists documented features; just adding a rule won't make an entry in +feature-info
[18:17] <benji> however, *referencing* a rule that isn't documented will make it show up in the Undocumented flags area of +feature-info
[18:19] <bac> benji: i see that now.
[18:20] <benji> if you haven't seen it, the wiki doc for feature flags is good: https://dev.launchpad.net/FeatureFlags
[18:22] <bac> benji: the problem was i used "default$" as stated in the scope section.  not sure where that errant $ came from
[18:23] <benji> bac: I bet you copy/pasted it from the -info page, where the scopes are given as regular expressions
[18:23] <bac> benji: yes, but is it a regex?  if so, wouldn't 'default$' work?
[18:25] <benji> nope, the scope is a string matched by a regex, the -info page shows the regex the strings match (which in "default"'s case is just a constant so it's wierd)
[18:53] <bac> benji: ok, another dumbish question
[18:53] <bac> the FF flag page says for "booleans" an empty string indicates false
[18:54] <bac> (makes me think "boolean" isn't the proper description)
[18:54] <bac> entering the following into the rule editor:
[18:54] <bac> malone.advanced-structural-subscriptions.enabled	default	10 ''
[18:55] <benji> well, it's really up to the calling code to decide what an empty string is; the FF code just returns strings
[18:55] <bac> gives the FF a value of u"''", which evalutes to True
[18:55] <gmb> bac: s/malone.//
[18:55] <gmb> Unless you've changed it since I merged my branc with ~yellow.
[18:55] <bac> gmb: i did.  i thought it followed the convention better
[18:56] <gmb> Ok.
[18:56] <bac> benji: so the question is, how do you enter a value in the rules editor to indicate false?
[18:56] <benji> I don't remember adding that "Value domains" section, it looks more deceptive than helpful
[18:57] <benji> bac: if you're writing the code that's retrieving and interpreting the value then you get to decide...
[18:57] <bac> benji: that is not consistent with the usage guide
[18:58] <bac> i mean, you're right if you understand you're going to get a unicode value back and you must test it yourself
[18:59] <gary_poster> trying to get things done for the new baby == surprise 2 hour lunch.  oops.
[18:59] <gary_poster> thank you for the feedback bac and benji; I'll incorprate to code and MP
[19:01] <benji> gary_poster: babys are indeed full of suprises. I may soon be reminded of that myself, Katie is starting to want another.  I'm not quite on the same page yet though ;)
[19:01] <gary_poster> benji, wow :-)
[19:02] <benji> bac: yeah, I really don't like the hints on the -info page that there is type conversion going on.  If I added that I hereby repent.
[19:02] <bac> benji: i'm not blaming, i'm 1) trying to understand it, 2) trying to use it properly
[19:02] <bac> the docstring for FF tell you to:
[19:02] <bac> if features.getFeatureFlag('soyuz.derived-series-ui.enabled'):
[19:03] <bac> but that will never work if the feature is edited using the UI
[19:03] <benji> no worries, I have no emotional attachment to previous versions of myself
[19:04] <benji> bac: I /think/ it will work; if you leave it unset you get [some false value] or you can set it using a rule
[19:04] <benji> let me look at the code a little
[19:05] <bac> benji: i think you're right.  but once set it can never be unset, which makes testing a pain as it involves 'make schema' to reset it
[19:06] <benji> bac: I believe there is a testing context manager that lets you temporarily set flags
[19:26] <gary_poster> bac, I have an up-to-date accordionoverlay and I am visiting https://launchpad.dev/firefox and I don't see the add button UI anymore.  Do I need to have the feature flag set now?
[19:26] <bac> for product, yes
[19:27] <bac> gary_poster: gmb did that page and i've now replicated it for others
[19:27] <bac> gary_poster: but my work hasn't been pushed
[19:27] <bac> gary_poster: if you want to see it you'll have to set a value for the feature flag
[19:27] <gary_poster> cool bac, thanks.  I was jusst trying to make sure I hadn't broken anything and was disconcerted to not see it.  Right, so I go to https://launchpad.dev/+feature-info...
[19:28] <bac> malone.advanced-structural-subscriptions.enabled	default	   10 on
[19:28] <bac> gary_poster: add ^^
[19:28] <gary_poster> bac, got it.  thank you.  who do I need to be logged in as?  Mark?
[19:28] <bac> yeah, you need to be some admin-type, i'm sure
[19:29] <bac> mark will work
[19:29] <gary_poster> mm, foo.bar worked too.  cool I guess
[19:31] <gary_poster> bac, I now have "malone.advanced-structural-subscriptions.enabled	default	10	on" but I don't see it working on https://launchpad.dev/firefox
[19:32] <bac> gary_poster: sorry, strip 'malone.' from the front.  i changed the name from what gmb did originally
[19:32] <gary_poster> ack
[19:33] <bac> the instructions for flags indicated an app area prefix was needed.  if you don't think so let me know and i'll remove it
[19:33] <gary_poster> bac, what you did sounds fine
[19:34] <gary_poster> and it is working now thank you
[20:01] <gary_poster> Unleash THE KRAKEN!
[20:01] <gary_poster> https://code.launchpad.net/~gary/launchpad/accordionoverlay-server/+merge/54415
[20:04] <gary_poster> benji, if you run out of cards, as seems all too possible, please take a look at the 739141 defect card in Quick Jobs
[20:05] <benji> gary_poster: k.  I hope to be done with this little card (description whitespace) in a few minutes; I'll look at 739141 next
[20:05] <benji> gary_poster: are we ready for more merges into ~yellow?
[20:06] <gary_poster> yes, benji, no problem.  If they are server side and should be reviewed as such maybe let me know, but we're good AFAIK
[20:06] <benji> nope, all JS
[20:21] <gary_poster> cool
[20:59] <gary_poster> bac, I'm looking at the kanban board and wondering what you will need to have a good client-side branch for review tomorrow.
[20:59] <gary_poster> My take is that you will need the card you are working on, and the card Danilo is working on in Feature Work 2: Coding.  The card to hook up the edit page is a nice-to-have (blocked in feature 1 tasks).  The card Danilo has in fw2: tasks is even less necessary.
[21:00] <gary_poster> Therefore, I'm thinking that we are in a pretty good place for getting the branch ready for review tomorrow as we had hoped.  Do you agree?
[21:00] <bac> gary_poster: i would but i'm having difficulties with my branch
[21:00] <bac> the tests with feature flags are not working as i expected
[21:00] <gary_poster> bac, I see. Anything I or anyone else can do to help?
[21:01] <bac> gary_poster: i could talk it over with you if you like.  perhaps you might see something i'm doing silly
[21:01] <gary_poster> bac, I'm happy to if you think it would help.  Now or tomorrow morning?  I need to leave to take care of kids in 15, fwiw
[21:02] <bac> gary_poster: now is fine...let's make it quick
[21:02] <bac> http://paste.ubuntu.com/583988/
[21:02] <gary_poster> k
[21:06] <gary_poster> with feature_flags():