=== salgado is now known as salgado-brb === salgado-brb is now known as salgado [15:00] #startmeeting [15:00] Meeting started at 09:00. The chair is barry. [15:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:00] mootbot! [15:00] hello everyone and welcome to this week's ameu meeting. who's here today? [15:00] me [15:00] me [15:00] me [15:00] me [15:00] me [15:01] me [15:02] allenap: BjornT cprov gary_poster ping [15:02] me [15:02] me [15:02] intellectronica: ping? [15:02] salgado: ping [15:02] me [15:03] barry: i did apologise, no? [15:03] intellectronica: you did. sorry. i mssed that [15:03] intellectronica: thanks [15:03] well, i think it's a light day today so let's get to it [15:04] [TOPIC] agenda [15:04] New Topic: agenda [15:04] == Agenda == [15:04] * Roll call [15:04] * Peanut gallery (anything not on the agenda) [15:04] * Action items [15:04] * Mentoring update [15:04] i'm going to jump around a bit... [15:04] [TOPIC] action items [15:04] New Topic: action items [15:04] * barry to look into techniques for eliminating back-patching of schema types (avoiding circular imports) [15:04] i actually did look into this and tried a few things, but they all failed [15:05] i may do a very simple syntactic sugar branch for this but i might just drop this item [15:05] ping me if you're interested in the gory details :) [15:05] * barry to add `pretty()` functions to reviewers docs [15:05] not done [15:06] * flacoste to work on API reviewer cheat sheet [15:06] he's at the team leads sprint [15:06] i think flacoste probably didn't do this, and he's at tl sprint, so we'll just leave it [15:06] * barry should type faster than mars [15:06] [TOPIC] * Peanut gallery (anything not on the agenda) [15:06] New Topic: * Peanut gallery (anything not on the agenda) [15:07] do you guys have anything not on the agenda? [15:07] barry: abentley had a proposed item [15:07] Yea, but I can't seem to find him. [15:07] * Should new classes be forbidden to use SQLObject compatibility layer, abentley [15:07] bac: thanks [15:08] looks like abentley is away on #launchpad-code [15:08] I think the answer is "Yes" [15:08] rockstar: i agree [15:08] bac: didn't you ping me yesterday about this? [15:08] abentley wrote a new db class that i reviewed yesterday. it was not using storm so i requested he modify it to use storm, as it is my understanding that new db work use the storm api. [15:09] We should deprecate the SQLObject compatibility layer altogether, and convert the old classes to Storm. [15:09] he objected on the grounds the storm api is not as nice as the compatibility layer. [15:09] i did not approve his branch pending the discussion he wanted to have here. [15:09] * barry thinks it's nicer :) [15:09] rockstar: +1 [15:09] rockstar: that was my position [15:09] bac, this is true, but Storm is a Canonical project, so we should be dogfooding and making bug reports, etc. [15:10] barry, storm is nicer? or the compatibility layer? [15:10] rockstar: i totally agree. it's unfortunate that aaron is not here to state his case. [15:10] * barry likes storm [15:10] I can't tell you how happy I am that the LP team is dogfooding reviews. It's allowed us to make all sorts of changes. [15:10] +1 for Storm from me. [15:10] FTR i am +1 on requiring new work be storm api [15:10] +1 as well. I think there's real value in dogfooding. [15:10] i wish abentley was here too [15:10] +1 too [15:11] [VOTE] +1 to require all new classes to use the storm api [15:11] Please vote on: +1 to require all new classes to use the storm api. [15:11] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [15:11] E.g. /msg MootBot +1 #launchpad-meeting [15:11] +1 [15:11] +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1 [15:11] +1 [15:11] +1 received from adeuring. 2 for, 0 against. 0 have abstained. Count is now 2 [15:11] 1 [15:11] +1 [15:11] +1 received from gmb. 3 for, 0 against. 0 have abstained. Count is now 3 [15:11] +1 [15:11] +1 received from bac. 4 for, 0 against. 0 have abstained. Count is now 4 [15:11] +1 [15:11] +1 received from allenap. 5 for, 0 against. 0 have abstained. Count is now 5 [15:11] +1 [15:11] +1 received from gary_poster. 6 for, 0 against. 0 have abstained. Count is now 6 [15:11] +1 [15:11] +1 received from salgado. 7 for, 0 against. 0 have abstained. Count is now 7 [15:12] going once... [15:12] going twice... [15:12] sold! [15:12] barry, i'll take an action item to update wiki to reflect the policy. should it go in PSG? [15:13] unanimous! i'll post this to the ml and we can take objections there [15:13] [ACTION] barry to post storm requirement to ml [15:13] ACTION received: barry to post storm requirement to ml [15:13] abentley: hi! (almost) just in time :) [15:14] me [15:14] Sorry I'm late. Real Life stuff... [15:14] abentley: we were just discussing your agenda item. you have some 'splainin' to do :) [15:14] abentley: no worries [15:14] Okay. [15:15] Personally, I find the SQLObject compatibility shim a better API than the native Storm API. [15:15] So I'd like to keep using it. [15:15] But I've been told that official policy dictates that we use native Storm foo for new classes. [15:15] So I wanted to bring it up for discussion. [15:15] abentley: what is it about the compatibility layer that you like better? [15:16] barry: It doesn't require obtaining stores, it comes with get methods built-in, it comes with constructors built-in. [15:18] abentley: there's unanimous consensus (here, at least) that we should be dogfooding and improving storm, using it for all new classes [15:18] barry, I think abentley is arguing that the SQLObject API *is* an improvement on top of Storm [15:19] Obtaining a store explicitly is a good pattern imho, because we must sometimes decide between master and slave. [15:19] mars: except that it's a horrible hack and i don't think it's even sqlobject-y any more [15:19] allenap: Perhaps, but it's the wrong place to make that decision. [15:19] barry, ah [15:20] allenap: You'd basically have to pass stores down a long call chain. [15:20] in the common case, it's one extra line [15:20] * al-maisan apologizes for being late [15:20] store = Store.of(self) [15:20] okay, two. you have to import Store [15:20] abentley: What barry said. [15:20] barry, but what about choosing between master and slave? [15:21] rockstar: It's still a one liner (imports notwithstanding). Slightly more complex [15:21] rockstar: i recall a discussion of this months ago. the outcome (iirc) is that you almost never really have to decide [15:21] rockstar: you normally let it automatically choose between master and slave based on whether it is a GET or POST request. [15:21] You need to choose between master and slave at the call site, not in the implementation of a getter. [15:21] rockstar: and Store.of() will almost always DTRT [15:21] EdwinGrubbs, so it will figure out the Store automatically? [15:21] barry: RIGHT! We are writing an extra line to no purpose at all. [15:22] I think there are at least two import lines, maybe three, also. [15:22] abentley: well, you can also write it like: Store.of(self).find(...) [15:22] barry: Not in a classmethod or static method. [15:22] abentley: sure, but those aren't the common case [15:22] Which is where you'd put a getter. [15:23] Those are the common case if you're writing a getter. [15:23] rockstar: yes, if you have made a write (POST) in the last few minutes, it will use the master. You only need to choose the master manually, when you can't tell from the browser session that the user needs very up-to-date info. For example, registering a new user or logging in. [15:23] abentley: really? aren't getters usually instance methods? [15:23] barry: They're instance methods for FooSet classes [15:23] gmb: right [15:23] But we want to get rid of unnecessary *Sets, IIRC. [15:24] gmb: oh i see, you don't have a db object at that point. yeah [15:24] gmb: I don't use FooSets. Classes are perfectly good utilities. [15:24] abentley: ... which is why we want to get rid of unnecessary *Sets. [15:24] Instead of class= you do component= and you're laughing. [15:26] barry: I haven't been allocated time to improve the Storm API, and I'm not sure what kinds of changes are welcome. [15:26] barry: It seems like the lack of constructors was a design choice, since all other ORMs do them. [15:27] barry: So I don't think I'd be able to make Storm work as conveniently as the compatibility shim. [15:27] abentley: this all comes down to basic dogfooding rule #1. same as for bzr, merge proposals, lazr.config, and on-and-on [15:27] we have dogfooding rules? [15:28] * barry recalls a rather lengthy ml discussion about dogfooding recently :) [15:28] ok, I'll look it up [15:29] mars: well, it's related to merge proposals and their emails [15:29] barry, ok, so what's rule #1 then? [15:29] barry: You'll note that in that discussion I didn't say "we must not use ML", I said we should work toward not needed to use MLs. [15:30] mars: i'm making it up as i go, but "we should dogfood our own technology and improve it" [15:30] even if that means sending a message to gustavo and/or the storm list with suggestions [15:31] iow, it would be great for abentley to send an email explaining where he finds the native api to be less ideal so we can at least start a dialog about if/how to improve it [15:32] abentley: i'm not saying your complaints about storm are without merit, just saying we should improve storm instead of punting [15:33] that's just my opinion though so if there's disagreement about that, please speak up! [15:33] barry: +1 on not punting. [15:33] barry: How about we not punt and change the shim into an explicit storm-for-launchpad library? [15:34] abentley, you should look up the "Five Whys" from lean. It's a quality practice. I think you've asked why #1, but that leaves maybe four more :) [15:35] abentley: the goal should be to eventually get that merged into storm. unless there's compelling reasons to maintain our own shim i think the entire storm community should benefit from our experience [15:35] barry: Sounds good to me. [15:36] We can call it "mildstorm" [15:36] "turbulence" [15:36] i prefer squall [15:36] blizzard [15:36] * barry looks out the window and suggests "blizzard" [15:36] mars: damn you again! :) [15:36] barry: I hear ya. [15:37] just not "nor'easter" -- god i hate that [15:37] sounds good. abentley, start with an email to the ml. let's get the specific issues on the table. please cc gustavo [15:38] Okay. [15:38] thanks [15:38] abentley: a side-by-side comparison of the class your new class from yesterday may be a good example [15:38] I take it not using the shim *really is* official policy? [15:38] doh, not writing english today [15:38] [ACTION] abentley to email ml and gustavo with suggestions for improving storm [15:38] ACTION received: abentley to email ml and gustavo with suggestions for improving storm [15:38] abentley: for new classes, we really don't want to use the shim [15:39] bac: I'll update my branch accordingly. [15:39] thanks. good discussion. anything else on this or any other non-agenda topic? [15:39] abentley: thanks. and thanks for bringing the discussion here. it was very useful. [15:40] bac: Cool. [15:40] ok, one last thing before we break [15:40] [TOPIC] * Mentoring update [15:40] Vote is in progress. Finishing now. [15:40] Final result is 7 for, 0 against. 0 abstained. Total: 7 [15:40] New Topic: * Mentoring update [15:40] any update from mentors or mentats? [15:42] no news is good news! [15:42] #endmeeting [15:42] Meeting finished at 09:42. [15:42] thanks everyone! [15:42] bye [15:42] thanks barry [15:43] thanks, barry === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === thumper_laptop is now known as thumper