[01:11] <lifeless> hmm, I wants  areviewer
[01:11] <lifeless>  https://code.launchpad.net/~lifeless/launchpad/cachedproperty/+merge/32728
[01:11] <lifeless> anyone up for it ?
[01:11] <lifeless> mwhudson: not that I'm stalking you or anything .... pretty please?
[01:11]  * mwhudson looks
[01:16] <mwhudson> lifeless: i guess you grepped for existing __storm_invalidate__ methods so i don't have to? :)
[01:16] <lifeless> yeah
[01:16] <lifeless> in devel as of latest commit a couple of hours ago
[01:16] <lifeless> of course, folk can still add them
[01:17] <lifeless> so it needs a psg update, mail to the list, various repeats etc etc
[01:20] <mwhudson> lifeless: approved
[01:21] <lifeless> \o/
[01:23] <lifeless> mwhudson: click the other button too
[01:23] <lifeless> (please)
[01:23] <mwhudson> lifeless: done
[01:23] <mwhudson> lifeless: can't you do that though?
[01:24] <lifeless> mwhudson: I can, but its a pita :)
[01:24] <mwhudson> ok
[01:24] <lifeless> so I try to do it for other people when I review their branches
[01:24] <lifeless> so that when they are told approved, they just need to do 'ec2 land'...
[01:24] <lifeless> rather than reopen the web page, etc etc
[01:25] <lifeless> anyhow thanks heaps for the review
[01:25] <lifeless> sorry if that last bit came across grumpy
[01:25] <lifeless> its just high friction
[01:27] <mwhudson> yeah, it was a slip on my part i agree
[01:27] <mwhudson> thanks for the prod
[01:40] <lifeless> hah, so the SQLBase super() call is bogus
[01:40] <lifeless> because the base class doesn't have one, so I'll nuke that :)
[01:41] <lifeless> (the test suite does blow up, I just hadn't run model class tests ;P)
[02:51] <lifeless> mwhudson: around? I'm about to pop in a fix or two to that branch (nonobvious in foresight, clear in hindsight)
[03:00] <lifeless> mwhudson: rev 11352 and 11353 on lp:~lifeless/launchpad/cachedproperty
[03:02] <mwhudson> lifeless: looking
[03:03] <lifeless> thanks!
[03:06] <mwhudson> lifeless: looks fine
[03:06] <lifeless> thanks
[03:06] <mwhudson> the need for 11353 is a bit depressing
[03:06] <lifeless> yes
[03:06] <mwhudson> hm
[03:06] <mwhudson> oh nm
[03:06] <lifeless> OTOH its good that folk are *already* using cachedproperty :P
[03:06] <mwhudson> was thinking that maybe you could write this as self.cachedprop.cache(value)
[03:06] <mwhudson> but obviously not
[03:07] <mwhudson> because of what self.cachedprop does :)
[03:08] <lifeless> yes
[03:08] <lifeless> it would be lovely
[03:08] <lifeless> but sadly, DENIED
[03:08] <lifeless> it might be an idea to make _cachedproperties a dict
[03:08] <lifeless> and then clear_properties can just replace the dict
[03:09] <lifeless> but since its now nicely abstracted ('nicely') we can do that later.
[03:09] <mwhudson> well, i guess you can do self.__class__.cachedprop
[03:10] <lifeless> I don't think so
[03:10] <lifeless> when the decorator is invoked you get a bare function
[03:10] <lifeless> no im_class attribute
[03:10] <lifeless> and definitely no instances (instances being what have __class__)
[03:10] <lifeless> oh, I see
[03:11] <lifeless> uhm, yes, we could make it into a obj with methods that you access via self.__class__.publicname
[03:11] <lifeless> self.__class__.publicname.clear(self)
[03:11] <lifeless> it a tad ugly
[03:12] <mwhudson> yeah, i think it's a bit ugly
[03:13] <mwhudson> so let's stick with what you have for now
[08:49] <henninge> Bring on your branches!
[10:13] <StevenK> henninge: Hi! :-)
[10:19] <lifeless> henninge: hi, I've made some changes to a branch sinzui approved, how do you feel about an incremental review ?
[10:20] <henninge> lifeless: Unless it's urgent I'd like you to take it back to sinzui, actually .. ;-)
[10:21] <lifeless> henninge: well, given ec2 takes 4 hours to land stuff, I was hoping to throw it in overnight :)
[10:21] <henninge> ah right, forgot were you are ... ;)
[10:21] <lifeless> :P
[10:22] <henninge> lifeless: put it on the queue
[10:23] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/32067
[10:23] <lifeless> henninge: there is one commit in particular I want to discuss - http://bazaar.launchpad.net/~lifeless/launchpad/registry/revision/11324
[10:23] <lifeless> which is not domain specific
[10:23] <lifeless> when you're done with mr K
[10:23] <henninge> ok ;)
[10:24] <StevenK>  Mine is only a widdle branch
[10:24] <henninge> StevenK: Hi! Looking ;
[10:27] <henninge> StevenK: I seem to remember that we voted in favor of lifeless' suggestion about on-import-per-line. Unless I am mistaken, could you please restructure the import lines that you touched?
[10:27] <henninge> StevenK: other than that, r=me ;-)
[10:27] <lifeless> we did, imports are now like any other list.
[10:28] <lifeless> well, nearly - still alpha-sorted please :)
[10:29] <lifeless> henninge: so, my branch looks big, but all the bulky stuff is already reviewed
[10:30]  * henninge looks
[10:30] <lifeless> I've explained in the review page the incremental stuff I would love to have more eyeballs on
[10:31] <henninge> danilos: the branch is ready for review btw.
[10:31] <danilos> henninge, cool, thanks, I'll take a look at it as soon as I am done with the debugging I am doing right now
[10:37] <henninge> lifeless: looking at r11324, you should call the result of removeSecurityProxy "naked_instance" or use rSP in place.
[10:37] <lifeless> sure, I can do that
[10:42] <henninge> lifeless: why do you (think you) need the rSP calls?
[10:42] <lifeless> because model objects hold security proxied references to other model objects
[10:43] <lifeless> and having many little 'clear_method_x' named functions in the public interface would make me want to stab my eyeballs out :)
[10:44] <lifeless> I think a few more iterations and we'll come up with some good way of managing these things that fits with interfaces and security proxies, but right now its very adhoc: these two branches clean it up a lot (IMNSHO), but also find the limits of the self same cleaned up protocol
[10:49] <henninge> lifeless: I have to admit I am on shaky ground here ...
[10:50] <lifeless> ok
[10:50] <lifeless> this is something new
[10:51] <lifeless> I don't think that *anyone* can say 'I know all this stuff and its definitely good/bad/whatever'
[10:51] <lifeless> there are acknowledged risks - and you can see curtis's comment: land it and we'll fix what breaks
[10:51] <lifeless> these incremental changes are simply the first things that goes boom :)
[10:56] <henninge> lifeless: actually, my original question about the "why" was if you did see tests failing without the rSP in place. In your comment on the MP you say that you are not sure if they are needed at all.
[10:56] <lifeless> henninge: oh, I mean sttructurally
[10:56] <lifeless> like
[10:57] <lifeless> can we find some (within scope of this branch) way to not need them
[10:57] <lifeless> but I couldn't see one
[10:57] <lifeless> ArchiveSet.new
[10:57] <lifeless> references owner.archive
[10:57] <lifeless> which populates the cache
[10:57] <lifeless> and then takes an action that invalidates it IFF the result of the lookup was None
[10:57] <lifeless> so the change to archive.py to invalidate has to work when the person object used for owner is security proxied
[11:07] <lifeless> henninge: ?
[11:09] <henninge> lifeless: how about this:
[11:10] <henninge> do not do the blanked "removeSecurityProxy" in cachedpropety.py but rather do it in archive.py for the specific use case.
[11:11] <lifeless> henninge: It looks to me like every use is likely to need it
[11:11] <lifeless> AIUI the general case is that external references are proxied
[11:12] <henninge> lifeless: the use of these functions (not the decorator, of course) is quite limited.
[11:12] <lifeless> henninge: of course, they are added today
[11:14] <henninge> lifeless: argh, missed that ...
[11:14] <lifeless> so is_cached clearly has no downside for our code, doing rSP
[11:14] <lifeless> likewise clear_*
[11:14] <lifeless> cache_property *could* be misused
[11:14] <lifeless> but I think it will stand out very clearly where its being used
[11:14] <lifeless> so its ok
[11:15] <lifeless> (IMHO)
[11:15] <henninge> lifeless: well, with these functions being new, we can asses each use of them more easily.
[11:16] <lifeless> that too
[11:16] <henninge> we are not in danger to introduce a security hole where there was none before.
[11:16] <lifeless> so in summary, I'd like to leave rSP in the readonly functions for sure
[11:16] <lifeless> I'm open to moving rSP out of the cache_property call, but I think we'll end up being more annoyed than benefited :)
[11:18] <henninge> lifeless: I tink it is fine as long as it is clear that these are low-level functions that do not care about security.
[11:18] <lifeless> I'll tweak the docstring on cache_property then
[11:18] <lifeless> for the others, I think its not security related as such *anyhow*
[11:19] <lifeless> because you can *at most* find out that an attribute exists, not get its value
[11:19] <henninge> lifeless: can you please create a seperate doctest for these functions instead of putting the tests in the docstrings?
[11:19] <henninge> We have been moving tests from docstrings into files.
[11:19] <lifeless> well, doctests are pain anyhow
[11:19] <henninge> I guess that was one reason I thought this was (really) old code.
[11:19] <lifeless> I followed the minimal path doing this though
[11:19] <lifeless> so
[11:20] <lifeless> how about we treat the tests - including the cachedproperty test - as techdebt, and I'll make a new branch to move it to lp.services, clean it up into proper unit tests and so on at the same time.
[11:20] <lifeless> I can do that wednesdayish
[11:21] <henninge> lifeless: that's perfectly fine.
[11:21] <henninge> lifeless: another idea I had: It would be great if the functions could do the same name mangling as cachedproperty itself.
[11:22] <lifeless> deal
[11:22] <lifeless> cachedproperty doesn't name mangle :)
[11:22] <lifeless> oh, I see the line you mean
[11:22] <lifeless> uhm
[11:22] <lifeless> yes, I can pull that out
[11:22] <lifeless> problem is
[11:22] <lifeless> we don't have the original fn to examine
[11:22] <lifeless> so we could *claim* it was called 'foo'
[11:22] <lifeless> and mangle that
[11:22] <lifeless> but that will fail for all cases where an explicit cached attribute name was chosen
[11:23]  * henninge greps
[11:23] <lifeless> so we'd need another parameter to say 'and don't mangle this' (or we'd probe twice)
[11:23] <lifeless> line 76
[11:23] <lifeless> probing twice is unneeded overhead
[11:24] <henninge> lifeless: how about a named parameter?
[11:24] <lifeless> and having two parameters for utility functions seems a bit ugh. I'd rather work on being able to do stuff with the actual descriptor
[11:24] <henninge> clear_property(owner, attr='archive')
[11:24] <henninge> clear_property(owner, name='_archive_cache')
[11:24] <henninge> ?
[11:25] <lifeless> do you think it adds much ?
[11:25] <lifeless> can always add it later if we decide we want it after all
[11:25] <henninge> I just think that the name mangling should be black boxed.
[11:26] <lifeless> so, we couldn't really do this until I added these helper functions anyhow
[11:26] <lifeless> I think you're right that it would be nicer to not require folk to thing about this
[11:26] <lifeless> I have two concerns
[11:26] <henninge> yes, what I mean. Using cachedproperty is quite transparent atm
[11:27] <lifeless> henninge: well, many users do cachedproperty('_name_to_use') already
[11:27] <lifeless> anyhow concerns
[11:27] <lifeless> setattr(thing, 'name', value)
[11:27] <lifeless> ==
[11:27] <lifeless> cache_property(thing, 'name', value)
[11:27] <lifeless> so its easy to translate in your head
[11:28] <lifeless> cache_property(thing, attrname='name', value) # This is not legal python
[11:28] <lifeless> so it would have to be
[11:28] <lifeless> cache_property(think, value, attrname='name')
[11:28] <lifeless> cache_property(think, value, attr='name')
[11:29] <lifeless> which is the oppposite order and I worry that that is prone to confusion
[11:29] <lifeless> I think I'd rather add in mangling versions later, if we need them
[11:29] <henninge> I understand.
[11:29] <henninge> Sure, was just my idea.
[11:29] <lifeless> cache_attribute(thing, unmangled, value)
[11:29] <lifeless> henninge: its a good idea
[11:29] <lifeless> needed thought :)
[11:30] <henninge> Here's another one ;)
[11:30] <henninge> for a future branch.
[11:30] <henninge> It would be great to be able to prevent caching in the first place.
[11:31] <lifeless> what do you think of waiting and seeing ?
[11:31] <henninge> instead of having to reset it right afterwards.
[11:31] <henninge> yes, just an idea, again ...
[11:31] <lifeless> yeah, that gets back to the descriptor idea
[11:32] <lifeless> 'permit a cache read but don't do a cache write'
[11:35] <noodles775> henninge: Easy branch testing and fixing a recent JS breakage: https://code.edge.launchpad.net/~michael.nelson/launchpad/561586-qa-fail/+merge/32745 (63 lines)
[11:37] <henninge> lifeless: r=me ;-)
[11:38] <henninge> Hi noodles775! ;-)
[11:38] <henninge> Let me see if I can do this before lunch ... ;)
[11:39] <noodles775> Thanks henninge
[11:41] <lifeless> henninge: thank you!
[11:41] <henninge> lifeless: pleasure
[11:42] <henninge> noodles775: lint should complain about two extra blank lines at the end of the file ...
[11:42] <noodles775> henninge: yes it did, and I fixed them, and forgot to push...
[11:42] <henninge> noodles775: np, r=me
[11:42] <noodles775> Great, thanks henninge.
[13:43] <jtv> henninge, got a review for ya: https://code.edge.launchpad.net/~jtv/launchpad/recife-karmarecorder-fix/+merge/32756
[13:46] <henninge> jtv: thanks ;)
[13:47] <jtv> henninge: you are ironing, I'm sure :)
[13:47] <jtv> Or whatever the verb for "being ironic" is
[13:47] <henninge> Now, I am done with my houshold chores. ;)
[13:47] <henninge> s/Now/No/
[13:48] <henninge> jtv: XXX: Module docstring goes here.
[13:48] <jtv> henninge: whoa, thanks
[13:49] <jtv> henninge: do I see you're also waiting for a review?
[13:49] <henninge> jtv: yes, danilo hat offered to take it but if he is not up to it, I'd be happy if you could do it.
[13:50] <jtv> henninge: ah, that's the one you mentioned in the call…  Yes, I think I can do that.
[13:50] <henninge> jtv: where is he anyway?
[13:50] <jtv> Just moving in mysterious ways, I'm sure.
[13:53] <henninge> jtv: comments on the tests wouldl be nice. ;)
[13:54] <jtv> henninge: can do
[13:56] <jtv> Done.
[13:59] <jtv> henninge: in your branch, in _makeTranslationsDict (diff line 8): if translations can be None, maybe it should just default to None—more conformant with factory practice.
[14:01] <henninge> jtv: I have copied that behavior from make TranslationMessage.
[14:01] <jtv> henninge: …where it has no business conforming with factory practice.  Here, it does.  :-)
[14:01] <jtv> henninge: then, I wouldn't document the method as "making sure" the data is in a particular format—it's a bit ambiguous as to what happens if it isn't.
[14:02] <henninge> jtv: is it not consistent with factory practice to make up a value of None is passed in?
[14:03] <jtv> henninge: it is consistent with factory practice to let a parameter default to None if you're going to accept a None and fill in a random value for testing.
[14:03] <jtv> So (self, translations=None) instead of (self, translations)
[14:06] <henninge> jtv: r=me btw
[14:06] <jtv> henninge: great, thanks
[14:06] <henninge> let me look at that
[14:10] <henninge> jtv: ah, now I understand what you want. But this is an internal method, so the outward behavior is consistent as it is "makeSuggestion(translations=None)"
[14:10] <jtv> henninge: ok
[14:10] <henninge> But I can add the default paramter, np.
[14:10] <jtv> henninge: moving on to the second line…  :-)
[14:10] <henninge> :-P
[14:11] <jtv> henninge: I wouldn't lead with "the right format" (IIRC the original code committed the same horror).  What matters is that you want the dict format.  Maybe an example would say it more clearly and in fewer characters: {0: 'foo'}
[14:14] <gmb> henninge, I have a short branch to add to your queue if that's okay.
[14:19] <jtv> henninge: I can't help but feel that trying to name all types that are a sequence but not a dict is a losing game…  do tuples really matter there?  What about ResultSets?  Maybe you could rearrange the test: if translations is None / elif isinstance(translations, dict) / else
[14:19] <jtv> The "else" part would return dict(enumerate(translations))
[14:20] <danilos> jtv, btw, are you reviewing henninge's branch?
[14:20] <henninge> danilos: he is, shouldn't he?
[14:20] <danilos> sure :)
[14:20] <jtv> danilos: yes… to keep him busy while we didn't hear from you :-)
[14:20] <jtv> It's eod here, but that also means it's too late to do other things.  :)
[14:20] <henninge> gmb: that is ok
[14:20] <danilos> henninge, jtv was only supposed to be out by now :)
[14:20] <henninge> ;-)
[14:21] <henninge> danilos: he basically begged me to be allowed to review it.
[14:21] <henninge> I tell him "It's Danilo's!"
[14:21] <henninge> He says "Oh no, please, please, not him!"
[14:21] <danilos> henninge, hehe, don't worry, I don't mind too much :)
[14:21] <jtv> gee, how lucky (!)
[14:22] <jtv> henninge: there's no more need to do a separate setSequence after a makePOTMsgSet… just pass the sequence number to makePOTMsgSet.
[14:22] <jtv> henninge: oh, and when you use assert, there has to be an explanatory string.
[14:23] <henninge> gmb: bug 618606 ?
[14:23] <_mup_> Bug #618606: Add bug_subscription_level to the BugSubscriptionModel <story-better-bug-notification> <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/618606>
[14:25] <gmb> henninge, Sure. Sorry, missed your first ping.
[14:26] <henninge> gmb: would it be too much for this branch to move BugNotificationLevel to lp.registry.enum?
[14:26] <henninge> Why is it in registry in the first place?
[14:27] <sinzui> henninge, structural subscriptions
[14:27] <henninge> sinzui: ok
[14:27] <gmb> henninge, I have no idea. I'd be +1 on moving it to lp.bugs.enum, given that it's bug-specific. Either that or changing it to SubscriptionNotificiationLevel
[14:27] <gmb> And leaving it in lp.registry.
[14:27] <sinzui> henninge, SS are some what problematic because when fully implemented, they would know about bugs, specs, questions, and branches
[14:28] <henninge> sinzui: so it should be lp.coop/inter/shared.enum ... ;-)
[14:28] <henninge> whatever we decide on ... or have we already?
[14:28] <sinzui> henninge, registry is exempt because every app depends on it...but that is also why it is problematic
[14:29] <sinzui> henninge, I think the db scheme is the origin of the problem maybe
[14:29] <henninge> sinzui: Is there a problem with putting it in lp.registry.enum ?
[14:30] <sinzui> No
[14:30] <henninge> cool ;)
[14:30] <henninge> gmb:  ^
[14:30] <gmb> Righto.
[14:30] <gmb> sinzui, Should it be renamed to something more generic so that it can be reused across different SS targets?
[14:31] <gmb> (e.g. SubscriptionNotificationLevel)
[14:31] <sinzui> good idea
[14:31] <henninge> gmb: good idea
[14:31] <henninge> ;)
[14:31] <gmb> Cool
[14:31] <gmb> Will do.
[14:32] <gmb> I'll file a bug about renaming the attributes, since that's more work.
[14:32] <gmb> s/attributes/attributes and db fields/
[14:37] <gmb> Ah.
[14:38] <gmb> henninge, sinzui: Maybe the rename doesn't make sense after all. There's also a BlueprintNotificationLevel.
[14:38] <gmb> So the rename makes sense if we're converging on one enum.
[14:38] <sinzui> :(
[14:38] <gmb> But I think that's out of scope for this branch.
[14:38] <gmb> I'll do the move though and update the import sites.
[14:40] <sinzui> gmb: We can revisit this in a few weeks when I need to look at ACLs for privacy. Maybe I can introduce a generic form for all artefacts
[14:40] <gmb> Right
[14:49] <henninge> gmb: r=me ;)
[14:49] <gmb> henninge, Thanks.
[14:55] <jtv> henninge: did you get my comments about the docstring, and about rearranging the conditions in _makeTranslationsDict?
[15:03] <jtv> henninge: could you please re-run "make lint"?  There's plenty of stuff in the diff that it would have complained about, so I think your previous run was incomplete somehow.
[15:13] <henninge> jtv: what was that about rearranging conditions?
[15:14] <jtv> henninge: Naming all types of sequence that might make up a non-dict translations list is probably a losing game: is it really necessary to accept tuples?  What about ResultSets?  If it's really needed, consider rearranging the conditions: "if translations is None / elif isinstance(translations, dict) / else" (where the "else" part returns dict(enumerate(translations)))
[15:14] <henninge> jtv: ah, god idea.
[15:15] <jtv> well I wouldn't go _that_ far…
[15:17] <jtv> henninge: I've got a ton more, a lot of it clearly not your doing.  I'll paste in the review.
[15:19] <henninge> jtv: well, I was aware that I would not catch all iterables but that's what the assert was for. But this is just as good.
[15:19] <henninge> s/but/and/
[15:20] <jtv> henninge: note that the assert would have needed an explanatory string btw.
[15:21] <jtv> And speaking of strings, I suppose if we treat everything else as an iterable, then someday we're going to pass a string instead of a list by mistake and get ['f', 'u', 'n', 'n', 'y'] results.
[15:21] <jtv> So that assertion may still be worthwhile.  :-)
[15:23] <henninge> jtv: but then I'd be checking isinstance(translations, dict) twice ... :(
[15:24] <henninge> I think I'll return to the first structure and just add the comment to the assert.
[15:24] <jtv> henninge: well the assertion on dict type wouldn't be needed, would it?
[15:24] <henninge> which assertion were you referring to?
[15:25] <jtv> Sorry: I mean, you can assert on the right type—but in the clause for sequences.  So assert isinstance(translations, (list, tuple)).
[15:25] <jtv> Then if we find that e.g. ResultSets need supporting, all we need to do is add that type to the assert.
[15:26] <jtv> (I think the error message would be clearer that way than with the current structure)
[15:26] <henninge> huh, so now we *are* back to the original structure? I am confused.
[15:27] <jtv> henninge: no, I'm referring to the original structure as the current one.
[15:27] <jtv> henninge: I can't see what you have locally.
[15:27] <henninge> you cannot? :-o
[15:28] <jtv> henninge: so I'm saying it would be good to do something like…  if translations is None: return {0: makeString()} ; elif isinstance(translations, dict): return translations ; else: assert isinstance(translations, (tuple, list)); return dict(enumerate(translations))
[15:29] <henninge> Hm, I don't see the big difference/advantage in that, though.
[15:37] <jtv> henninge: think about what happens if it goes wrong, e.g. because you're getting a ResultSet.
[15:37] <jtv> Think about the failure mode.
[15:38] <henninge> ok, we'd be getting something we don't expect.
[15:38] <danilos> jtv, henninge: is there any reason not to define one single interface (i.e. "only takes a dict")
[15:38] <henninge> jtv: but OTOH we are not checking that the elements of the list are really strings.
[15:39] <jtv> In the original code, you'd get a failure "this is not a dict."  Which would be a fairly silly thing to expect it to be.  In the rearranged version, you'd get a failure "this is neither a list or a tuple."  That would instantly make you think: "clearly there are several things this is allowed to be, and clearly a ResultSet is a lot _like_ a list or tuple."
[15:39] <danilos> (I know I am jumping right into the middle of the discussion, but I'd go with simplest possible APIs)
[15:39] <henninge> danilos: well, lists are passed in many places and this seemed easier than checking all call sights.
[15:39] <henninge> site
[15:39] <henninge> sites
[15:39] <jtv> s
[15:40] <henninge> jtv: ok, let's end this here. ;-)
[15:40] <jtv> uh-oh… are we talking gunfight in the street?
[15:43] <henninge> jtv: nah, this is just taking longer then it is worth. Any idea for a good failure message for the assertion?
[15:43] <henninge> "Translations must be in a dict, list or tuple."
[15:43] <jtv> henninge: er... "Expecting either a dict or a sequence"?
[15:44] <jtv> (so as to document intent, not what the code does)
[15:45] <henninge> ok
[15:45] <jtv> I pasted the rest of my notes in the MP.
[15:46] <henninge> jtv: here is the lint output before any changes, btw.
[15:46] <henninge> http://paste.ubuntu.com/478885/
[15:46] <jtv> henninge: maybe some messages are being suppressed then.
[15:47] <henninge> I think the linters expectations on blank lines need to be fixed and I don't know what form to raise exceptions in ...
[15:47] <henninge> jtv: thanks
[15:47] <henninge> for the review
[15:47] <henninge> have not seen it yet, though :-P
[15:47] <jtv> henninge: it's rather a lot, and mostly probably not about stuff you did so feel free to push back a bit
[18:12] <sinzui> EdwinGrubbs, I shot myself in the foot with a bad branch and I used my own project for the test.
[18:12] <sinzui> EdwinGrubbs, Can you read through this bug and then talk to me about whether my proposed fix will help undo future damge: https://bugs.edge.launchpad.net/launchpad-registry/+bug/522599
[18:21] <EdwinGrubbs> sinzui: I'm looking at it now.
[18:30] <sinzui> EdwinGrubbs, I am ready to mumble and explain how I screwed up
[18:44] <sinzui> EdwinGrubbs :Store.of(bugtask).remove(bugtask.conjoined_master)
[19:16] <lifeless> sinzui: hiya
[19:19] <sinzui> hi lifeless
[19:42] <salgado> anybody willing to review a small branch for me? https://code.edge.launchpad.net/~salgado/launchpad/vostok-no-external-redirect/+merge/32623
[19:45] <sinzui> salgado, yes
[19:46] <salgado> sinzui, yay, thanks!
[19:46] <sinzui> salgado, I have a 25 line branch I wanted reviewed. the mp will show up in a few minutes. Can you take a look at it when it does.
[19:47] <salgado> sinzui, sure
[19:51] <sinzui> salgado, Is your branch intended to ensure any reuse of lp logic does not take the user to lp.net?
[19:52] <salgado> sinzui, yes, but it's a nice-to-have safety net anyway.  we only had to remove that in Launchpad because we have multiple hosts we can redirect people to
[19:53] <sinzui> salgado,  I always think links to attachments/changelogs as redirects to the librarian. Will these links still work?
[19:55] <salgado> sinzui, in vostok we probably won't have attachments, but we'll certainly store other things in the librarian, so we might have to change that later to allow redirects to the librarian as well
[19:55] <salgado> but we can worry about that when we need it
[19:56] <sinzui> Will API calls work? Is API not a part of vostock
[19:56] <sinzui> That may be moot. We never redirect to API
[19:56] <salgado> this shouldn't affect the API
[19:59] <sinzui> salgado, r=me. I have no other questions
[19:59] <salgado> thanks sinzui.  where's yours?
[19:59] <sinzui> salgado, https://code.edge.launchpad.net/~sinzui/launchpad/delete-conjoined-bugtask-1/+merge/32796
[20:01] <sinzui> salgado, I should note that Edwin-lunch fixed by project data. But he too saw a bugtask targeted to trunk with no project bug task.
[20:07] <salgado> sinzui, r=me
[20:07] <sinzui> thanks salgado
[20:31] <rockstar> sinzui, since you just got a review, would you please do a (small) review for me? https://code.edge.launchpad.net/~rockstar/launchpad/no-recipes-on-private-branches/+merge/32799
[20:31] <sinzui> I can start in a few minutes
[20:43] <sinzui> rockstar, I had a few questions. Your branch is really fine as it is, but I want to understand if there is something I am missing.
[20:43] <rockstar> sinzui, cool.
[20:45] <rockstar> sinzui, so, I haven't used the formatters in the past because we want to use javascript on this feature (_before_ we call the feature done) and the formatters don't yet let you specify an id.
[20:46] <sinzui> good reason
[20:47] <rockstar> sinzui, I'll use the with person_logged_in
[20:47] <sinzui> Thanks for the explanation. I will update the review with my new insight.
[20:50] <sinzui> rockstar, r=me
[20:50] <rockstar> sinzui, thanks.