[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[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:01] <sinzui> me☢
[15:01] <bigjools> how do you keep a bunch of wankers in suspense
[15:01]  * mars pokes the meeting chair
[15:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15]  * 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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <sinzui> gary_poster, I think my point is being missed
[15:24] <gary_poster> maybe so :-)
[15:25] <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:26] <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:27] <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:28] <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:29] <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:30]  * 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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <abentley> flacoste, verified.
[15:38] <abentley> I withdraw my 1 2 3.
[15:39] <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:40] <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:41] <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:42] <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:43] <danilos> he won't be forced, he'll be just politely asked by everybody :)
[15:43] <gary_poster> heh
[15:44] <sinzui> https://bugs.edge.launchpad.net/pocket-lint/+bug/606897
[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:45] <bac> we'll have to address this on the ML or a future meeting, if required, as we're out of time.
[15:46] <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 :)
[22:30] <bac> thumper, rockstar: you around?
[22:32] <thumper> bac: should also ping mwhudson and lifeless
[22:32] <thumper> rockstar is not around today
[22:33] <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:40] <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:41] <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:42] <bac> it turns out, the base assumptions were wrong.  curtis sent out a mea culpa email and has gone to live underground.
[22:43] <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:44] <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:45] <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] <lifeless> I don't love it either
[22:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <wgrant> FWIW, I hit it fairly frequently.
[22:55] <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:56] <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:57] <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:58] <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:59] <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
[23:00] <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:01] <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:02] <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:03] <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:04] <sinzui> thumper, 1. I estimate I need to do 5 from my master branch
[23:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <lifeless> and so I was pondering what the formality buys us.
[23:13] <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:14] <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:15] <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:17] <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:18] <lifeless> roger wilco
[23:18] <lifeless> ciao ;)


