| *** chandan_kumar has joined #openstack-sprint | 02:44 | |
| *** chandan_kumar has quit IRC | 04:39 | |
| *** chandankumar has joined #openstack-sprint | 04:59 | |
| *** AJaeger has joined #openstack-sprint | 09:05 | |
| *** chandankumar has quit IRC | 10:25 | |
| *** chandankumar has joined #openstack-sprint | 10:39 | |
| *** chandankumar has quit IRC | 11:42 | |
| *** chandankumar has joined #openstack-sprint | 11:43 | |
| *** chandankumar has quit IRC | 13:06 | |
| *** AJaeger has quit IRC | 14:25 | |
| *** AJaeger has joined #openstack-sprint | 14:38 | |
| *** AJaeger has quit IRC | 14:38 | |
| *** AJaeger has joined #openstack-sprint | 14:38 | |
| pleia2 | anteaya: sprint time? | 15:19 |
|---|---|---|
| AJaeger | good morning, pleia2 | 15:20 |
| pleia2 | good morning AJaeger :) | 15:20 |
| anteaya | it is | 15:21 |
| anteaya | so it is | 15:21 |
| anteaya | we are sprinting | 15:21 |
| *** jeblair has joined #openstack-sprint | 15:21 | |
| pleia2 | \o/ | 15:21 |
| anteaya | welcome everyone | 15:21 |
| anteaya | and thanks to those for getting up early or staying up late | 15:21 |
| anteaya | let's check our notes: https://etherpad.openstack.org/p/infra-manual-sprint-December-2014 | 15:22 |
| anteaya | so any questions on the etherpad before we get rolling? | 15:23 |
| anteaya | if so, ask as we go along | 15:24 |
| AJaeger | just as noted on the etherpad: Enhancements for RST markup to the wiki page is welcome! IF there's none, just add - and if there's disagreement with what I added already, please change | 15:24 |
| anteaya | awesome, thank you | 15:24 |
| * AJaeger cleaned up the bold/emphasis patches on Friday. | 15:24 | |
| anteaya | thank you | 15:24 |
| anteaya | pleia2: actually by way of getting started, do you mind running some stats? | 15:24 |
| pleia2 | stats of? | 15:24 |
| anteaya | how many patches up, open, abandoned | 15:25 |
| AJaeger | could one of the cores please abandon https://review.openstack.org/107360 now? | 15:25 |
| anteaya | so we can track our progress for the sprint in terms of patches created, merged etc | 15:25 |
| AJaeger | I've moved the real content to https://review.openstack.org/137819 | 15:25 |
| anteaya | AJaeger: can you put that in the etherpad as a request for cores? | 15:25 |
| anteaya | in case it gets lost in scrollback? | 15:25 |
| AJaeger | will do, anteaya | 15:25 |
| anteaya | thank you | 15:25 |
| pleia2 | anteaya: I'll grab number opened now, and see what I can do stats-wise about open/merged/abandoned this evening | 15:26 |
| anteaya | pleia2: awesome thank you | 15:27 |
| pleia2 | or tomorrow evening | 15:27 |
| anteaya | so we have some numbers to announce when we are done | 15:27 |
| pleia2 | this is a 2 day thing :) | 15:27 |
| anteaya | sure, either way | 15:27 |
| anteaya | it is | 15:27 |
| AJaeger | I'd like to have a review on https://review.openstack.org/137819 - please tell me what to do with the -1 there. If there's agreement to just link to the gerrit page, I can rework it. | 15:28 |
| anteaya | sure | 15:29 |
| pleia2 | yeah, link to gerrit docs wfm | 15:29 |
| AJaeger | jeblair, I would love to have current patches approved so that we know what really needs working on and have less merge conflicts | 15:29 |
| jeblair | AJaeger: yep. i'm just waking up, hope to soon. | 15:30 |
| *** nibalizer has joined #openstack-sprint | 15:30 | |
| AJaeger | jeblair, thanks! Drink your coffee first ;) | 15:30 |
| anteaya | AJaeger: I like your approach, for beginners sending them all over the place confuses them | 15:31 |
| anteaya | they don't know what they should be looking at when they arrive at the new link | 15:31 |
| anteaya | best to describe as you do | 15:31 |
| anteaya | and then add the link for reference at the bottom of your description | 15:31 |
| AJaeger | (not my text, copied from 107360) | 15:31 |
| AJaeger | Ok, let me do that - pleia2 ok? | 15:32 |
| jeblair | anteaya: ++ | 15:32 |
| anteaya | AJaeger: and if you did a straight copy can you link the copied patch, for reference in the commit message? | 15:32 |
| AJaeger | anteaya, will update | 15:32 |
| pleia2 | sure | 15:33 |
| anteaya | thanks, you gave co-author credit, lets explictly see why | 15:33 |
| anteaya | and thank you | 15:33 |
| AJaeger | updated 137819 | 15:35 |
| anteaya | I'm waiting for the docs to come back, but the rst looks good | 15:36 |
| AJaeger | anteaya, docs are back | 15:38 |
| pleia2 | it's back, looks good | 15:38 |
| anteaya | AJaeger: this sentence is a bit long: After you add one or more inline comments, you still have to send the Review message (see above, with or without text and vote), prior to sending the inline comments in a review comment the inline comments are stored as Drafts in your browser. | 15:39 |
| anteaya | can we split it at all? | 15:39 |
| AJaeger | let me try reworking... | 15:40 |
| anteaya | thanks | 15:40 |
| pleia2 | it's something that confuses people often, so I didn't feel it was run-on, but I am the queen of run-on sentences, so ;) | 15:40 |
| AJaeger | Was easy to split ;) | 15:40 |
| anteaya | I'm looking at the gerrit link, the content is for reviewing a change, not just adding an inline comment | 15:40 |
| anteaya | AJaeger: yay | 15:41 |
| anteaya | perhaps we should add the gerrit link as a reference for that entire Reviewing a Patch section, not just adding an inline comment | 15:41 |
| anteaya | thoughts? | 15:41 |
| anteaya | sorry that entire Code Review section | 15:42 |
| dhellmann | anteaya, pleia2 : as promised: https://review.openstack.org/138094 (I tried to remove most of the oslo-specific stuff, but there are a few places where knowing oslo vs. not oslo is important for the process so I tried to make those more generic) | 15:42 |
| AJaeger | anteaya, will do. | 15:42 |
| pleia2 | dhellmann: wow, excellent! | 15:42 |
| anteaya | dhellmann: morning | 15:42 |
| anteaya | dhellmann: are you around for much of the sprint? | 15:43 |
| AJaeger | anteaya, check again ;) | 15:43 |
| anteaya | or just ducking in and out? | 15:43 |
| dhellmann | pleia2: I think I found a few things that were out of date, too, so please read closely :-) | 15:43 |
| anteaya | AJaeger: thanks | 15:43 |
| pleia2 | dhellmann: will do | 15:43 |
| anteaya | dhellmann: the reason I ask | 15:44 |
| dhellmann | anteaya: I'll be in and out. I have the Oslo meeting in 15 minutes but then I'll be more responsive. I'd like to land some version of this guide if possible so I can update our wiki page to refer to it, so I'm motivated to respond to review comments. I'll try to help with some reviews, too, of course. | 15:44 |
| anteaya | dhellmann: great thanks | 15:44 |
| AJaeger | dhellmann, thanks! | 15:44 |
| anteaya | dhellmann: I will leave some stuff in channel and the channel is logged so reply as you are able | 15:44 |
| dhellmann | anteaya: sounds good | 15:44 |
| anteaya | at summit we had a chat about how to organize content | 15:45 |
| anteaya | since some content doesn't fit in just one place in our intended format | 15:45 |
| anteaya | of having guides for specific audiences | 15:45 |
| dhellmann | anteaya: I saw some comments about that, so if this can be split into snippets that should work out | 15:45 |
| anteaya | beginning developers, core-reviewers (or those wanting to), ptls | 15:45 |
| anteaya | dhellmann: great that is what I am getting to | 15:46 |
| anteaya | the snippets syntax | 15:46 |
| anteaya | mordred found it and we have it on the etherpad | 15:46 |
| anteaya | and so far the rest of us don't have experience with it or how to use it | 15:46 |
| anteaya | I see your patch introduces a new file | 15:46 |
| dhellmann | anteaya: ok, I have lots of sphinx experience so maybe I can help there | 15:46 |
| *** fungi has joined #openstack-sprint | 15:46 | |
| anteaya | which would be outside our format of guides | 15:46 |
| anteaya | awesome | 15:46 |
| anteaya | so I can review for content | 15:47 |
| anteaya | then we would have to have a chew about how to use snippets so the content can be accessed via one or more of the guides | 15:47 |
| anteaya | if that makes sense | 15:47 |
| pleia2 | I'm still a bit tired, need some fresh air, going to go for a quick jog + pick up some coffee | 15:47 |
| anteaya | pleia2: enjoy, thanks for getting use rolling | 15:47 |
| anteaya | pleia2: see you when you get back | 15:47 |
| anteaya | s/use/us | 15:48 |
| dhellmann | anteaya: the only gotcha I can think of with mordred's idea is you will need to make sure sphinx knows it is ok for the snippet files to not be in the toctree. There are a couple of ways to handle that. Simplest is probably to create a doc/snippets and put them all there instead of under doc/source | 15:48 |
| *** hashar has joined #openstack-sprint | 15:48 | |
| anteaya | I'm for the simpliest approach | 15:48 |
| anteaya | especially since we don't have legacy to consider | 15:48 |
| anteaya | so you have your meeting, I'll have some breakfast, I'll review for content and we can talk more about structure | 15:49 |
| anteaya | and thanks | 15:49 |
| dhellmann | anteaya: sounds good | 15:49 |
| jeblair | re snippets: we should consider when to use snippers vs simply linking to elsewhere in our own doc. there's a value to teaching people where to find things in the manual by linking to them (and thereby also introducing them to other content they may otherwise miss), whereas repetition may cause confusion | 15:54 |
| jeblair | i'm not saying one way or the other is always right; i just want us to keep that in mind when making the choice | 15:54 |
| anteaya | good point | 15:54 |
| anteaya | makes sense | 15:54 |
| anteaya | since dhellmann's patch introduces a new file, which is not one of our guides files, i thought talking about snippets was warrented | 15:55 |
| anteaya | so once we have a look at the content we can decide where it should live and when to snip and when to link | 15:56 |
| anteaya | sound fair? | 15:56 |
| jeblair | yep | 15:56 |
| anteaya | thanks | 15:56 |
| fungi | as soon as i finish catching up with things this morning, i'm happy to start reviewing or writing infra-manual changes, whichever is more urgently needed | 16:01 |
| anteaya | fungi: thank you! reviewing to start | 16:03 |
| fungi | can do | 16:03 |
| jeblair | approved 126506 (Remove call of 'python setup.py testr' in tox.ini) | 16:03 |
| anteaya | fungi: we have an etherpad: https://etherpad.openstack.org/p/infra-manual-sprint-December-2014 | 16:04 |
| *** clarkb has joined #openstack-sprint | 16:09 | |
| clarkb | ohai | 16:10 |
| jeblair | this is really cool: https://review.openstack.org/#/c/132844/1/doc/source/code_review.png | 16:10 |
| jeblair | (new gerrit showing image diff) | 16:10 |
| jeblair | and approved | 16:10 |
| clarkb | so for someone just waking up after the long weekend, where should I start? review infra-manual changes? | 16:11 |
| AJaeger | jeblair, yeah, really helpfull and much apprectiated for doc reviews | 16:12 |
| jeblair | clarkb: yes. also see etherpad here: https://etherpad.openstack.org/p/infra-manual-sprint-December-2014 | 16:12 |
| clarkb | should that etherpad be in the topic? | 16:12 |
| jeblair | clarkb, fungi: here's one ready for a +3: 104921 | 16:12 |
| jeblair | clarkb: probably should be; i think for future virtual sprints, we should work out how to make it easy for people to change the topic and put gerritbot in here | 16:13 |
| clarkb | ++ | 16:13 |
| jeblair | in the mean time, i will ask an openstack irc op to do it. ;) | 16:14 |
| *** ChanServ sets mode: +o jeblair | 16:14 | |
| * AJaeger is driving home now, will rejoin in two hours.... | 16:14 | |
| *** jeblair changes topic to "OpenStack infra-manual sprint | Etherpad: https://etherpad.openstack.org/p/infra-manual-sprint-December-2014 | Channel logs at: http://eavesdrop.openstack.org/irclogs/%23openstack-sprint/" | 16:15 | |
| anteaya | thank you | 16:18 |
| anteaya | clarkb: yes, if you could review any patches that can be merged, that would be a great place to begin | 16:19 |
| anteaya | and welcome | 16:19 |
| anteaya | we had discussed putting gerritbot in here but felt with the lag in changeover after we were done that it wasn't worth it for this sprint | 16:21 |
| clarkb | pleia2: maybe you want to update 135397 with your suggested fix then we can get that through? | 16:39 |
| pleia2 | clarkb: sure | 16:40 |
| *** annegent_ has joined #openstack-sprint | 16:40 | |
| pleia2 | there we go | 16:43 |
| clarkb | danke | 16:43 |
| anteaya | so I have a few comments in https://review.openstack.org/#/c/138094/1 about style things | 16:44 |
| anteaya | like should we have a manual wide syntax for saying "this value needs to be replaced"? | 16:45 |
| anteaya | <replacethisvalue> | 16:45 |
| anteaya | $replacethisvalue | 16:45 |
| anteaya | have both been suggested | 16:45 |
| anteaya | I'd like to pick one | 16:45 |
| anteaya | anyone else care/have thoughts? | 16:46 |
| pleia2 | I'll sift through docs standards, this must be covered | 16:46 |
| anteaya | pleia2: well it is possible that both are used, depending on the documentation | 16:46 |
| anteaya | so don't take too much time with it as we may just have to pick one ourselves | 16:47 |
| anteaya | but I would like to see anything you find on the topic | 16:47 |
| annegent_ | pleia2: currently in the install guide we have chosen <replaceable>VARIABLENAME</replaceable> with no dollar sign, but we do get complaints it's not copy pastable | 16:49 |
| pleia2 | I don't see anything, but I think I'd prefer the man-style <this> thing | 16:50 |
| annegent_ | pleia2: https://wiki.openstack.org/wiki/Documentation/Markup_conventions#Variable_text | 16:50 |
| clarkb | I personally prefer $foo | 16:51 |
| pleia2 | annegent_: aha, I was only looking through the contents of the first menubar on that page, thanks :) | 16:51 |
| pleia2 | clarkb: me too, but I think that's my geek brain | 16:51 |
| pleia2 | documentation for normal people seems to use other things | 16:51 |
| anteaya | can we get a core to mark https://review.openstack.org/#/c/109800/ as wip and take any third party issues out of the rotation for this sprint please? | 16:52 |
| fungi | anteaya: on it | 16:52 |
| anteaya | thanks | 16:53 |
| anteaya | I don't care whether we pick $foo or <foo> for infra-manual | 16:53 |
| anteaya | just that we pick one | 16:54 |
| anteaya | I can set up a poll if we need to | 16:54 |
| anteaya | so we can vote on it | 16:54 |
| fungi | ¿foo? | 16:54 |
| *** krtaylor has joined #openstack-sprint | 16:54 | |
| *** chandankumar has joined #openstack-sprint | 16:54 | |
| anteaya | I don't think that the <replaceable>VARIABLENAME</replaceable> is what we want here, thanks though annegent_ | 16:54 |
| anteaya | fungi: there's an option too | 16:55 |
| fungi | or just ☃ | 16:55 |
| *** annegent_ has quit IRC | 16:55 | |
| clarkb | fungi: :) | 16:55 |
| clarkb | replace all instances of snowman with context sensitive data | 16:55 |
| anteaya | ha ha ha | 16:57 |
| anteaya | can't wait for the translation team to weigh in on that | 16:57 |
| fungi | it's a universal constant... no need to translate it | 16:59 |
| clarkb | anteaya: for 108857 does someone want to just add that comma so that we can move on? | 16:59 |
| jeblair | annegent went away :( | 17:00 |
| clarkb | anteaya: note that david is correct about not being able to link to section on git.o.o | 17:00 |
| jeblair | AJaeger: does "<replaceable>VARIABLENAME</replaceable>" do something in docbook? | 17:01 |
| jeblair | perhaps we should make an RST role that does some special decoration? | 17:01 |
| pleia2 | clarkb: yeah, I'll take care of that one too | 17:02 |
| jeblair | "The text is frequently italicized in output. " from the wiki page | 17:02 |
| anteaya | clarkb: sorry I just realized I had a draft comment there that I never published | 17:04 |
| anteaya | clarkb: re-reading the patch | 17:05 |
| *** hashar has quit IRC | 17:05 | |
| clarkb | dhellmann: any chance you will be able to address the comments in 138094 this morning? | 17:06 |
| clarkb | awesome looks like dhellmann is one step ahead of me :) | 17:08 |
| jeblair | anteaya: re your general comment on 138094 | 17:08 |
| anteaya | jeblair: yes | 17:09 |
| anteaya | do share your thoughts | 17:09 |
| fungi | any objections to me slightly reworking 108857 per my inline comment? | 17:09 |
| jeblair | anteaya, dhellmann: i think that 'project creators' (or possibly a variant like 'project administrators', or 'project configurators' :) may warrant a manual section... | 17:09 |
| anteaya | yay | 17:09 |
| clarkb | fungi: nope | 17:10 |
| anteaya | boy that would make it easy | 17:10 |
| jeblair | at least, it seems to fit in the same kind of audience classifacation as "developers", "core reviewers", "project drivers" ... "project creators" | 17:10 |
| anteaya | makes sense to me | 17:10 |
| * anteaya notes we still need to have the snippets conversation, just not right now | 17:10 | |
| jeblair | (otherwise, i would suggest it belongs with "project drivers", but i actually think they may often be distinct groups of people) | 17:10 |
| anteaya | dhellmann: what kind of label would you like? | 17:11 |
| anteaya | it is a hefty bit of doc in and of itself | 17:11 |
| dhellmann | jeblair: the problem with a special rst role for variables is it can't be used inline with other markup like preformatted blocks | 17:12 |
| dhellmann | clarkb: yeah, I was in the oslo meeting when those came in | 17:12 |
| fungi | pleia2: regarding your reply on my comment, is there some consensus that we should inline display the urls of non-cooked documentation or other files (rather than hyperlinking descriptive text)? | 17:13 |
| dhellmann | jeblair: yeah, I really want this thing to be one LOOOONG list of instructions (well, I'd really prefer a short list, but you know) | 17:13 |
| pleia2 | fungi: no, I think that's the problem | 17:13 |
| fungi | pleia2: if so, then i'm cool with that. just want to make sure we're reasonably consistent | 17:13 |
| jeblair | currently, it's in the form of a tutorial, which is great; i think eventually we may want to evolve a reference-oriented approach (but still keeping a tutoral perhaps as a separate section). i think if/when that happens, we may be motivated to find a name for it that encompases ongoing administration. | 17:13 |
| dhellmann | anteaya: label? for variables? I'm OK with the <> syntax (see my common on draft 1) | 17:14 |
| jeblair | so i think 'project creators' works for now :) | 17:14 |
| pleia2 | fungi: I'm actually inclined to agree with you, since it's proper rst-wise whether we're publishing it somewhere or not (plus, we might some day) | 17:14 |
| dhellmann | jeblair: wfm | 17:14 |
| anteaya | dhellmann: I like <> personally | 17:15 |
| dhellmann | anteaya: ok, I think pleia2 did, too, so I'll go make that change now | 17:15 |
| anteaya | and you do raise a good point about using $foo and getting confused with shell script | 17:16 |
| fungi | pleia2: i think in this case it counts as a to-do item for the git-review project (there's no reason i'm aware of that we're not publishing its documentation to, e.g., docs.o.o/developer/git-review) | 17:16 |
| anteaya | clarkb: any thoughts ^^ | 17:16 |
| pleia2 | fungi: sounds good, I'll linkify | 17:16 |
| fungi | pleia2: i already have the patch ready, just wanted to check with you before pushing | 17:17 |
| clarkb | anteaya: I think $foo beingconfused with a shell script is the whole point | 17:17 |
| clarkb | anteaya: you can export foo=thingIneed then evaluate any of the text in the document to get the output you really want | 17:17 |
| pleia2 | fungi: oh, go for it | 17:18 |
| fungi | pleia2: already done | 17:18 |
| dhellmann | anteaya: done | 17:18 |
| jeblair | perhaps we should adopt "$FOO" as a style since it serves the dual purpose of indicating replacability and being directly replaceable in shell scripts (and still likely to fail if the person does not set a value) | 17:19 |
| fungi | <foo> means required parameter to those who read manpages a lot, but i agree it's potentially confusing if someone accidentally pastes it directly into a command prompt since they end up with fd redirections instead | 17:21 |
| fungi | also it gets complicated to render in some html-oriented situations | 17:21 |
| fungi | +1 for $foo in command-line examples | 17:21 |
| jeblair | fungi: though sphinx should take care of <> for us | 17:21 |
| fungi | in this particular case, yes | 17:22 |
| * anteaya waits | 17:22 | |
| anteaya | dhellmann: can sphinx do some <> magic? | 17:23 |
| dhellmann | anteaya: yeah, it will render properly | 17:23 |
| fungi | in non-sphinx situations where the document could get rendered as fuzzy sgml, it's possible for the browser to hide it as an unrecognized tag | 17:23 |
| jeblair | anteaya: it's automatic, it's not a concern | 17:23 |
| fungi | but for this case it's not a concern | 17:23 |
| dhellmann | I can change them to $ if you like, and use all caps, too | 17:23 |
| anteaya | so do we have consensens? | 17:23 |
| * dhellmann doesn't have a bike in this shed :-) | 17:23 | |
| anteaya | AJaeger: looks like we need an entry on the doc style conventions | 17:24 |
| anteaya | AJaeger: we appear to agree we are using $FOO for values that need to be replaced | 17:24 |
| jeblair | yeah. i think we need to choose one style to keep our readers from going crazy, and it seems like $FOO is the most useful, particularly in preformatted blocks of shell commands, which we have a lot of | 17:25 |
| anteaya | yes, my goal was one style, so if this is it, I'm good | 17:26 |
| dhellmann | ok, $FOO works for me | 17:26 |
| anteaya | yay | 17:26 |
| jeblair | (though if you look at the bottom of dhellmann's change, there's a lot of $VARIABLES which actually don't need to be substituted | 17:26 |
| jeblair | so that's sort of context-dependent) | 17:26 |
| dhellmann | jeblair: yeah, I just spotted those | 17:27 |
| dhellmann | this may be a case where one-size-fits-all doesn't | 17:27 |
| *** chandankumar has quit IRC | 17:28 | |
| jeblair | clarkb: ^ a case for why we shouldn't use $foo -- they are indistinguishable from variables that you should _not_ substitute | 17:28 |
| clarkb | hrm | 17:29 |
| dhellmann | jeblair, clarkb : it has been a while, but that might be why I chose to just go with 'projectname' in the wiki page, assuming it was clear that it needed to be replaced | 17:29 |
| jeblair | dhellmann: you're right about the inline block case; though i think if we really really wanted styled inline blocks, we could define a new directive that did that ('.. niftyinlinereplacementhighlighting::') | 17:30 |
| dhellmann | jeblair: quite likely | 17:30 |
| jeblair | i'm now uncomfortable with the $FOO idea that i think we ought to stick with the <projectname> syntax dhellmann has for now | 17:32 |
| jeblair | i think it will work well enough for the moment and will be more unambiguous if we want to change it later. | 17:33 |
| anteaya | I can get behind <projectname> | 17:33 |
| clarkb | wfm | 17:34 |
| dhellmann | would it make sense to add a style section to the guide itself? | 17:34 |
| fungi | how about all-caps with no additional wrapper characters? | 17:34 |
| dhellmann | fungi: that has the same ambiguity questions when documenting changes to devstack | 17:34 |
| dhellmann | s/questions/issues | 17:34 |
| anteaya | dhellmann: well we are using the Documentation team's style guide | 17:35 |
| fungi | that's infrequently confusing in command-line examples because programmers are lazy and don't like to hold down shift or needlessly strike caps-lock | 17:35 |
| dhellmann | fungi: PROJECTS="openstack/<projectname> $PROJECTS | 17:35 |
| anteaya | https://wiki.openstack.org/wiki/Documentation/Conventions | 17:35 |
| fungi | hrm, yeah i suppose so | 17:35 |
| dhellmann | anteaya: I was thinking of a small section at the top saying "when you see <projectname> in an example, replace it with the name of your project" or whatever | 17:36 |
| anteaya | dhellmann: ah a reader's usage style guide | 17:36 |
| * dhellmann notes that the real solution to this is to automate the process of generating the first version of the patch | 17:36 | |
| anteaya | dhellmann: I think we should have one infra-manual wide | 17:37 |
| fungi | a "documentation conventions" section? | 17:37 |
| anteaya | yeah | 17:37 |
| dhellmann | fungi: yeah | 17:37 |
| dhellmann | anteaya: sure, that makes sense, too | 17:37 |
| anteaya | makes sense, then readers know what we mean | 17:37 |
| fungi | that's a fairly common convention, so seems useful to tackle it that way | 17:37 |
| anteaya | well I hope that what we decide for conventions will be infra-manual wide | 17:37 |
| anteaya | shall we put it in the ehterpad as a todo? | 17:38 |
| anteaya | then we can track it | 17:38 |
| anteaya | https://etherpad.openstack.org/p/infra-manual-sprint-December-2014 | 17:38 |
| anteaya | I can add it | 17:38 |
| fungi | though i note that <> syntax is (less frequently) confusing in cases like `./script.sh </dev/null>/dev/null 2>&1 &` | 17:39 |
| anteaya | fair enough | 17:39 |
| anteaya | tough to find a one size fits all | 17:39 |
| fungi | since < and > are shell convention for redirecting file descriptors | 17:40 |
| fungi | yep. i think that's an unusual enough situation that it doesn't merit optimizing our style to avoid | 17:41 |
| fungi | just putting it out there that it can have a potentially confusing failure mode with invisible side effects if someone pastes a <foo> in a command line invocation without properly substituting | 17:42 |
| anteaya | yes | 17:44 |
| anteaya | jeblair: let me know when you are able to discuss https://review.openstack.org/#/c/104951/ | 17:44 |
| *** AJaeger_ has joined #openstack-sprint | 17:44 | |
| anteaya | jeblair: you suggest putting it in a section other than the one offered | 17:44 |
| anteaya | which I am fine with and you make a good point | 17:45 |
| anteaya | any thoughts on where to put it? | 17:45 |
| anteaya | is this a case for snippets, I wonder | 17:47 |
| dhellmann | anteaya: regarding the "groups" list; I'd like to have a valid default to mention in the docs but I don't know what it is. "openstack"? is that the launchpad project group name, or something else? | 17:48 |
| anteaya | dhellmann: you raise a good question, to which I dont' have the answer | 17:49 |
| anteaya | dhellmann: lets see if we can ask in -infra | 17:49 |
| fungi | pleia2: inline comments on 107741. let me know if you agree and would like me to address those or if you want to do it | 17:49 |
| dhellmann | anteaya: it looks like most projects don't have the value at all, so I assume it can be left out unless the lp project is not in the openstack project group | 17:50 |
| pleia2 | fungi: thanks, I'll have a look | 17:50 |
| anteaya | dhellmann: we could do that yes, to be honest I am uncertain of the state of launchpad/storyboard groups so I don't know if not offering a default value is the preference | 17:52 |
| jeblair | i need to check out for maybe 30-60 mins; anteaya: talk when i'm back? | 17:56 |
| anteaya | jeblair: of course, happy whateveritisyouaredoing | 17:58 |
| anteaya | dhellmann: the information fungi provides in the comment is actually useful information that I didn't clearly have before I read that | 17:58 |
| anteaya | dhellmann: any thoughts on capturing the information in the comment in the document? | 17:59 |
| fungi | anteaya: dhellmann: the history is that used to be a single-parameter option called "launchpad" which was used to do git repository to lp project mapping for situations where they were not equivalent. we renamed it to "group" and then later to "groups" and turned it into a list of potential group names, so that we can leverage it for grouping in storyboard at some point in the future | 18:00 |
| fungi | documenting the history isn't necessary, but pointing out that it's optional and in many (most?) cases unnecessary | 18:01 |
| fungi | would be good i think | 18:01 |
| anteaya | okay | 18:02 |
| anteaya | I'll just have these logs for my reference | 18:02 |
| dhellmann | fungi: done | 18:04 |
| fungi | dhellmann: thanks--going through it in greater detail now | 18:07 |
| *** jesusaurus has joined #openstack-sprint | 18:09 | |
| *** reed has joined #openstack-sprint | 18:11 | |
| anteaya | so where do we stand on directing new projects to set up launchpad pages? | 18:12 |
| pleia2 | I don't like continuing to go down that path, but it will be several months before storyboard is ready for them | 18:13 |
| pleia2 | I think we have to document how it's done today and update when it's time to make the transition | 18:13 |
| dhellmann | pleia2: ++ | 18:13 |
| fungi | yes, launchpad is where we (openstack projects on the whole) do bugs. best not to get ahead of ourselves | 18:16 |
| anteaya | dhellmann: how do we make a comment in .rst so we can note this section needs to be updated when we move to storyboard, but won't be published | 18:16 |
| anteaya | okay, as long as we have a plan | 18:16 |
| dhellmann | anteaya: if you prefix a section with just ".." that will make it a comment. I'll do that for the section you're talking about | 18:16 |
| anteaya | thanks | 18:16 |
| AJaeger_ | I'm currently updating developers.rst to remove reverify and noticed some overlong lines. | 18:17 |
| fungi | anteaya: dhellmann: though i also like to think of the rst files as readable plaintext documentation, so having content in there which is hidden from the rendered version ought to be avoided when reasonably possible | 18:17 |
| AJaeger_ | Ok to wrap them as part of changing a paragraph? Or should this be a separate patch? | 18:17 |
| anteaya | also it appears the cookiecutters will need to be allow for storyboard, if I understand nibalizer's cookiecutter concerns correctly | 18:18 |
| anteaya | AJaeger_: you are so wonderful, thank you | 18:18 |
| anteaya | fungi: fair enough | 18:18 |
| dhellmann | anteaya: done | 18:18 |
| *** gothicmindfood has joined #openstack-sprint | 18:18 | |
| anteaya | I would like some sort of indicator to show that we know this part of the process in in flux | 18:18 |
| dhellmann | anteaya: the templates provide a link to the place to report bugs for the project, so it should be easy enough to update them | 18:19 |
| pleia2 | combing through reviews+documentation now to identify some todo items for folks who want to pitch in, will add to the etherpad under "What you're working on now" so people can assign themselves | 18:19 |
| anteaya | it might stave off some questions from folks who wonder about storyboard | 18:19 |
| nibalizer | anteaya: that wasn't really my point but you're right that they'll need that | 18:19 |
| anteaya | pleia2: thanks, actually I have added a TODO section | 18:19 |
| anteaya | nibalizer: an extention of the point you made | 18:19 |
| pleia2 | anteaya: ah! just noticed that, I'll add there | 18:19 |
| anteaya | pleia2: thanks | 18:20 |
| anteaya | dhellmann: great | 18:20 |
| * dhellmann heads off in search of food | 18:21 | |
| anteaya | dhellmann: enjoy | 18:22 |
| anteaya | yay we are merging stuff: http://git.openstack.org/cgit/openstack-infra/infra-manual/log/ | 18:25 |
| anteaya | \o/ | 18:25 |
| pleia2 | anteaya: are we going to ignore 3rd party entirely during this sprint? (I don't remember what the consensus was as far as what goes in our docs and what goes elsewhere re: jaypipes' blog posts) | 18:25 |
| anteaya | yes, I would like to | 18:26 |
| pleia2 | ok, I'll make a note in the pad | 18:26 |
| anteaya | simply because we could spend two days on that material | 18:26 |
| krtaylor | pleia2, I thought we had agreed to wait until third_party.rst had been revised with the third-party WG | 18:26 |
| anteaya | thanks | 18:26 |
| krtaylor | agreed | 18:27 |
| anteaya | and we have entire manuals that have no content | 18:27 |
| anteaya | the core-reviewers section has nothing but titles | 18:27 |
| anteaya | so we focus on dev, core, ptl sections and get as far as we can | 18:27 |
| anteaya | and then rally round third party docs seperately | 18:27 |
| *** annegent_ has joined #openstack-sprint | 18:27 | |
| anteaya | pleia2: and thanks | 18:28 |
| anteaya | krtaylor: :D | 18:28 |
| pleia2 | anteaya: yep, under TODO I identified those sections | 18:29 |
| anteaya | thanks | 18:31 |
| anteaya | should we create an images directory? http://git.openstack.org/cgit/openstack-infra/infra-manual/tree/doc/source | 18:32 |
| anteaya | I'm leaning yes | 18:32 |
| pleia2 | Developer's Guide is pretty low hanging fruit, we need some project driver types and core reviewers to tackle much of what we have left to write | 18:32 |
| anteaya | pleia2: we do | 18:32 |
| anteaya | I think if we can focus on hitting the style and structure conventions in this sprint | 18:33 |
| anteaya | then we can track down ptl types and at least pick their brain for this info | 18:33 |
| anteaya | for the sections I don't know anyway | 18:33 |
| anteaya | I have time to do that at mid-cycles | 18:33 |
| anteaya | that was my plan | 18:34 |
| pleia2 | is anyone using blueprints anymore, or has everything been transitioned to specs? | 18:34 |
| AJaeger_ | pleia2: I think manila has no specs - but that's the odd one out. | 18:35 |
| fungi | pleia2: they're used together | 18:35 |
| AJaeger_ | Just document the specs process and add a section for project that only use blueprints but not specs repo. | 18:35 |
| AJaeger_ | pleia2: workflow is AFAIK : Create spec, create blueprint, get blueprint approved, approve spec | 18:36 |
| AJaeger_ | and create links between spec and blueprint | 18:36 |
| AJaeger_ | for the developers guide: What do we expect to cover in the merging part? | 18:36 |
| AJaeger_ | post jobs? | 18:36 |
| clarkb | ok sorry I got distracted. Turns out today is a good day to buy a laptop and I needed a new one | 18:36 |
| AJaeger_ | And that jobs get merged automatically? | 18:37 |
| clarkb | any pressing things I should look at? | 18:37 |
| anteaya | clarkb: pick a good one | 18:37 |
| anteaya | clarkb: ah you are back from shopping | 18:37 |
| clarkb | mostly. I do need to eat some food thouhg | 18:37 |
| AJaeger_ | reviews for https://review.openstack.org/138143 - removes reverify - are welcome | 18:37 |
| anteaya | me too | 18:37 |
| anteaya | I'm going to go eat then will respond to your questions AJaeger_ | 18:38 |
| AJaeger_ | anteaya: enjoy your mail! | 18:38 |
| pleia2 | AJaeger_: that workflow hurts my brain :( | 18:38 |
| AJaeger_ | pleia2: yeah ;( | 18:38 |
| AJaeger_ | pleia2: see http://specs.openstack.org/openstack/nova-specs/readme.html | 18:39 |
| AJaeger_ | I think most specs repos use a similar wording, once we have this in, we could send patches to the specs repo ;) | 18:39 |
| pleia2 | AJaeger_: thanks, I'll work with this for a patch and we can review away against it :) | 18:40 |
| AJaeger_ | pleia2: go for it! | 18:40 |
| reed | I've started putting the review checklist in developer.rst and wanted to ask how we want to treat the different instructions for separate programs | 18:44 |
| clarkb | reed: I think we would have to defer to the programs | 18:44 |
| clarkb | and be hand wavy about it | 18:44 |
| clarkb | imo this document shouldn't try to accomodate all the specific projects | 18:44 |
| reed | on https://wiki.openstack.org/wiki/ReviewChecklist there are notes for horizon and non-core... | 18:44 |
| reed | clarkb, I agree with you... | 18:45 |
| reed | ok, pushing the change up for review as I have it and we can discuss on gerrit the details | 18:45 |
| fungi | though mentioning practices common across a majority of programs is definitely on topic there | 18:45 |
| clarkb | yup | 18:45 |
| fungi | as perhaps is linking to places where you can find general info about program-specific practices not included in the document | 18:46 |
| reed | fungi, right ... would that be ... what? the generic landing page http://docs.openstack.org/developer ? | 18:48 |
| AJaeger_ | reed: that page has no review information, I think it's mainly in the wiki. Perhaps we need to create one. | 18:50 |
| reed | clarkb, what laptop are you buying? | 18:50 |
| clarkb | reed: x240 | 18:50 |
| clarkb | reed: ttx convinced me in paris that it actually is the machine I want. really good battery life, reasonable size and terrible trackpad | 18:50 |
| reed | AJaeger_, that page needs to be redone, yes... I have to start that conversation (I have a draft already, haven't had time to push the send button) | 18:50 |
| clarkb | but I can live with terrible trackpad as there are apparently xorg hacks to make it better | 18:51 |
| reed | clarkb, I live with an external mouse anyway :) | 18:51 |
| clarkb | can anyone reproduce `git review -d 137240` failures? | 18:51 |
| clarkb | it is failing for me | 18:51 |
| clarkb | also broadwell looks like a bust so I am not waiting for those chips anymore | 18:52 |
| fungi | reed: i know some groups have their own specific details linked from the how to contribute wiki | 18:52 |
| AJaeger_ | clarkb: works for me in system-config | 18:52 |
| clarkb | oh its system config | 18:53 |
| clarkb | I am in project-config | 18:53 |
| clarkb | :/ | 18:53 |
| clarkb | AJaeger_: thank you | 18:53 |
| anteaya | nibalizer: your vote on https://review.openstack.org/#/c/107741/ got applied to patchset 9, did you want to review patchset 10? | 19:00 |
| nibalizer | sure | 19:05 |
| clarkb | jeblair: when you get back 108857 should be good to go and needs +3 | 19:07 |
| AJaeger_ | reed: your patch contains many whitespaces at EOL and the lines are not properly intented. Do you know what to do to fix this or do you need help? | 19:08 |
| clarkb | anteaya: 104951 do you plan on doing the refactor that jeblair suggested? | 19:08 |
| *** annegent_ has quit IRC | 19:08 | |
| reed | AJaeger_, I definitely need help with the whitespace issue. A .viminfo example I can grab? | 19:09 |
| clarkb | reed: set list then set listchars=tab:>-,trail:-,extends:#,nbsp:- will highlight trailing whitespace | 19:09 |
| AJaeger_ | reed: I don't have one to offer. I can offer to clean the patch up for you. | 19:09 |
| dhellmann | anteaya: your images directory: https://review.openstack.org/#/c/138153/ | 19:10 |
| reed | AJaeger_, I better learn how not to repeat that mistake :) it scales better, thanks for offering though | 19:10 |
| reed | clarkb, there is no way to delete those automatically? | 19:10 |
| AJaeger_ | reed: sure. Note that you need to indent lines in a enumerated list, see http://docutils.sourceforge.net/docs/user/rst/quickref.html#enumerated-lists | 19:11 |
| clarkb | reed: I think there may be. I prefer to highlight it | 19:11 |
| clarkb | so unsure of auto deletion | 19:11 |
| anteaya | clarkb: sorry I have marked 104951 as wip until I talk with Jim | 19:12 |
| anteaya | clarkb: yes, I want to find out where a better place for this should be | 19:12 |
| clarkb | anteaya: sounds good | 19:13 |
| anteaya | thanks | 19:13 |
| reed | clarkb, how to make those changes permanent? | 19:13 |
| clarkb | AJaeger_: 138148 has a -1 from me | 19:13 |
| anteaya | dhellmann: ah aren't you wonderful, thank you | 19:13 |
| clarkb | reed: I put them in my .vimrc file | 19:14 |
| clarkb | reed: on two separate lines so it is configured whenever vim runs | 19:14 |
| fungi | i hate that i'm such a slow reader | 19:14 |
| fungi | dhellmann: i just added 23 comments to patchset 5 of 138094 | 19:15 |
| fungi | in that time it grew four new patchsets, so i'm not sure how many of them are relevant now | 19:15 |
| dhellmann | fungi: I'm working on adding sphinx docs to git-review for a bit, so I'll come back around and look at the comments in a while and ignore anything that's obsolete. Most of those other changes were really small though. | 19:16 |
| reed | thanks clarkb | 19:16 |
| fungi | dhellmann: yeah, i'm checking the diff now. hopefully it didn't include any rebases | 19:16 |
| reed | AJaeger_, what about indentation? I'm not sure i see the problem | 19:16 |
| dhellmann | fungi: I don't think I did | 19:16 |
| AJaeger_ | anteaya asks in https://review.openstack.org/138143 whether "recheck bug XXXX" is obsolete - I think it isn't. Anybody to clarify? | 19:17 |
| AJaeger_ | reed, write: | 19:17 |
| AJaeger_ | 1. test | 19:17 |
| AJaeger_ | test test | 19:17 |
| AJaeger_ | ARgh, one more space in front | 19:17 |
| AJaeger_ | 1. test long lline | 19:17 |
| AJaeger_ | next line of same paragraph | 19:17 |
| AJaeger_ | reed: see the link I gave | 19:18 |
| fungi | dhellmann: nope--looks like all my comments are still relevant | 19:18 |
| AJaeger_ | another question about 138143: The current section mentions the lanuchpad "openstack-ci project" | 19:19 |
| AJaeger_ | What should we say there? | 19:19 |
| clarkb | fungi: what is status on closing down openstack-ci and using the new tracker on launchpad? | 19:20 |
| clarkb | fungi: I see a fair amount of bug traffic via email today | 19:20 |
| clarkb | fungi: also https://review.openstack.org/#/c/138143/1/doc/source/developers.rst may need to be updated if we switch soon | 19:20 |
| fungi | clarkb: i haven't started yet | 19:21 |
| * fungi wears hat of shame | 19:21 | |
| reed | AJaeger_, how about nested enumerated lists? | 19:22 |
| clarkb | AJaeger_: comments on https://review.openstack.org/#/c/138143/ now too | 19:22 |
| fungi | i'll ping the relevant people on it now, but i'll add updating the text from 138143 (with a new patchset or another change if it's already merged) to the list of steps | 19:22 |
| AJaeger_ | clarkb: thanks for keeping me busy ;) | 19:22 |
| clarkb | AJaeger_: no problem | 19:22 |
| AJaeger_ | reed: Indent them. | 19:22 |
| AJaeger_ | reed: send a next review and I'll comment on it | 19:22 |
| reed | k | 19:23 |
| AJaeger_ | clarkb: pushed new change sets. | 19:26 |
| AJaeger_ | anteaya: you're right that we need to work storyboard in - but I propose to do this in a separate patch set. | 19:29 |
| anteaya | I will buy that | 19:30 |
| anteaya | you are the machine for patches, I am having trouble keeping up with you | 19:30 |
| anteaya | go go go | 19:31 |
| reed | AJaeger_, thanks, check the new patch I sent | 19:31 |
| anteaya | I'm going over the summit etherpad: https://etherpad.openstack.org/p/kilo-infra-manual to ensure we are addressing all the mentioned issues | 19:31 |
| pleia2 | anteaya: good thing someone is, my writing brain has apparently taken the day off, ugh | 19:31 |
| clarkb | its that long weekend hangover | 19:32 |
| clarkb | I am suffering from it as well | 19:32 |
| clarkb | doing my best to review | 19:32 |
| reed | developers.rst is a very long file already :) | 19:34 |
| clarkb | ya ... | 19:34 |
| clarkb | not sure if good or bad. But I think right now getting content then reorganizing as necessary may be best | 19:34 |
| reed | clarkb, totally agree with you: get off the wiki first :) | 19:35 |
| anteaya | pleia2: not to worry, just do the thing that is in front of you, you are doing great :D | 19:35 |
| anteaya | clarkb: ++ | 19:35 |
| * pleia2 soldiers on with specs/blueprints section | 19:35 | |
| AJaeger_ | reed: nicely reformatted, I could concentrate on nits ;) | 19:37 |
| AJaeger_ | yeah, two more patches merged ;) | 19:38 |
| clarkb | nibalizer: re 138159 not sure I want that there since its all generic "most other unix systems" too | 19:38 |
| clarkb | nibalizer: maybe link to generic pip how to install stuff instead? | 19:39 |
| anteaya | yay merged patches | 19:40 |
| anteaya | nibalizer: I'm in agreement with clarkb, using the word pip as an anchor leads me to believe we should be linking to pip docs | 19:41 |
| AJaeger_ | for the core.rst file: Should we document "Work in Progress" setting of somebody else's patch? | 19:42 |
| reed | do we want to keep https://wiki.openstack.org/wiki/GitCommitMessages in the wiki or move to infra-manual? | 19:43 |
| anteaya | AJaeger_: I think so | 19:44 |
| * AJaeger_ adds it to the etherpad as section | 19:44 | |
| anteaya | reed: it is a fairly hefty body of work | 19:44 |
| anteaya | reed: we have linked to it in the manual | 19:44 |
| reed | anteaya, ok, let's link it to wiki then | 19:44 |
| anteaya | reed: I think linking to it is fine for the moment | 19:44 |
| anteaya | reed: sounds good | 19:45 |
| reed | same with DocImpact, I guess | 19:45 |
| AJaeger_ | for now, let's leave it in the wiki - we can move this later. And then it needs to be a separate document. | 19:45 |
| reed | https://wiki.openstack.org/wiki/Documentation/DocImpact | 19:45 |
| AJaeger_ | reed, yeah, just link to those for now. | 19:45 |
| reed | ok, agreed | 19:45 |
| anteaya | great | 19:53 |
| nibalizer | clarkb: anteaya what if i move the link to 'osx' ? | 19:56 |
| nibalizer | that way you know you're getting something osxy ? | 19:56 |
| clarkb | nibalizer: no I think having an os x link in there at all is wrong | 19:57 |
| reed | AJaeger_, RST issue: this line with no break builds nicely 1. Learn the best practices for `git commit messages <https://wiki.openstack.org/wiki/GitCommitMessages>`_. | 19:57 |
| clarkb | nibalizer: we shouldn't try to handle every case ever. instead just say "use pip here are pip docs" | 19:57 |
| reed | but if I put a line break between 'messages' and '<http... the build fails | 19:57 |
| nibalizer | okay | 19:58 |
| nibalizer | ill just abandon | 19:58 |
| AJaeger_ | reed in that case don't wrap it ;) | 19:58 |
| reed | ah, simple then :) | 19:58 |
| * reed feels like rst is just another giant hack | 19:59 | |
| anteaya | nibalizer: I am in agreement with clarkb | 20:00 |
| anteaya | nibalizer: please don't abandon | 20:00 |
| anteaya | nibalizer: it would be great to have a link to pip docs | 20:00 |
| anteaya | just change the commit message and links | 20:00 |
| reed | seems like SecurityImpact is not fully documented on the wiki (couldn't find a URL for it) | 20:01 |
| nibalizer | anteaya: oh okay | 20:01 |
| nibalizer | will do | 20:01 |
| AJaeger_ | reed: You can link to https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references | 20:02 |
| AJaeger_ | There's also APIImpact now | 20:02 |
| AJaeger_ | reed: ping the security team to write a nice wiki page about it;) | 20:02 |
| reed | it's pretty awful but I'll make do | 20:02 |
| reed | same with apiimpact | 20:02 |
| anteaya | nibalizer: thanks | 20:03 |
| AJaeger_ | reed, might be better not to link for those two for now. | 20:04 |
| clarkb | AJaeger_: there was already a WIP doc change somewhere | 20:04 |
| clarkb | AJaeger_: is yours conflicting with that? | 20:04 |
| AJaeger_ | clarkb: OOps, let me check | 20:04 |
| AJaeger_ | clarkb: I can't find it | 20:04 |
| clarkb | ya I can't find it either but I swear I reviewed it this morning | 20:05 |
| clarkb | AJaeger_: I9ce84f5db0aac5e3e5e0ef8a1d8c3497903c16ac found it | 20:05 |
| dhellmann | fungi: regarding the pypi permissions, I have been telling everyone to use Owner for precisely the reason you point out -- it would let us edit all of the settings and remove a human "owner" who leaves the project | 20:06 |
| AJaeger_ | clarkb: that's for developers - I think we need to document it for cores as well, don't we? | 20:06 |
| clarkb | AJaeger_: oh I see the distinction | 20:07 |
| clarkb | AJaeger_: yup | 20:07 |
| AJaeger_ | clarkb: should we crosslink from core.rst to developer.rst? | 20:07 |
| fungi | dhellmann: that's a valid counterargument | 20:07 |
| clarkb | AJaeger_: I think the audience is sufficiently different that we don't need to | 20:08 |
| anteaya | fungi: can we get https://review.openstack.org/#/c/138153/ merged and then dhellmann can rebase? | 20:09 |
| AJaeger_ | clarkb: let me move WIp to the end of the file, I'm currently looking into the other sections | 20:09 |
| clarkb | AJaeger_: ok | 20:09 |
| fungi | anteaya: done | 20:09 |
| AJaeger_ | clarkb: send again, no text changes | 20:10 |
| dhellmann | fungi, AJaeger_ : we should talk about the warnings for the project-config changes | 20:10 |
| AJaeger_ | clarkb: thanks for the review | 20:10 |
| anteaya | fungi: thank you | 20:11 |
| dhellmann | I found that those 2 spots where I included warnings to be the most commonly out of date sections, and included the warnings in the wiki so Oslo devs would pay attention and update the wiki as needed. It also reduced frustration at having a patch that "followed the directions" being rejected by the project-config team. | 20:11 |
| AJaeger_ | dhellmann: thinking how long it took us with infra-manual to come to the current state, it might be better to leave the warnings in ;( | 20:11 |
| anteaya | I am fine with the warnings in | 20:11 |
| reed | AJaeger_, I noticed that if I don't indent the line break, the file builds: 6. The code should comply with the community `logging standards | 20:11 |
| reed | <https://wiki.openstack.org/wiki/LoggingStandards>`_. | 20:11 |
| dhellmann | obviously, all of this *could* get out of date, but those are the spots that did *every time* we created a new repo -- there was a lot of template refactoring going on last cycle, I think | 20:12 |
| anteaya | dhellmann: and no reason to believe template refactoring won't continue | 20:12 |
| AJaeger_ | reed, send in what works ;) | 20:12 |
| dhellmann | AJaeger_: if this doc was in the project-config repository, those sections could pull in live examples using an include directive | 20:12 |
| dhellmann | anteaya: sure, though I think/hope maybe the pace will slow down now | 20:12 |
| anteaya | dhellmann: idealist | 20:13 |
| AJaeger_ | ;) | 20:13 |
| dhellmann | anteaya: touche | 20:13 |
| AJaeger_ | dhellmann: we just merged today another templatization patch ;) | 20:13 |
| dhellmann | AJaeger_, fungi : would it be more palatable if I included a sentence about submitting a patch to the doc if it is out of date? | 20:13 |
| dhellmann | AJaeger_: death by 1000 refactorings | 20:14 |
| anteaya | dhellmann: yeah, work with AJaeger_ a bit longer | 20:14 |
| anteaya | dhellmann: dude must rearrange his furniture in his house everyday | 20:14 |
| anteaya | for maximum efficientcy | 20:14 |
| anteaya | :D | 20:14 |
| fungi | dhellmann: yeah, i think that's reasonable. but also we should try to be better about updating our documentation if we're making changes to that stuff... especially now that it's rst in git | 20:15 |
| AJaeger_ | anteaya: my family won't let me ;) | 20:15 |
| anteaya | ha ha ha | 20:15 |
| anteaya | what magic incantation did they use, and can they teach it to me? | 20:15 |
| AJaeger_ | dhellmann, agreed | 20:15 |
| dhellmann | fungi: totally agree with wanting to be better | 20:15 |
| * AJaeger_ is not going to answer anteaya ;) | 20:16 | |
| anteaya | ha ha ha | 20:16 |
| anteaya | :D | 20:16 |
| fungi | dhellmann: i fairness, it was harder to keep updated when it was documented in a wiki article which was maybe only somewhat known to the infra team | 20:16 |
| dhellmann | fungi: yes, that was completely the problem and I knew that going in -- it was easier for us to manage it in the wiki until we had the steps worked out | 20:17 |
| fungi | i'm hoping that we can convince people proposing major architectural changes to job stuff to update the relevant infra manual sections while they're at it | 20:17 |
| dhellmann | fungi: I didn't expect you all to manage the directions at that point | 20:17 |
| jeblair | 'grep' helps a _lot_ with this sort of thing | 20:17 |
| dhellmann | fungi: ok, in the spirit of optimism that that will happen, I'll remove the warnings :-) | 20:18 |
| fungi | dhellmann: my main concern with pessimistic warnings about it having the possibility of falling out of date is that it can reduce the reader's confidence in the accuracy of what they're reading (and thus the point in reading it at all) | 20:20 |
| dhellmann | fungi: fair | 20:20 |
| fungi | which just means they come asking us every time | 20:21 |
| fungi | somewhat defeating the purpose of having a manual | 20:21 |
| AJaeger_ | fungi: we should ask people doing changes for project-config etc. to update infra-manual if needed as well. | 20:23 |
| AJaeger_ | But that means we need to be aware of the content of infra-manual. | 20:23 |
| anteaya | AJaeger_: I have no problem with that | 20:24 |
| fungi | AJaeger_: yeah, i'm hoping anyone who acts as a core reviewer on any openstack-infra project has more than a passing familiarity with the contents of the infra manual ;) | 20:24 |
| AJaeger_ | anteaya: it's something we should do as review on a best-effort base. I'm fine with adding a -1 to a patch and asking for a patch for infra-manual first | 20:24 |
| AJaeger_ | fungi: not only familiarity but also knowing that it's documented and that a proposed patch will "break" the manual - and thus the manual needs updating | 20:25 |
| anteaya | sure | 20:25 |
| fungi | AJaeger_: everything we do is "best effort" anyway, so no disagreement from me. there are no guarantees | 20:25 |
| anteaya | the manual patch doesn't need to be merged, just exist and linked in the commit message with the project-config patch mentioned in the commit message of the manual patch | 20:26 |
| AJaeger_ | fungi: yeah... | 20:26 |
| AJaeger_ | anteaya: yes, indeed | 20:27 |
| fungi | i'm also hoping that we find ways to make infra-manual and our related infra projects abstracted from one another enough that it takes more than trivial changes to invalidate the documentation, so i wouldn't expect that to come up all the time unless we're doing something wrong | 20:27 |
| dhellmann | fungi: ps 9 of https://review.openstack.org/#/c/138094/ should address your comments | 20:41 |
| fungi | dhellmann: great--thanks! | 20:41 |
| anteaya | I am noting the time and realize that I haven't gone for a walk yet today | 20:44 |
| clarkb | and I haven't eaten | 20:44 |
| clarkb | so I am doing that now | 20:44 |
| anteaya | so I am heading out and will be back in about an hour | 20:44 |
| anteaya | clarkb: yes thank you, eating is a good idea | 20:44 |
| anteaya | please eat | 20:44 |
| AJaeger_ | clarkb: enjoy! | 20:50 |
| AJaeger_ | anteaya: have a great walk! | 20:51 |
| reed | dhellmann, the instructions to create a new project may also go somewhere in docs.openstack.org/developer but I don't know how to do that | 20:52 |
| reed | in theory the whole content of infra-manual may well sit there since it's documentation for infra tool as much as it is documentation for contributors | 20:53 |
| dhellmann | reed: I assume there are plans to publish the infra-manual stuff, if it isn't already being published | 20:53 |
| reed | dhellmann, it's published already afaik | 20:54 |
| reed | http://docs.openstack.org/infra/manual/ | 20:54 |
| pleia2 | lunch break here too, bbiab | 20:55 |
| AJaeger_ | and linked from http://docs.openstack.org/ , see "OpenStack Infrastructure User Manual " | 20:56 |
| AJaeger_ | reed: for adding something to the index page - it's a patch against openstack-manuals | 20:57 |
| AJaeger_ | reed: To get something published on docs.openstack.org: That's a patch against project-config repo | 20:57 |
| reed | AJaeger_, thanks | 20:57 |
| jeblair | anteaya: i'm back; i'm sorry that took so long :( | 21:02 |
| AJaeger_ | jeblair: Now she's gone for a walk ;) | 21:02 |
| jeblair | i know :( | 21:02 |
| jeblair | we should probably drop stackforge.rst from system-config docs once dhellmann's change merges | 21:04 |
| clarkb | + | 21:04 |
| clarkb | er ++ | 21:05 |
| fungi | agreed, i'm hoping it can fully replace that old document | 21:05 |
| AJaeger_ | agreed | 21:05 |
| fungi | dhellmann: the change lgtm but AJaeger_ has some good suggestions in there too. i think it's getting veeeery close now | 21:06 |
| AJaeger_ | fungi: +1 | 21:08 |
| jeblair | hrm, i'm not sure i'm keen on the new project creation instructions requiring github | 21:09 |
| jeblair | it should be pretty easy to re-order those to "create the project, clone it, run cookiecutter, git commit, git review", right? | 21:09 |
| AJaeger_ | jeblair: do you want to start with an empty repo? | 21:11 |
| clarkb | ya or even host cookiecuttered project not on github | 21:11 |
| AJaeger_ | Can we import from anywhere that is a public location? | 21:12 |
| clarkb | yup | 21:12 |
| jeblair | AJaeger_: yes. i think starting from an empty repo is a good thing | 21:12 |
| fungi | right, unless there are preexisting commits you need imported to preserve history, you should ideally start with the empty repo and push your initial content as the first change | 21:12 |
| AJaeger_ | fungi: agreed | 21:12 |
| fungi | the trick there is that cookiecutter will create a new git repo, right? so you need to adjust your remote and rebase it onto the initial .gitreview commit added by manage-projects in that case | 21:13 |
| dhellmann | AJaeger_: ps 10 should address your comments | 21:13 |
| clarkb | nibalizer: can you update the commit message on https://review.openstack.org/#/c/138159/2 too? | 21:13 |
| AJaeger_ | dhellmann: it does - I'm calling it a day now ;) | 21:15 |
| dhellmann | AJaeger_: thanks for your reviews | 21:15 |
| * AJaeger_ waves good-bye. I'll continue in 10 hours | 21:15 | |
| AJaeger_ | dhellmann: thanks a lot for your great patch and ultra-fast turn-around! | 21:15 |
| *** AJaeger_ has quit IRC | 21:16 | |
| jeblair | i need to add a command to "copy my line comments from previous patchset" to gertty | 21:17 |
| clarkb | pleia2: re 138179 did you want to address the suggestions there? there is no -1 but figured I would aks before I +2 | 21:18 |
| dhellmann | jeblair: these instructions are turning into something useless to me for oslo. I may have to maintain my wiki page even if this thing merges. | 21:19 |
| dhellmann | jeblair: what's more common, creating a project from scratch or importing something that has been started elsewhere? | 21:19 |
| jeblair | dhellmann: oh, i thought my suggestion was not incompatible with oslo | 21:19 |
| dhellmann | jeblair: in 99% of the cases for oslo there will be a repository somewhere that we need to import | 21:19 |
| jeblair | dhellmann: i was referring to where you provide directions on creating a new project from scratch | 21:20 |
| jeblair | dhellmann: i believe that both cases should be documented; i just thing that the case where a project is created from scratch should have different instructions | 21:20 |
| dhellmann | jeblair: yeah, we don't actually do that for oslo so I guess it doesn't matter | 21:20 |
| dhellmann | jeblair: ok, the initial steps are actually pretty different in the from scratch case that doesn't involve an import -- several of the other sections end up having to be split up because you don't want to add test jobs until there's content, for example | 21:21 |
| dhellmann | oh, I see, I didn't copy over the oslo-specific steps for exporting a repository | 21:22 |
| jeblair | dhellmann: are we still talking about the 'from scratch' case? | 21:22 |
| pleia2 | clarkb: yeah, I'll address those in a few | 21:22 |
| dhellmann | jeblair: we are, although I'm assuming there's some stuff in that repository besides what cookiecutter creates | 21:22 |
| jeblair | dhellmann: it's okay to add test jobs for an empty repository -- the first commit just needs to add whatever they need. cookiecutter should do that (eg, unit tests should noop successfully) | 21:23 |
| dhellmann | I guess the only difference is that there's a step after creating the repository to populate it, where if you have a repository you DO NOT want that, you want it imported | 21:24 |
| jeblair | dhellmann: yes (though it saves you the step of creating the project in github and pushing to it). but yes, you very much don't want to create an empty repo if you plan on importing | 21:25 |
| dhellmann | jeblair: it's hard to make a linear set of instructions that supports both of these cases; lots of gotos | 21:27 |
| dhellmann | jeblair: I'll look at it a little more | 21:27 |
| jeblair | dhellmann: ok. i'm not looking at it right now, but the vague idea in my head was that you'd discuss the import option when writing the project-config change, and then discuss the create-from-scratch option later on; so mostly linear with a few conditionals | 21:29 |
| dhellmann | yeah, that may work | 21:29 |
| jeblair | later-on == after approval+creation | 21:29 |
| *** jesusaur has joined #openstack-sprint | 21:29 | |
| anteaya | jeblair: I am back now | 21:30 |
| anteaya | and ready to discuss that patch | 21:30 |
| jeblair | woohoo | 21:30 |
| anteaya | here it is: https://review.openstack.org/#/c/104951/ | 21:31 |
| * anteaya listens | 21:31 | |
| *** jesusaurus has quit IRC | 21:31 | |
| *** jesusaur is now known as jesusaurus | 21:31 | |
| jeblair | anteaya: a lot of the material in there feels somewhat like a tutorial | 21:33 |
| anteaya | fair enough | 21:33 |
| anteaya | what is our ability to do javascripty expandable sections with rst | 21:33 |
| jeblair | which i think is really useful, but i don't want experienced git users to see it and think that the whole section is not for them | 21:33 |
| anteaya | then the folks who don't need the tutorial can not expand and aren't overwhelmed by content | 21:33 |
| anteaya | right | 21:33 |
| anteaya | and I wrote it for the brand new newbs I was handholding | 21:34 |
| anteaya | I don't tend to spend much time wiht the experienced git users | 21:34 |
| anteaya | they don't need me | 21:34 |
| anteaya | so how do we address both audiences | 21:34 |
| anteaya | without upsetting the other? | 21:34 |
| jeblair | we could create a new standalone document or section for this walkthrough, and link to it from the developer manual? | 21:35 |
| anteaya | sure | 21:35 |
| anteaya | we have a section in the repo called notes | 21:35 |
| anteaya | I could stuff it in notes | 21:35 |
| jeblair | i think there are some similarities with the current work around new projects (except that most of that doesn't also have reference material yet) | 21:35 |
| anteaya | sorry notes is a file, I'm not sure where it is used | 21:36 |
| jeblair | anteaya: i think notes might be left over from my original sketch :) | 21:36 |
| anteaya | ah | 21:36 |
| anteaya | that would make sense | 21:37 |
| anteaya | so how to address the needs of the seasoned dev who needs slim docs so they feel comfortable and contribute | 21:39 |
| anteaya | and have something to point brand new people to so that I don't have to keep repeating myself | 21:39 |
| jeblair | anteaya: so i'm okay with the first part of that change more or less as-is where you change 'nova' -> 'sandbox' (even with the additional text) | 21:40 |
| anteaya | not sure if you caught it last night but the devs intel has selected for setting up the third party ci for nfv have never used irc before, so that was last night's work | 21:40 |
| jeblair | i think that's a good idea regardless | 21:40 |
| anteaya | okay, thanks | 21:41 |
| jeblair | anteaya: then the next section is really basic (like what happens if you are in the wrong directory), and then there's some stuff that's repetitive with the following sections in the manual | 21:43 |
| jeblair | anteaya: (under 'starting a change', we talk about how to create a branch, etc) | 21:43 |
| anteaya | yeah | 21:44 |
| fungi | i'm going to run out to grab some food. need to drill holes in walls tonight and want to be able to do that before it's so late i feel bad for the neighbors. after that i'll get some more infra-manual reviews knocked out | 21:44 |
| anteaya | and that is the stuff I have to tell folks over and over again | 21:44 |
| anteaya | since they don't know it and they don't know what to do | 21:44 |
| jeblair | anteaya: so i think that's all stuff that can be removed from this section without losing information | 21:44 |
| anteaya | and if it isn't written down, I have do tell them | 21:45 |
| jeblair | anteaya: well, it is written down, in the very document it's being added to | 21:45 |
| anteaya | fungi: thanks enjoy food and drilling | 21:45 |
| anteaya | jeblair: can I see it in a comment, so I know which lines you mean? | 21:45 |
| jeblair | anteaya: sure | 21:46 |
| anteaya | I have no problem removing repetition | 21:46 |
| anteaya | thanks | 21:46 |
| * anteaya puts some soup on the stove | 21:50 | |
| dhellmann | jeblair: see what you think of ps 12 on https://review.openstack.org/#/c/138094/ | 21:52 |
| jeblair | anteaya: specific line comments left. | 21:54 |
| anteaya | jeblair: thank you | 21:55 |
| * anteaya reviews | 21:55 | |
| anteaya | pleia2: you can't git clone by clicking an https link | 21:56 |
| anteaya | but I take your point about expectations around links in docs | 21:56 |
| pleia2 | anteaya: you can't do anything by clicking on the http link | 21:56 |
| pleia2 | er, https | 21:57 |
| pleia2 | it opens a blank page, that confuses folks | 21:57 |
| jeblair | can we convince sphinx _not_ to hyperlink that? | 21:57 |
| clarkb | literal quote it? | 21:57 |
| jeblair | pleia2: also, istr some conversation about using mod rewrite to inspect incoming headers and possibly redirect that for non-git clients... is that something we should do? | 21:58 |
| pleia2 | jeblair: I dunno, that gets sticky | 21:58 |
| anteaya | clarkb: double or single quotes? | 21:59 |
| clarkb | `` iirc | 21:59 |
| clarkb | ``stuff`` | 21:59 |
| jeblair | dhellmann: generally lgtm, thanks; left inline nit. | 21:59 |
| anteaya | I'll try ``stuff`` thanks, those are backticks I used not quotes | 22:00 |
| clarkb | yup | 22:01 |
| dhellmann | jeblair: nit addressed | 22:01 |
| clarkb | I will review dhellmann's change next | 22:02 |
| dhellmann | I'm going to call it a day. I'll check back for more comments on that creator's guide in the morning. Thanks for your help today, everyone! | 22:05 |
| anteaya | dhellmann: thanks so much for all your help doug | 22:06 |
| anteaya | dhellmann: enjoy the evening | 22:06 |
| jeblair | dhellmann: thank you so much! you're filling in a huge gap in our docs! :) | 22:06 |
| anteaya | don't review my latest patchset I still need to figure out how to rework to remove duplication | 22:06 |
| jeblair | anteaya: i think it's worth figuring out why you don't like the existing content :) | 22:08 |
| anteaya | I like the existing content so much I duped it :D | 22:08 |
| jeblair | hehe | 22:08 |
| anteaya | trying to figure out how to figure out a better order | 22:08 |
| anteaya | or what I consider to be a better order | 22:08 |
| anteaya | I think part of it might be the sections | 22:12 |
| anteaya | getting started and development workflow | 22:12 |
| anteaya | since when I hand hold folks I don't even talk about anything else before they have a patch on sandbox | 22:12 |
| anteaya | since they haven't done enough to understand anything else anyway | 22:13 |
| jeblair | whereas normally we would not recommend a new developer start a patch without claimining a bug or blueprint first :) | 22:13 |
| jeblair | claiming even | 22:13 |
| anteaya | whereas it might be concievable that someone skips the getting started and moves straight to workflow | 22:13 |
| anteaya | starting a patch, yes | 22:13 |
| anteaya | and the folks I work with can't even comprehend starting a patch before they figure out the sandbox | 22:14 |
| anteaya | I guess it comes down to different audiences | 22:14 |
| anteaya | perhaps I am trying to make the manual be all things to all people | 22:15 |
| anteaya | and the folks I hand hold need something different than a manual | 22:15 |
| jeblair | anteaya: so i think our choices are to move your walkthrough to another section (and link to it from the dev guide), or merge all the existing 'git operations' together into the getting started section, similar to how you've structured the walkthrough (though we should probably still break it up into minor sections so we can link to, eg, "updating a change") | 22:18 |
| anteaya | the `` prevented the url from being a hyperlink but they show up in the text: http://docs-draft.openstack.org/51/104951/12/check/gate-infra-manual-docs/2b19394/doc/build/html/developers.html#development-workflow | 22:18 |
| anteaya | let's look at setting up another section and linking | 22:19 |
| anteaya | this won't be the first section that needs some remedial help | 22:19 |
| anteaya | you do make a good point, they need to create/find a bug or blueprint first, I don't want to be teaching folks bad habits | 22:20 |
| anteaya | so shall we create a directory of random pages not linked to the index page but linked via other pages? | 22:20 |
| clarkb | jeblair: I think the current stack of infra manual changes that are not WIP'd lgtm | 22:21 |
| *** sweston has joined #openstack-sprint | 22:21 | |
| *** jhesketh has joined #openstack-sprint | 22:25 | |
| dhellmann | anteaya: instead of :: try offsetting that block under a directive like: .. code-block:: none | 22:26 |
| dhellmann | anteaya: http://sphinx-doc.org/markup/code.html?highlight=code | 22:28 |
| jeblair | clarkb: me too, wasn't sure if we wanted to leave them out for more reviews (and possible nit fixes) or just go ahead and clear them out | 22:31 |
| anteaya | dhellmann: thanks I will try that | 22:31 |
| anteaya | clear them out | 22:31 |
| anteaya | please | 22:31 |
| dhellmann | anteaya: I tested it locally and it took care of it. The :: turns on "auto-highlighting" which tries to guess what syntax you're using. The ".. code-block:: none" turns off highlighting. | 22:32 |
| dhellmann | ok, now I'm really leaving my desk for the day | 22:33 |
| jeblair | dhellmann: oh, i thought you were back for another shift! ;) | 22:33 |
| anteaya | dhellmann: thanks | 22:33 |
| anteaya | I'm going to eat my soup and then will try what doug suggests | 22:33 |
| clarkb | jeblair: Ithink we should clear out. It is easy enough to go back and fix tyops and grammar | 22:35 |
| * clarkb gets into writing the feature branch section | 22:35 | |
| jeblair | okay, i merged 4, i left 138177 and 138179 though | 22:47 |
| anteaya | thank you | 22:52 |
| clarkb | https://review.openstack.org/138200 for feature branches | 22:53 |
| clarkb | anteaya: https://review.openstack.org/#/c/138195/1 spits out a sphinx warning and we fail on awarnings :/ | 23:00 |
| clarkb | anteaya: not sure how we want ot handle that, probably wait until we have aplace we want to link from? | 23:01 |
| anteaya | awesome, thanks | 23:01 |
| anteaya | hmmm, perhaps that is the problem I will put a link in the parent patch and see if that fixes things | 23:01 |
| clarkb | jeblair: anteaya: I have a question about reapproval on the sprint etherpad | 23:09 |
| clarkb | does anyone know what the answer to that is? I figure I can start knocking the unstarted ones out | 23:10 |
| anteaya | clarkb: sorry I don't know what you mean by reapproval | 23:11 |
| clarkb | anteaya: its on the etherpad | 23:11 |
| * anteaya was context switching | 23:11 | |
| * anteaya reads the etherpad | 23:11 | |
| clarkb | Re-approval | 23:11 |
| anteaya | line 54 | 23:12 |
| anteaya | I have no clue | 23:12 |
| anteaya | we will have to wait for jeblair | 23:12 |
| anteaya | I could guess and might brainstorm it might have something to do with getting stuck approved patches back into the gate | 23:13 |
| anteaya | but I'm not certain that would be its own heading in the docs | 23:13 |
| jeblair | oh | 23:15 |
| jeblair | let me see if i can recall what i was thinking :) | 23:15 |
| jeblair | clarkb: i think i was thinking about "reverify" or other stuff related to "this is approved but isn't merged" | 23:16 |
| anteaya | I guessed right | 23:17 |
| anteaya | would that need its own section in the manual? | 23:17 |
| jeblair | not necessarily; could probably be covered in the previous section | 23:18 |
| jeblair | i think the _topic_ deserves attention though | 23:18 |
| anteaya | agreed | 23:19 |
| anteaya | the topic does | 23:19 |
| clarkb | so a generic "things went wrong now what" section? | 23:20 |
| jeblair | clarkb: i hesitate to say yes to that phrasing :) | 23:21 |
| jeblair | clarkb: but i think we need to mention that you can approve again to re-enqueue | 23:22 |
| jeblair | clarkb: or leave a recheck comment | 23:22 |
| jeblair | clarkb: this has some overlap with the section in the developer guide that talks about what happens when jenkins fails (but i don't think we should focus on that here) | 23:23 |
| clarkb | ok let me take a stab at it | 23:23 |
| clarkb | anteaya: jeblair maybe something like https://review.openstack.org/138204 | 23:31 |
| jeblair | clarkb: ya | 23:32 |
| anteaya | I like it but jenkins doesn't | 23:33 |
| clarkb | any idea why my addition of _failed-tests as a target didn't work? | 23:33 |
| jeblair | clarkb: is '-' allowed? | 23:34 |
| clarkb | oh maybe not /me does local testing | 23:34 |
| jeblair | sphinx docs say it is | 23:35 |
| jeblair | ".. _my-reference-label:" is their example | 23:35 |
| jeblair | clarkb: but they say to use it use: ref:`my-reference-label` | 23:35 |
| clarkb | oh I wonder if what I used only works within one document | 23:36 |
| jeblair | yeah, there's a different syntax that only works in one doc, that might be it. :ref: works cross-doc | 23:36 |
| clarkb | jeblair: that works | 23:37 |
| clarkb | new patchset should work. builds locally | 23:38 |
| anteaya | clarkb: I'm going to try that for my link that didn't work | 23:40 |
| anteaya | are those backticks or single quotes? | 23:42 |
| anteaya | backticks | 23:42 |
| clarkb | yes backticks | 23:44 |
| clarkb | anteaya: do you need a better font :) | 23:44 |
| clarkb | I will admit to using droid which has the major flaw of making 0 and O look the same | 23:45 |
| clarkb | there is a version of droid out there that fixes that | 23:45 |
| anteaya | perhaps I need a better font | 23:47 |
| anteaya | I am currently not having good luck getting my dependencies updated properly | 23:48 |
| anteaya | document isn't included in any toctree | 23:48 |
| anteaya | I'm getting tired | 23:49 |
| anteaya | I'm thinking about tossing my hands in the air and coming back tomorrow | 23:50 |
| anteaya | I don't think I'm blocking anyone | 23:50 |
| jeblair | anteaya: you add the filename to index.rst | 23:50 |
| jeblair | anteaya: and if we don't want it to show up in the main TOC, there's a way to specify that when adding it to the toctree in index.rst | 23:51 |
| jeblair | anteaya: i think system-config has an example of the latter | 23:51 |
| reed | I would like to add slides/ as output for the manual but I'm not familiar with tox | 23:52 |
| reed | does anyone have a pointer to a cheatsheet? | 23:52 |
| jeblair | reed: you want tox to run a sphinx command to build a slide deck? | 23:53 |
| reed | jeblair, yes | 23:53 |
| anteaya | jeblair: thanks, I will look at system-config's index.rst | 23:53 |
| reed | jeblair, basically add one build target to man and html we have now | 23:53 |
| jeblair | reed: look at tox.ini for the docs env; you can copy that and change the command it uses | 23:54 |
| jeblair | reed: could also add the command to the docs env so it runs both | 23:54 |
| * reed checks | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
