| === salgado-afk is now known as salgado | ||
| === mrevell is now known as mrevell-lunch | ||
| === Ursinha-afk is now known as Ursinha | ||
| === mrevell-lunch is now known as mrevell | ||
| === gary_poster_ is now known as gary_poster | ||
| bac | #startmeeting | 15:00 |
|---|---|---|
| MootBot | Meeting started at 09:00. The chair is bac. | 15:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:00 |
| danilos | hi | 15:00 |
| gary_poster | me? | 15:00 |
| jelmer | me! | 15:00 |
| mars | moo | 15:00 |
| * bigjools on the edge of my seat | 15:00 | |
| adeuring | me | 15:00 |
| EdwinGrubbs | me | 15:00 |
| abentley | me¡ | 15:00 |
| sinzui | me☢ | 15:01 |
| bigjools | how do you keep a bunch of wankers in suspense | 15:01 |
| * mars pokes the meeting chair | 15:01 | |
| bac | mars: ? | 15:02 |
| * gary_poster wonders if bac's connection died | 15:02 | |
| bac | huh? | 15:02 |
| bac | am i not here? | 15:02 |
| gary_poster | we were expecting you to tell us to say "me" :-) | 15:02 |
| bac | i never say me | 15:03 |
| mars | bac, dude, where's the protocol? :) | 15:03 |
| bac | it's embedded in #startMEeting | 15:03 |
| bac | [topic] agenda | 15:03 |
| MootBot | New Topic: agenda | 15:03 |
| bac | == Agenda == | 15:03 |
| bac | * Roll call | 15:03 |
| bac | * Agenda | 15:03 |
| bac | * Outstanding actions | 15:03 |
| bac | * New topics | 15:03 |
| bac | * try/else/finally is considered harmful in doctests [curtis] | 15:03 |
| bac | * Peanut gallery | 15:03 |
| bac | [topic] outstanding actions | 15:04 |
| MootBot | New Topic: outstanding actions | 15:04 |
| bac | so lifeless and i are having this inefficient discussion: | 15:04 |
| bac | * lifeless: to set a policy on what can live in lib/lp, lib/services, and lib/coop | 15:04 |
| bac | ** I plan to ignore this, folk seem to have the idea already ** | 15:04 |
| bac | ** Please reconsider. This item came about because we couldn't figure it out ourselves. Some people won't use 'coop' due to its name. Personally I don't know the difference. --bac ** | 15:04 |
| flacoste | me | 15:04 |
| bac | so my question for the reviewers, is this really an issue? we originally asked bjorn for an opionion b/c none of really knew what went where wrt services and coop/co-op | 15:05 |
| bac | er, 'none of us' | 15:05 |
| bigjools | I bet the code guys hate it when using tab completion | 15:05 |
| bac | bigjools: that plus the name | 15:06 |
| abentley | bigjools, I actually hate that 'code' is a prefix of 'codehosting'. | 15:06 |
| danilos | what do we have in coop? | 15:06 |
| bac | answerbugs | 15:06 |
| sinzui | bug-answer | 15:06 |
| bigjools | if that is all, why not lib/lp/answersbugs | 15:06 |
| sinzui | coop is for cross app dependancies | 15:06 |
| sinzui | registry exempted | 15:06 |
| danilos | sinzui, right, but we haven't really went forward with it | 15:06 |
| bigjools | I must admit, I forgot it existed | 15:06 |
| mars | Is it something the reviewer should look for? Or is it something for the pre-imp? | 15:07 |
| gary_poster | My take: yes, we are still confused | 15:07 |
| sinzui | because it is neigh impossible to separate branch-bug-spec-question | 15:07 |
| danilos | i.e. we have developed a lot of translations-code and translations-soyuz bridges (well, there are some old ones), and like bigjools, I forgot it existed so never pushed for using it | 15:07 |
| gary_poster | Either robert d=should decide, or we should | 15:07 |
| gary_poster | and that's what bac is asking, I think | 15:07 |
| bac | gary_poster: yep | 15:07 |
| gary_poster | I'd be happy to tell robert, "yes, I confirmed, we're still confused. please help." | 15:07 |
| danilos | well, setting a policy is easy, but how do we migrate existing stuff? | 15:08 |
| gary_poster | ...happy for you to tell... | 15:08 |
| abentley | My original question was about whether the job system and the build farm should be in different places. | 15:08 |
| abentley | Right now, jobs is under lp.services and buildmaster is under lp | 15:08 |
| EdwinGrubbs | maybe, calling it crossappdeps would be clearer than coop. | 15:09 |
| danilos | EdwinGrubbs, isn't that what services is as well? | 15:09 |
| * EdwinGrubbs shrugs | 15:09 | |
| mars | bac, so, we are still confused, and we have no migration strategy | 15:09 |
| bac | danilos: i'd be happy combining the two | 15:10 |
| bac | mars: right. | 15:10 |
| mars | design by committee (us) isn't working | 15:10 |
| sinzui | Services is intended to hold utilities that have no lp deps, but other lp apps depend on them | 15:10 |
| mars | (IMHO) | 15:10 |
| bac | so i think i shall leave the item for lifeless and encourage him to think about it | 15:10 |
| gary_poster | +1 | 15:10 |
| danilos | yeah, I think everybody is happy to go with a decision whatever it is :) | 15:10 |
| bac | which i've really already done. | 15:10 |
| bac | danilos: yes, clarity now! | 15:10 |
| bac | ok, let's move on | 15:10 |
| bac | [topic] try/else/finally is considered harmful in doctests [curtis] | 15:11 |
| MootBot | New Topic: try/else/finally is considered harmful in doctests [curtis] | 15:11 |
| sinzui | http://pastebin.ubuntu.com/473086/ | 15:11 |
| MootBot | LINK received: http://pastebin.ubuntu.com/473086/ | 15:11 |
| sinzui | ^ take a moment to read this example | 15:11 |
| gary_poster | ContextManager use does not confuse the parser, I take it? | 15:12 |
| bac | sinzui: by that do you mean 'with'? i thought you said that was broken too. | 15:12 |
| sinzui | I think the issue in the parser is that it assumes '... ' is always an indented block | 15:12 |
| bigjools | that whole piece of code looks like a unit test to me | 15:13 |
| danilos | I must admit to not seeing that too often | 15:13 |
| bac | bigjools: yep | 15:13 |
| sinzui | yes, every example I have seen looks like a mis use of doctests | 15:13 |
| abentley | so ">>> finally:" doesn't work? | 15:13 |
| sinzui | the testrunner dies | 15:13 |
| danilos | there seems to be a total of 9 uses of "finally" in lib/lp/*/doc | 15:13 |
| mars | sinzui, so then it is safe to say "don't do it, because it smells funny"? | 15:13 |
| mars | as well as breaking the parser | 15:14 |
| sinzui | this may also be bad: ... else: | 15:14 |
| sinzui | mars, yes | 15:14 |
| bac | so when lint complains about it we should listen | 15:14 |
| sinzui | Something that constructs the tests from the doctest is correcting the parsed doctest parts. | 15:14 |
| danilos | sinzui, +1 on making it a lint failure (or well, keeping it a lint failure) | 15:14 |
| * bac notes the new pocket-lint is much less chatty. thanks sinzui. | 15:15 | |
| mars | danilos, +1, and now we all know a better way to fix it, too | 15:15 |
| abentley | sinzui, -1. If lib/lp/*/doc is supposed to be documentation, it shoujld demonstrate the best way to write code. | 15:15 |
| bac | sinzui: would you update the appropriate test style wiki with your findings? | 15:16 |
| abentley | sinzui, and omitting a finally block that you would normally put there doesn't seem like good documentation. | 15:16 |
| sinzui | We can place branching statements in functions and classes | 15:16 |
| gary_poster | I think abentley makes a good point. Moreover, I thing the argument being proposed here is "the parser doesn't understand blocks in doctests so don't use the," | 15:16 |
| gary_poster | them | 15:16 |
| gary_poster | that seems a bit weak on its own | 15:16 |
| gary_poster | if doctests are about documentation, not unit tests, then blocks may be appropriate in some cases | 15:16 |
| gary_poster | I've written them in doctests that I felt were pretty good documentation | 15:17 |
| bac | gary_poster: but is it testable documentation if the testing framework doesn't work? | 15:17 |
| gary_poster | bac, ? doctests understand this fine | 15:18 |
| gary_poster | the *lint* parser gets confused | 15:18 |
| sinzui | Do we advocate that users write code without classes and functions? I think not. If we want to show branching, we can easily show it in function | 15:18 |
| EdwinGrubbs | won't the parser be happy enough with the try/finally if you put it inside a function that is defined in the doctest? | 15:18 |
| sinzui | Keep in mind, that the example I have seen do not look like good documentation | 15:18 |
| bac | gary_poster: thanks for clearing that up | 15:18 |
| gary_poster | (np) | 15:19 |
| gary_poster | forcing docs to use a function for this purpose seems arbitrary | 15:19 |
| abentley | EdwinGrubbs, in cases where the function is needed anyway, that's reasonable. If it's not... | 15:19 |
| gary_poster | (or class) | 15:19 |
| abentley | EdwinGrubbs, ... then it's bad documentation to have a function you otherwise wouldn't need. | 15:19 |
| gary_poster | right | 15:20 |
| sinzui | gary_poster, jamesh wrote pyflakes-doctest because the test did play fine, but it was invalid. He discovered we had unreachable code in them, or code that was broken | 15:20 |
| bac | sinzui: so is the finally getting executed in doctests? is the doctest runner broken because it uses the same parser? | 15:21 |
| sinzui | The essence of this issue is that we are not presented with the unittest that is built from the doctest. We need to be careful and clear about what we write in them | 15:21 |
| sinzui | All the tools we are talking about use DocTestParser() | 15:22 |
| sinzui | I think the finally is, but I have not seen the unittest that was constructed | 15:22 |
| bac | I think we need to do more analysis to fully understand the problem. | 15:23 |
| sinzui | Since we are in am ambiguous situation, lets write code that in not ambiguous to the tools and ourselves | 15:23 |
| gary_poster | sinzui, pyflakes-doctest: ok. but I don't see how that's a point against the position that abentley and are taking. | 15:23 |
| gary_poster | unittest: we have already established quite clearly that doctests are not good for unit tests. | 15:23 |
| gary_poster | finally parsed: it is, as can be demonstrated very easily, and as has been part of the doctest library behavior since its release to my knoweldge | 15:23 |
| sinzui | gary_poster, I think my point is being missed | 15:24 |
| gary_poster | maybe so :-) | 15:24 |
| sinzui | I have not seen an example in our doctests, that our tools report an issue with that does not look like a bad test. | 15:25 |
| gary_poster | I would be +1 on this as something that had to be explained in a review | 15:25 |
| gary_poster | perhaps that's all that you are proposing | 15:26 |
| sinzui | Since changing our tools requires second guessing the reparsing of the parsed doctest objects, we then place our selves into a false sense of confidence that we are right | 15:26 |
| gary_poster | I would be -1 on making a blanket statement that using blocks in doctests is not OK | 15:26 |
| bigjools | I agree with gary_poster | 15:26 |
| gary_poster | and similar sub-blanket statements | 15:26 |
| bac | bigjools: you're +1 with gary's -1? | 15:26 |
| bigjools | bac something like that :) | 15:27 |
| gary_poster | :-) | 15:27 |
| sinzui | Well what do you want to do then. Do you propose a change to doctestparser or the two tools we have used? | 15:27 |
| bigjools | sinzui: I still don't understand the point you're trying to make :( | 15:27 |
| sinzui | That markup fails. and the doctestparser says it is bad | 15:28 |
| gary_poster | I don't know these tools, but I also generically object to tools' limitations driving style | 15:28 |
| bigjools | is it that we think the tests are not executing code in finally: or else: blocks? | 15:28 |
| sinzui | No | 15:28 |
| bigjools | so it's just the linter? | 15:28 |
| gary_poster | can we make "be quiet about this warning" linter statements in doctests the way we can in other contexts? | 15:29 |
| sinzui | This is about the fact that the example code is not being interpreted exactly as we write it! it is being reinterpreted. | 15:29 |
| flacoste | sinzui: what reinterprets it? | 15:29 |
| flacoste | the testrunner? | 15:29 |
| * gary_poster is confused again | 15:30 | |
| * bac too | 15:30 | |
| sinzui | I assume the class that build the source + want blocks into a unittest | 15:30 |
| flacoste | isn't that the doctest module itself? | 15:30 |
| gary_poster | yes | 15:30 |
| flacoste | so the same thing you think you are using in the linter? | 15:30 |
| flacoste | the testrunner uses doctest primitives | 15:30 |
| sinzui | yes | 15:30 |
| flacoste | like you do | 15:30 |
| flacoste | if it works in the testrunner but not in the linter there is a mystery to be solved | 15:31 |
| flacoste | not style statement to be changed | 15:31 |
| sinzui | two engineers wrote near identical code re using the doctest lib to parse the content to get the code that is compiled | 15:31 |
| gary_poster | +1 to what flacoste said (though, as I said, I'm happy to try the position that "blocks in a doctest are worth questioning in a review") | 15:32 |
| abentley | gary_poster, as am I. | 15:32 |
| flacoste | but again, if if it works in the testrunner | 15:32 |
| flacoste | ... | 15:32 |
| sinzui | Well | 15:32 |
| flacoste | unless you show that the testrunner is doing something funky | 15:32 |
| flacoste | so as not to complain | 15:32 |
| sinzui | I recall several asserts in doctests that were never played | 15:32 |
| flacoste | that was different | 15:33 |
| sinzui | The linter found that, not out test runner | 15:33 |
| flacoste | that's a known python limitation | 15:33 |
| flacoste | not a syntax error | 15:33 |
| flacoste | here you are talking about a case where the linter has a parse error | 15:33 |
| flacoste | and the testrunner doesn't | 15:33 |
| sinzui | yes | 15:33 |
| flacoste | in the assert case, both parsed it correctly | 15:33 |
| flacoste | they were valid statements that didn't do what the author intended | 15:34 |
| flacoste | that's very different | 15:34 |
| bac | but does the testrunner DTRT or not regarding try...finally? | 15:34 |
| gary_poster | it DTRT | 15:34 |
| bac | ok | 15:34 |
| flacoste | it's a separate question anyway | 15:34 |
| flacoste | the problem pointed here is that the lint tools choke on it, not that it's dubious | 15:34 |
| flacoste | an assert with a comma is dubious, but valid | 15:35 |
| flacoste | here, the try: finally: is a syntax error | 15:35 |
| flacoste | for one tool and not for the other | 15:35 |
| flacoste | or others | 15:36 |
| abentley | flacoste, I think there are a few things: 1, it's dubious: it should be '>>>'. 2. the linter is not following the dubious formatting. 3. the linter is valuable to us, so we should play nice with it. | 15:36 |
| abentley | sinzui, is that what you mean? | 15:36 |
| flacoste | abentley: you mean, ... finaly: should be written as >>> finaly: | 15:37 |
| flacoste | ? | 15:37 |
| flacoste | that baffles me | 15:37 |
| bigjools | me too | 15:37 |
| abentley | flacoste, well, lemme try in a python console here... | 15:37 |
| danilos | shouldn't we just fix the linter then? (provided it's not too much work) | 15:37 |
| gary_poster | (disagree on >>> point also) | 15:37 |
| flacoste | >>> try: | 15:37 |
| flacoste | ... print 1 | 15:37 |
| flacoste | ... finally: | 15:37 |
| flacoste | ... print 2 | 15:37 |
| flacoste | ... | 15:37 |
| flacoste | that works fine in the python interpreter | 15:37 |
| flacoste | console | 15:37 |
| abentley | flacoste, verified. | 15:38 |
| abentley | I withdraw my 1 2 3. | 15:38 |
| gary_poster | well, your 3 is the core issue still, from my perspective | 15:39 |
| gary_poster | "the linter is valuable to us, so we should play nice with it." | 15:39 |
| danilos | gary_poster, +1, so we should either fix the linter, or make code slightly uglier but keep the linter happy | 15:39 |
| jelmer | danilos: I agree, the best solution would be to just fix the linter if that's not too hard. | 15:39 |
| flacoste | first step in that direction is to understand what the linter and testrunner do differently | 15:40 |
| sinzui | The issue is broader than finally: | 15:40 |
| bac | flacoste: +1 | 15:40 |
| sinzui | it is branch statements | 15:40 |
| danilos | sinzui, then we should probably fix the linter | 15:40 |
| sinzui | I said wont fix because I do not want to second guess how the parsed objects are reparsed | 15:41 |
| danilos | I don't think we've got to come up with a coding solution here, as long as we agree that these: 1) warnings can be ignored until linter is fixed or 2) doctest code should accommodate the buggy linter | 15:41 |
| flacoste | sinzui: sure, but i'm pretty sure that the testrunner doesn't mess with the input either | 15:41 |
| sinzui | Using the same process that makes a playable doctest is a requirement | 15:41 |
| flacoste | sinzui: unless you have evidence to the contrary | 15:41 |
| gary_poster | +1 on danilo's resolution to the current topic | 15:42 |
| gary_poster | with the acknowledgement that sinzui shouldn't be forced to be the one to make the code changes | 15:42 |
| danilos | yeah :) | 15:42 |
| danilos | he won't be forced, he'll be just politely asked by everybody :) | 15:43 |
| gary_poster | heh | 15:43 |
| sinzui | https://bugs.edge.launchpad.net/pocket-lint/+bug/606897 | 15:44 |
| ubot5 | Launchpad bug 606897 in pocket-lint "doctest cannot compile finally (affected: 1, heat: 8)" [Undecided,Triaged] | 15:44 |
| mars | so can we say this issue is resolved? | 15:44 |
| sinzui | yes | 15:44 |
| bac | mars: i think so, for now, unless we get more information | 15:44 |
| bac | we'll have to address this on the ML or a future meeting, if required, as we're out of time. | 15:45 |
| bac | thanks sinzui | 15:46 |
| bac | thanks everyone. | 15:46 |
| jelmer | thanks bac | 15:46 |
| mars | thanks bac | 15:46 |
| gary_poster | thanks bac, sinzui | 15:46 |
| abentley | thanks bac | 15:46 |
| bac | #endmeeting | 15:46 |
| MootBot | Meeting finished at 09:46. | 15:46 |
| bigjools | tqa | 15:46 |
| danilos | thanks sinzui, bac :) | 15:46 |
| === Ursinha is now known as Ursinha-lunch | ||
| === salgado is now known as salgado-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === salgado-lunch is now known as salgado | ||
| === EdwinGrubbs is now known as Edwin-lunch | ||
| === Edwin-lunch is now known as EdwinGrubbs | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| bac | thumper, rockstar: you around? | 22:30 |
| thumper | bac: should also ping mwhudson and lifeless | 22:32 |
| thumper | rockstar is not around today | 22:32 |
| bac | thumper: sure. i thought mwhudson was no longer participating and lifeless would not be up. | 22:33 |
| bac | but i'd forgotten lifeless was in NZ | 22:33 |
| lifeless | hiya, sorry to be late | 22:40 |
| bac | lifeless: it's pretty hard to be late for this meeting. it sort of drifts around. | 22:40 |
| lifeless | :P | 22:41 |
| bac | lifeless: but glad you're here | 22:41 |
| bac | it's just you, thumper, and me | 22:41 |
| lifeless | ok cool | 22:41 |
| lifeless | its your show, so lead on :) | 22:41 |
| bac | we had a rousing 30 minute discussion this morning about the linter and test runner wrt to try/finally in doctests | 22:41 |
| bac | it turns out, the base assumptions were wrong. curtis sent out a mea culpa email and has gone to live underground. | 22:42 |
| bac | lifeless: we also talked a bit about the action item you inherited regarding lib/lp/services and lib/lp/coop | 22:43 |
| lifeless | ok | 22:43 |
| thumper | I want to propose that we rename lp.coop to lp.shared | 22:43 |
| lifeless | I saw your 'please do it' | 22:43 |
| bac | as i suspected we're still mightily confused and are looking for some guidance | 22:43 |
| thumper | or lp.crossapp | 22:43 |
| thumper | anything but "coop" | 22:44 |
| lifeless | thumper: AIUI coop is for XtoY code | 22:44 |
| bac | or merge the two... | 22:44 |
| lifeless | like bugstobranch | 22:44 |
| lifeless | or branchtoproduct | 22:44 |
| thumper | lifeless: yes | 22:44 |
| bac | answerstobugs is all there now | 22:44 |
| thumper | more between app | 22:44 |
| thumper | rather than app -> registry | 22:44 |
| lifeless | so between | 22:44 |
| lifeless | or inter | 22:44 |
| thumper | app -> registry is still considered app | 22:44 |
| bac | i actually found some definition in utilities/migrater/README | 22:44 |
| lifeless | I don't like shared, for the same reason as coop - its a true but useless definition | 22:44 |
| thumper | bac: but bug-branch and branch-spec are not | 22:44 |
| lifeless | lp.services is also shared | 22:45 |
| thumper | lp.interapp | 22:45 |
| thumper | gah | 22:45 |
| thumper | maybe I don't care as much | 22:45 |
| thumper | but I just really dislike coop | 22:45 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | I don't love it either | 22:45 |
| lifeless | so here's my take: everyone seems to know, its about XtoY | 22:46 |
| thumper | because I read it as "coup" rather than co-op | 22:46 |
| bac | in an amazing big of self-awareness, i think we agree we'll never come to satisfaction making the decision as a group but are willing to follow any well-thought fiat | 22:46 |
| bac | s/big/bit | 22:46 |
| lifeless | if its the definition that is missing, I'll edit the namespace package to say - well exactly what it says now. | 22:46 |
| lifeless | (pydoc lp.coop -> useful answer) | 22:46 |
| thumper | no Python documentation found for 'lp.coop' | 22:47 |
| lifeless | if its the name that sucks, I'll raise it on the list and we can paint it anycolour but coop | 22:47 |
| lifeless | thumper: oh yeah, another reason to hate buildout :) | 22:47 |
| thumper | I'm happy with the concept | 22:47 |
| thumper | unhappy with the name | 22:47 |
| wgrant | Doesn't it still only have answersbugs? | 22:47 |
| thumper | but lets continue... | 22:47 |
| thumper | wgrant: for now yes | 22:47 |
| bac | no, just pick a name. no list! use your authoritarian mandate | 22:47 |
| thumper | I've not moved the branch ones there as I hate the name | 22:48 |
| lifeless | bac: I gave that up on day one :) | 22:48 |
| thumper | bac: I'll discuss with lifeless and we'll pick a name | 22:48 |
| bac | suits me | 22:48 |
| lifeless | but sure, I'll lead organising a better name | 22:48 |
| lifeless | lp.cracks | 22:48 |
| lifeless | because its in between | 22:48 |
| thumper | lifeless: no... we'll choose one between us | 22:48 |
| thumper | lifeless: and bend the team to our will | 22:48 |
| lifeless | thumper: Well, we'll move it forward. | 22:49 |
| bac | lifeless: as to your other issue about imports per line, it did not come up as i didn't understand your position | 22:49 |
| lifeless | bac: so I replied in the list thread about 40 minutes ago | 22:49 |
| thumper | bac: one import per line | 22:49 |
| sinzui | We had someone who made a mandate, and we discovered that if enough engineers hate it, it will not happen | 22:49 |
| bac | lifeless: we did have quite a go at that one last time and it was not a popular idea | 22:49 |
| sinzui | only flacoste used coop/ | 22:49 |
| lifeless | bac: could you read my reply ? | 22:49 |
| lifeless | sinzui: exactly, mandate == fail | 22:49 |
| thumper | sinzui: but I'll move my code if I can tollerate the name | 22:50 |
| bac | lifeless: yes, i'd already read your reply | 22:50 |
| lifeless | the way I think of it, leaders only have one mandate card at a time; if they play a new one, the old one gets lost :) | 22:50 |
| lifeless | bac: ok. Still confused ? | 22:50 |
| bac | lifeless: no. i'm not confused now but was 8 hours ago, hence it didn't make the meeting | 22:51 |
| lifeless | righto | 22:51 |
| lifeless | bac: so I'm up to speed now :) | 22:51 |
| lifeless | I think changing this will have several good effects. | 22:51 |
| lifeless | firstly it will make reviews easier. | 22:51 |
| thumper | less merge conflicts | 22:51 |
| lifeless | secondly it will mead we can delete most of the section about import scopes, because that is dealing with fallout from the current policy - such as the current policy causing merge conflicts. | 22:52 |
| bac | personally i don't think changes to imports affect reviews as the linter will tell you whether you have extras and it won't compile if you leave something out | 22:52 |
| thumper | bac: but we do get (unnecessary) conflicts | 22:53 |
| lifeless | bac: you've never had your eyes glaze over as you try to assess what was changed ? | 22:53 |
| bac | thumper: really? are you seeing lots of merge conflicts on imports? | 22:53 |
| thumper | bac: reasonably regularly, yes | 22:53 |
| bac | i must be living right, then, as i don't see it often | 22:53 |
| wgrant | FWIW, I hit it fairly frequently. | 22:54 |
| bac | lifeless: you don't have to convince me, though, but the rest of the reviewers. | 22:55 |
| lifeless | bac: well, you've got three enthusiastic votes here. | 22:55 |
| lifeless | and noone shouted it down on the list. | 22:55 |
| * sinzui is still seeing lots of conflicts his apocalypse branches because imports are still using c.l globs | 22:55 | |
| lifeless | so I think we should just do it | 22:55 |
| lifeless | four enthusiastic votes here. | 22:56 |
| wgrant | sinzui: I've pondered making the linter complain about c.l.i imports. | 22:56 |
| bac | lifeless: and i will say we have lost one of the biggest proponents of the status quo to another team so it might be easier | 22:56 |
| sinzui | jml and I agree it should, maybe scream at every change to the module | 22:56 |
| bac | lifeless: seriously? i'll bring it up and take a vote next week. | 22:57 |
| bac | lifeless: you may want to stay up late and come argue your case... | 22:57 |
| lifeless | bac: what time, UTC, is it ? | 22:57 |
| bac | 1400 | 22:57 |
| lifeless | 2am | 22:58 |
| bac | ugh | 22:58 |
| lifeless | I think I'll pass. | 22:58 |
| lifeless | But I'll keep gnawing at this on the list until the pros and cons are clearly established :) | 22:58 |
| bac | right | 22:58 |
| bac | any other topics to discuss? | 22:59 |
| thumper | I might mention something | 22:59 |
| lifeless | Separately, there is a meta-thing here, which is that I think the review team <-> style guidelines interaction may need a tuneup | 22:59 |
| thumper | I sent an email to the list about lp.<app>.errors and lp.<app>.enums | 22:59 |
| lifeless | the review team is now ~= all developers | 22:59 |
| lifeless | sorry thumper, go ahead | 22:59 |
| thumper | we should raise it on the reviewer meeting too | 22:59 |
| thumper | by moving enums and errors out of interface files we reduce circular dependencies | 23:00 |
| sinzui | thumper, emums and errors is just going to happen | 23:00 |
| thumper | enums and errors have fairly static and defined dependencies | 23:00 |
| thumper | emum? | 23:00 |
| sinzui | the people who really want to kill the issue will make it happen | 23:00 |
| thumper | sinzui: I've been moving more out | 23:00 |
| thumper | I almost created the registry ones | 23:00 |
| thumper | moving NotFound though was quite taxing | 23:01 |
| sinzui | I bet you broken shipit | 23:01 |
| bac | thumper: i like your idea and will bring it up next week | 23:01 |
| thumper | sinzui: yep | 23:01 |
| bac | [action] bac to bring up thumper's point about errors and enums | 23:01 |
| sinzui | All the webapp globs in c.l have to stay until we can kill it | 23:01 |
| thumper | sinzui: so there is an import that keeps it where shipit cares about | 23:02 |
| sinzui | I have that in one of my apoc branches | 23:02 |
| wgrant | sinzui: It seems like it's pretty killable, except that it needs access to Person.karma. | 23:02 |
| wgrant | sinzui: Everything else can be done through SSO. | 23:02 |
| thumper | sinzui: how many epoc branches do you have unlanded? | 23:02 |
| sinzui | shipit has insider knowledge of lp, and it's knowledge is wrong. I do not think most lp engineers are aware of the webapp shims | 23:03 |
| sinzui | thumper, 1. I estimate I need to do 5 from my master branch | 23:04 |
| bac | lifeless: you had another issue? | 23:05 |
| lifeless | yes, was letting sinzui and thumper duke it out ;) | 23:05 |
| lifeless | My issue - Separately, there is a meta-thing here, which is that I think the review team <-> style guidelines interaction may need a tuneup | 23:05 |
| lifeless | the review team is now approximately all developers | 23:05 |
| sinzui | I cannot complete branch 6 until enum, errors are address, and we soyuz and registry need to stop fighting over distroseries | 23:05 |
| lifeless | so I think that the original responsibility - tuning process & deciding on the coding guidelines, are perhaps no longer a good fit for these meetings | 23:06 |
| bac | lifeless: yes. the AMEU meeting sometimes reflects that as it is the only time during the week we're basically all around for a chat | 23:06 |
| lifeless | instead, the meeting should be about tuning process | 23:06 |
| lifeless | and we should just use the mailing list to build consensus on the guidelines and act directly from that | 23:07 |
| lifeless | this would do two things: | 23:07 |
| lifeless | - make the review meetings more focused on the /review/ component | 23:07 |
| lifeless | - allow faster iteration when good ideas come up, because it would no longer be bypassing-the-system to change guidelines based on list consensus | 23:07 |
| lifeless | I haven't thought really deeply about this yet - its a sketch, a possibility; I'm interested in what you think about this idea. | 23:08 |
| bac | i'm not convinced that getting a consensus on the list is faster. often in a meeting we can quickly come to a conclusion. the times we don't we send it off to the list. | 23:09 |
| lifeless | perhaps I should say then, that 'consensus should be the test, decoupled from any specific meeting' | 23:10 |
| lifeless | if a meeting helps achieve consensus, great, but its a tool towards consensus, not the approval-step | 23:10 |
| lifeless | anyhow, as I say, this is a fairly fresh thought, not time-hammered and analysed yet ;) | 23:10 |
| bac | lifeless: i'm open to any ideas to improve the meetings and make them more productive | 23:11 |
| lifeless | it struck me as very formal to need to bring the import change through the review team process, rather than just saying 'any objections... wait... done' | 23:11 |
| lifeless | and so I was pondering what the formality buys us. | 23:12 |
| bac | actually, that is a bad example, i think b/c until your last email it was not clear to me what was being proposed | 23:13 |
| lifeless | Years ago, it bought us consensus amongst senior developers and no requirement for team wide consensus. The team is a very different place today. | 23:13 |
| bac | ten messages over the course of two days before the actual proposal was fleshed out | 23:13 |
| lifeless | bac: Its a good example - it shows the thing needing discussion to make it clear to everone, but no synchronisation point needed | 23:14 |
| lifeless | neverhteless, I'm not proposing a change here; its in the minutes and folk can think about this. | 23:14 |
| bac | right, but were we able to all be in a meeting at once it would been clear within about 90 seconds | 23:14 |
| === salgado is now known as salgado-afk | ||
| bac | lifeless: it's definitely worth considering. thanks for bringing it up. | 23:15 |
| lifeless | we feel -very- process heavy compared to the bzr team, and I'm just questioning in a state of childlike naivety the tradeoffs all over the place | 23:15 |
| lifeless | so - I'm 'fin' on that point | 23:17 |
| bac | anything else? | 23:17 |
| lifeless | back to the chair | 23:17 |
| thumper | nope | 23:17 |
| bac | ok, thanks for showing up and having a good discussion. see you next week. | 23:17 |
| lifeless | roger wilco | 23:18 |
| lifeless | ciao ;) | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!