[07:31] <lordievader> Good morning
[08:38] <zioproto> hello ubuntu folks
[08:38] <zioproto> my monitoring system is not happy because of these errors in kern.log https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1705447
[08:39] <zioproto> this happens on Bare Metal
[08:39] <zioproto> I guess I can safely ignore them ... is anyone else hitting this stuff ?
[09:57] <jamespage> coreycb: https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1677207 seem familiar to you? I'm not sure our flush cache/upgrade bits are working in the horizon pacakges.
[10:04] <zioproto> good... some Ocata bugs are popping up before I start my upgrade :)
[11:49] <coreycb> jamespage: ah, is it memcache do you think?
[12:17] <hehehe> hey hey
[12:17] <hehehe> if I am making new sftp user - chrooting it to images directory and using strong password is all that I need?
[12:17] <hehehe> :)
[12:18] <hehehe> just a user who can upload images via www :D
[12:18] <jamespage> coreycb: I don't think so
[12:19] <hehehe> Match Group sftp_users - whats that for ?X11Forwarding no   AllowTcpForwarding no ChrootDirectory /images
[12:29] <hehehe> ok I see whats up
[12:29] <hehehe> :)
[12:29] <hehehe> its to catch users to whom following commands apply
[12:29] <hehehe> however in my cases, dirs are owned by root:www-data lol
[12:30] <hehehe> can I use Match user somehow instead of a group?
[12:30] <hehehe> so I add 1 more user to www-data group :)
[13:18] <hehehe> mm anyhow now I see that entire path have to be root:root
[13:18] <hehehe> but my php app required group write read access
[13:18] <hehehe> via group
[13:50] <rbasak> nacc: "debian/changelog must exist in source packages"
[13:50] <rbasak> Looks like that's only just become a requirement.
[13:50] <rbasak> Interesting for us.
[15:12] <nacc> rbasak: where is that?
[15:26] <rbasak> nacc: lastest Debian policy change.
[15:26] <rbasak> Sent to devel-debian-announce
[15:27] <nacc> rbasak: ah
[15:28] <nacc> rbasak: I mean, beyodn perhaps adding it to the linter, what do you expect to chagne?
[15:46] <rbasak> nacc: I mean that we're assuming that it exists when importing historical packages.
[15:46] <rbasak> But I suppose if it did in practice, then we're OK. Hence interesting rather than a problem.
[15:47] <nacc> rbasak: ah ok
[15:47] <nacc> rbasak: yeah, I think we just would't see any versiosn
[15:47] <nacc> rbasak: which would mean orphans
[15:47] <nacc> perhaps we'd fail to tag too
[15:47] <nacc> not sure
[15:48] <nacc> rbasak: is your schedule pretty full today, or do you think you'll be able to get to ay of the reviews?
[15:59] <rbasak> nacc: seems unlikely, sorry. Do you have any small ones you can point out that I can try to tackle when I find a few minutes here and there?
[16:00] <nacc> rbasak: no it's fine, just gauging my own expectations
[16:02] <lol768> https://help.ubuntu.com/community/UFW states that "By default, UFW allows ping requests"
[16:03] <lol768> the minute I do an "ufw enable", I can no longer ping6 the server, or ping6 out from it
[16:22] <nacc> rbasak: the only one that definitively you need to review is the queue change
[17:43] <nacc> rbasak: was cjwatson's suggestion that we add a Git-Ubuntu: field to the DSC?
[17:43] <nacc> rbasak: i see dgit adds a Dgit
[18:12] <drab> hello .o/
[18:12] <sarnold> hey drab :)
[18:13] <drab> I'm considering doing something "different" for our centralized home dirs and hoped to hear some opinions
[18:13] <drab> basically right now we have a standard ldap + nfs shares, users auth against ldap and pam_mount mounts their homedir
[18:14] <drab> however as I've been moving stuff to containers nfs is a pita becuase the userspace version is awfully slow and the kernel version won't run in a container
[18:14] <drab> there's also the problem that a network blip and/or issue with the nfs server freezes up the clients very badly
[18:15] <drab> I've read that may be fixed using soft rather than hard mounts with nfs tho
[18:15] <drab> in any case, as I was trying to help some folks with a samba share, I came across some links wondering if I could use samba for homedirs...
[18:16] <drab> it turns out there's some largish university campuses doing homedirs on samba as it can be interoperated with windows too, but generally I've not seen a lot of setups like that and wondered how crazy of an idea it is
[18:16] <nacc> i mean, i'd expect to see some similar caveats a la network blips
[18:16] <nacc> i'm not sure how resilient samba is to long outages
[18:17] <sarnold> soft mounts definitely help nfs clients
[18:17] <drab> I've no experience with samba so wondering if: a) is it performing alright compared to nfs? (will test of course) 2) is it crazy to put homedirs on it coupled with ldap?
[18:17] <nacc> and/or how it reconciles remote changes onn the server
[18:17] <nacc> drab: +1 on soft, though
[18:18] <drab> tbh the most appealing part of this is avoiding to run kvm so that I can run nfs-kernel-server
[18:18] <drab> right now I'm 99% lxc with the exception of the nfs server, requiring kvm
[18:18] <drab> and that means handing off the infra to people requires them to know how to deal with that too which isn't terribly hard but does add some complications
[18:19] <drab> so if I could be 100% lxc using samba for homedirs that would be, in the larger picture, quite a win
[18:19] <drab> but I don't want of course to ruin it for all the users by making their experience terrible
[18:19] <nacc> drab: in theory, could your VM be a privileged container?
[18:20] <drab> nacc: the thing is, that doesn't really solve the isolation issue... I've had nfs locking up on the server and taking down the whole thing
[18:20] <nacc> drab: ah sure
[18:20] <nacc> drab: yep, i can see that happening :)
[18:20] <drab> so even if I could do a privileged containres, which I guess would solve having kvm
[18:20] <nacc> yeah, if you need isolation, then that's a different issue
[18:20] <drab> I don't quite feel comfortable given everything else going on on that box
[18:20] <nacc> yep
[18:20] <drab> yeah, but you're right, that would solve my kvm issue
[18:20] <sarnold> drab: are you sure the samba mounts _would_ be allowed?
[18:20] <nacc> drab: nfs lockinng up in the kernel?
[18:21] <drab> nacc: yes, basically locking up the machines, doing something bad to the drives, whatever
[18:21] <drab> ending up impacting all the other containers/services on that box
[18:21] <drab> sarnold: based on what I read, it looks like it. this is the best link so far:
[18:21] <drab> https://sites.duke.edu/linux/cifs-nfs-homes/
[18:21] <drab> so it seems the workflow is the same
[18:22] <drab> except it uses pam_cifs
[18:22] <drab> altho right now I'm using autofs to mount the homes, not even pam_mount
[18:22] <drab> but that should also work with samba no prob
[18:22] <drab> except that samba requires user/pwd so maybe pam is required in this workflow
[18:22] <drab> the added benefit to using samba over nfs is auth
[18:22] <sarnold> drab: btw i've had success unsticking nfs mounts by bringing up the IP address of the server on an interface, exporting an identically-named filesystem, and umounting
[18:23] <drab> good to know, thanks for sharing
[18:27] <drab> I guess I'll take it as a good sign that neither of you called me crazy and begin experimenting :)
[18:28] <drab> that will give me a better sense, the general principle seems fairly simple/standard, I just have no clue how well samba is going to handle disconnections or multiple logins (sometimes ppl forget to log out and their home stays mounted)
[18:28] <nacc> ahasenack: --^ has also been doing quite a bit to get samba up to snuff relative to bug reports
[18:28] <nacc> he may have further insights
[18:29] <drab> that's another pretty annoying this I found no good solution to... log people out after inactivity
[18:29] <drab> ok, cool, thanks
[18:29] <drab> always good to be here, you guys are great :)
[18:30] <sarnold> drab: check out systemd-logind for the idle thing.
[18:31] <drab> k, thanks
[18:31] <drab> brb
[18:31] <sarnold> my own experience with samba is decades ago at this point but I recall being massively annoyed at how many bloody authentication types there are. public, share-level security, user auth, etc etc
[18:32] <sarnold> but if you get to run the server and clients and control them yourself you can probably get something happy
[20:49] <coreycb> beisner: hi, can you please promote horizon 3:11.0.3-0ubuntu3~cloud0 to ocata-proposed? it's a high-priority fix for upgrade from newton->ocata.
[20:50] <beisner> hi coreycb - on that ^
[20:51] <coreycb> beisner: cheers, thanks
[22:12] <drab> sarnold: nacc: fwiw found this which seems possibly problematic: https://github.com/lxc/lxd/issues/3442
[22:12] <drab> but stgraber says he has it working so maybe I'm misunderstanding the issue
[22:12] <nacc> drab: do you use zentyal?
[22:12] <drab> I only need to serve files, not even the DC part, altho it'd be nice to do that later
[22:13] <drab> I don't , but it didn't seem zentyal specific, maybe I misread
[22:13] <drab> the problems seemed to be related how samba stores the acls in the security.* namespace
[22:14] <nacc> drab: zentyal sets the --use-xattrs bits
[22:14] <nacc> drab: but not really sure either
[22:14] <nacc> i'd try it and see :)
[22:14] <drab> heh, I'm setting stuff up nowish, had to deal with some broken hardware and building sorting box frames
[22:15] <drab> the "fun" part of being a charity is that we hold on whatever junk we can get our hands on for the rainy days
[22:15] <drab> it's like a flashback 20yrs in my father's garage...
[22:16] <drab> I don't think he ever threw away a single screw, everything had to come off before the boards ended up in the bin
[22:16] <nacc> that's how my dad was too
[22:16] <nacc> i had one of his boxes of screws until it got rained
[22:16] <nacc> somehow he kept it totally organized by type, size, thread, etc. too
[22:16]  * drab nods
[22:17] <drab> I think the first tool I was every introduced to was a labelling machine :P
[22:17] <nacc> heh
[22:18] <drab> now that it's up to me I just write with sharpies on masking tape lol :P
[22:18] <nacc> yeah, that's what we do in our pantry, e.g. :)
[22:18] <stgraber> drab: the xattrs stuff is configurable IIRC and my DC is deployed manually through samba-tool, so I'm simply not passing that particular option
[22:18] <drab> stgraber: sounds good, thanks for chiming in
[22:19] <drab> stgraber: any chance you have an opinion on the craziness of replacing nfs+ldap with samba+ldap for centralized homedirs for a bunch of linux desktops?
[22:20] <stgraber> I haven't done either in a while. I used to do that kind of stuff for school districts in a previous life and I seem to remember both being annoying but in different ways :)
[22:20] <nacc> heh
[22:21] <drab> yep, that's exactly where I am... edu charity/school and being annoyed :P
[22:21] <stgraber> IIRC we'd usually do nfs on trusted networks where no sharing was needed with Windows and cifs for the rest
[22:21] <drab> I guess testing will tell... getting to it
[22:21] <drab> yeah, I'd normally do that if it wasn't that I'm trying to get everything into containers
[22:22] <drab> and nfs-kernel-server won't play nice with it and still be a nuisance to the host if I go with a privileged container
[22:22] <drab> samba would solve that problem, which is quite a plus in this setup
[22:22] <stgraber> yeah, and the old nfs-user-server wasn't exactly fun to use :)
[22:22] <drab> yap
[23:02] <Village> Hello,
[23:03] <Village> what's best SMTP server is on ubuntu 16.04?
[23:03] <Village> Where you can chnge ports?
[23:06] <nacc> Village: 'best' is a really ... vague ... term to use. I would think every SMTP server worth using is configurable as to what port it listens onn.
[23:07] <nacc> Village: which have you looked at?
[23:08] <Village> I want that Internet Site can send emails via SMTP and email addresses sender by not same..
[23:08] <Village> now i looking
[23:08] <Village> postfix
[23:14] <drab> postfix is good
[23:15] <drab> postfix and exim are 2 of the common ones and largely a matter of taste which one you pick
[23:15] <drab> personally exim would drive me bonkers each time I tried to configure it and always stuck with postfix, but really it's just a personal preference thing
[23:15] <drab> Village: ^^
[23:22] <Village> Ok, i have at mind that two of best is postfix and exim
[23:23] <Village> but i wanna know google smtp not allow send<EMAIL_ADDRESS>?
[23:27] <drab> why do you think it does not?
[23:29] <Village> i don't know need try
[23:47] <oerheks> make sure you leave a copy on your gov.us server :-D