[13:29] bac benji (are you really here?) danilos gmb: kanban now-ish, skype almost now-ish [13:29] quack-quack [13:30] Baa. [13:30] gary_poster had a farm, ee [13:30] [13:30] i ee i o. [13:30] lol [13:30] :) [13:36] https://dev.launchpad.net/LEP/BugLinking [13:36] https://bugs.edge.launchpad.net/launchpad/+bug/95419 [13:36] <_mup_> Bug #95419: Record dependencies between bugs

< https://launchpad.net/bugs/95419 > [13:38] gmb, gary_poster: I assume bug 674815 is "fix released" (Rob added it to our bug "view")? [13:38] <_mup_> Bug #674815: When a bug is marked as duplicate, you are invited to subscribe to the master bug

< https://launchpad.net/bugs/674815 > [13:49] benji, please make sure you keep me/us apprised as to what you are working on so we can take over if the germs win today's battle [13:50] gary_poster: sure; at the moment I'm fixing a bug I found in my 777786 branch, but once that's in the rube goldberg machine of landing I'll start another one. [13:50] cool [13:50] if there's one in particular you like, let me know [13:53] bug 784575 is the new one [13:53] <_mup_> Bug #784575: Change bug notification email to point to new bug +subscriptions page to manage subscriptions < https://launchpad.net/bugs/784575 > [13:55] benji, you could prepare a branch for that, even though we could land that; or just pick one. bug 777789 and bug 781987 are the other good candidates that I see. [13:55] <_mup_> Bug #777789: "Other subscriptions" description of direct team subscription makes no sense < https://launchpad.net/bugs/777789 > [13:55] <_mup_> Bug #781987: when a bug has no subscribers the list is shown as 'None' < https://launchpad.net/bugs/781987 > [13:56] sounds good [13:56] "even though we could land that" -> "even though we would land that at a later date" [14:18] bac benji danilos gmb, I've mentioned this to some of you in our pdr calls, but I was not consistent about it. I thought of another goal that could be shared across the squad: we deliver value consistently within two week increments. We will be evaluated by this collectively (as a squad), so it might be reasonable to call it out in our individual goals as well. I won't require it, but it's a good idea, I think. [14:18] I like it. [14:18] cool [14:18] So do I. [14:19] très bien [16:28] benji, extra points for a branch that removes the feature flags at the same time :-P [16:29] will I get a 1up too? I could use an extra life right about now. [16:29] heh, not in my power to grant :-) [16:30] extra points: ...I think.... Eagerly getting rid of the feature flags does make me a bit nervous, but AIUI that's what we are asked to do [16:31] well, in this case we pretty much have to; the email sending can't be feature flagged (as far as I know) so everyone's emails will be sending them to a place that they might not be able to see unless we open up the feature flag to everyone, which is equivelent to just removing them [16:32] ("them" == "feature flags", not the people) [16:57] yeah makes sense [16:59] Wouldn't it be safer to just open the feature flags up to everyone, land the branch that adds the link to the emails and then wait a week or so to remove the flags from the code? [16:59] I'm thinking about the cost of rolling back if we need to [16:59] (Though I guess with bzr it's pretty much moot) [16:59] (Aside from LOSA time) [17:00] benji, gary_poster ^^ [17:00] (Which I say with no context or knowledge of anything you may have said about this recently) [17:00] gmb, I think this is the logic: [17:01] if we send emails with links to the page, then the feature flag better be open to everyone or gone [17:01] links are not feature flagged [17:01] the email links I mean [17:01] So here's a bad story [17:01] followed by a good story [17:02] The Bad Story [17:02] 1) we open up feature flags for everyone [17:02] 2) we land a branch that adds a link to the email [17:02] 3) oh noes! Bad Things Happen! [17:03] 4) we turn off the feature flag for everyone (but don't revert the branch) [17:03] Result: emails are being sent out to a page that doesn't work [17:03] that is, that is feature flagged [17:03] The Slightly Better Story (known here as The Good Story, In Comparison) [17:04] 1) we open up feature flags for everyone [17:04] 2) we land a branch that adds a link to the email [17:04] 3) oh noes, etc. [17:05] (oh, sorry, #2 was supposed to also remove feature flags) [17:05] 4) We revert branch for #2 [17:05] Result: emails are sent with the old, working link [17:05] Admittedly, it is somewhat slower [17:05] but the end result is better [17:06] We can wait a bit after step 1 (in either story) to see if we can prevent #3 from happening, of course [17:06] The othe advantage of The Slightly Better Story is that, if #3 never happens, we have done what we are supposed to do (remove the feature flags) [17:07] So anyway, I suppose one could argue either way, but I'm happy with going with the second approach [17:07] gary_poster: Okay. I'm officially ±0 as far as one way of doing it over the other. Like I said, bzr reduces the cost, except for LOSA time. [17:07] gmb, fair enough, and agreed [17:09] * gary_poster going for a lunch/walk, since my coding project is making me grumpy :-P [17:09] :) [19:34] hi gary_poster [19:34] gary_poster: you post-grumpy? [19:34] :-) [19:35] mostly but on call [19:35] np [19:53] bac, wassup? [19:53] gary_poster: not much. was just going to run a text change by you before i submitted my branch. too late now. :) [19:53] idle chit chat mainly [19:53] heh, ok :-) [19:54] s/None/No subscribers./