| === Moot2 is now known as MootBot | ||
| === salgado-afk is now known as salgado | ||
| === mrevell is now known as mrevellunch | ||
| === mrevellunch is now known as mrevell | ||
| barry | #startmeeting | 15:00 |
|---|---|---|
| MootBot | Meeting started at 09:00. The chair is barry. | 15:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:00 |
| barry | welcome everyone to this week's ameu launchpad reviewer's meeting. who's here today? | 15:00 |
| allenap | me | 15:00 |
| abentley | me | 15:00 |
| beuno | me | 15:00 |
| rockstar | me | 15:00 |
| BjornT | me | 15:00 |
| intellectronica | me | 15:00 |
| barry | cprov, danilos ping | 15:01 |
| barry | EdwinGrubbs: flacoste ping | 15:02 |
| flacoste | me | 15:02 |
| barry | salgado: ping | 15:02 |
| EdwinGrubbs | me | 15:02 |
| barry | mars: ping | 15:02 |
| sinzui | me | 15:02 |
| salgado | me! | 15:02 |
| intellectronica | mrevell: are you joining the meeting? might make sense given that you've added an agenda item | 15:03 |
| bigjools | me | 15:03 |
| mrevell | Sorry, me | 15:03 |
| adeuring | me | 15:03 |
| bigjools | cprov is in Lexington and will probably not make any meetings this week | 15:04 |
| barry | [TOPIC] * Roll call | 15:04 |
| barry | * using reST - flacoste | 15:04 |
| barry | * What support can beuno and mrevell offer during the review process? (mrevell) | 15:04 |
| barry | * If there's time, the old boring script | 15:04 |
| barry | * Next meeting | 15:04 |
| MootBot | New Topic: * Roll call | 15:04 |
| barry | * Action items | 15:04 |
| barry | * Queue status | 15:04 |
| barry | * Mentoring update | 15:04 |
| barry | er | 15:04 |
| barry | [TOPIC] agenda | 15:04 |
| MootBot | New Topic: agenda | 15:04 |
| barry | * Roll call | 15:04 |
| barry | * using reST - flacoste | 15:04 |
| barry | * What support can beuno and mrevell offer during the review process? (mrevell) | 15:04 |
| barry | * If there's time, the old boring script | 15:04 |
| barry | * Next meeting | 15:04 |
| barry | * Action items | 15:04 |
| barry | * Queue status | 15:04 |
| barry | * Mentoring update | 15:04 |
| barry | [TOPIC] * using reST - flacoste | 15:04 |
| MootBot | New Topic: * using reST - flacoste | 15:04 |
| barry | flacoste: the floor is yours | 15:04 |
| flacoste | ok | 15:04 |
| flacoste | so, like was discussed on the previous meeting where this topic was raised | 15:05 |
| danilos | me | 15:05 |
| flacoste | gary did a a little experiment showing how the documentation and doctest of launchpadlib would look like | 15:05 |
| flacoste | once post-processed by Sphinx | 15:05 |
| flacoste | and it was discussed on list | 15:05 |
| flacoste | are we ready to move forward and to change the Moin heading policy? | 15:06 |
| flacoste | so that our doctest and format is more in line with the rest of the python world | 15:06 |
| BjornT | i have one final question | 15:06 |
| flacoste | ok | 15:06 |
| * sinzui prepares script to remove the SteveA-approved headers | 15:07 | |
| BjornT | how do we intend to use the newly created ReSt documents? i mean, i can't imaging running sphinx over the existing doc/ directory to make much sense. are we going to change the way we write (how they look like and where they should be placed) as well, if we switch to ReST? | 15:07 |
| BjornT | i think we should change the structure of doc/ anyway, but that should be done before/during the switch to ReST, otherwise it doesn't make much sense | 15:08 |
| barry | BjornT: i do think we need to adjust our doctest focus and organization, but that could be a big task | 15:08 |
| barry | BjornT: agreed, though this does get us in the habit of writing rest instead | 15:08 |
| flacoste | yes, one plan is to reorganize doc | 15:09 |
| BjornT | barry: there's this risk of us only switching to rest, but not using it for anything :) | 15:09 |
| flacoste | an idea I suggested was to group tests by application area | 15:09 |
| flacoste | and then link them in doc | 15:09 |
| barry | BjornT: i really hope that isn't the case :) | 15:10 |
| BjornT | i'd like to see a plan for this. one alternative would be to require rest only for those new doctests that are intended to be processed by sphinx | 15:10 |
| flacoste | i think processing doc using sphinx isn't that crazy at first | 15:10 |
| intellectronica | i, for one, am quite comfortable reading doctests as text. it's api documentation that would benefit from formatting, imo | 15:10 |
| BjornT | barry: well, we used to use ReST in the past, but didn't do anything with it | 15:10 |
| flacoste | it would be easier to find stuff that way than by browsing the directory anyway | 15:10 |
| danilos | intellectronica: +1 | 15:10 |
| barry | flacoste: agreed | 15:11 |
| sinzui | flacoste: are you proposing that we merge the interface and doc tests for an application together? | 15:11 |
| flacoste | sinzui: i'm not sure i understand | 15:11 |
| flacoste | the question, but my gut says "not really" | 15:11 |
| sinzui | interfaces/ftests/questiontarget | 15:11 |
| flacoste | sinzui: a yes, that would makes sense | 15:12 |
| barry | BjornT: i agree w/flacoste. let's restify+sphinxify right now. we can improve the content and reorg over time | 15:12 |
| flacoste | i propose the following plan, which is cheap: | 15:12 |
| flacoste | use reST in doctests | 15:12 |
| flacoste | 2) run sinzui script to reSTify all headers | 15:12 |
| flacoste | 3) setup sphinx to generate API docs + doctests (unsorted) | 15:13 |
| flacoste | several iterations of refactor the big pile so that the generated stuff looks better organized and stuff | 15:13 |
| barry | flacoste: +1 | 15:13 |
| flacoste | btw, rs=flacoste on any landing doing 2) | 15:13 |
| intellectronica | i would start with generating api docs. i think that we'll get value immediately from doing that | 15:14 |
| * barry tells sinzui to jfdi | 15:14 | |
| BjornT | barry, flacoste: well, to summarize. i'm -1 to switch to ReST without any concrete plans. -0 if we have a plan, and we start to do something (useful) with them immediately. (i'm -0, since the cost of switching is quite high, imo) | 15:14 |
| flacoste | so far, only barry, Bjorn and me have expressed an opinion | 15:15 |
| intellectronica | i agree with BjornT here. i really don't see what's the immediate benefit, especially as far as doctests are concerned | 15:15 |
| rockstar | flacoste, jfdi I guess. I don't have any objections. | 15:15 |
| sinzui | +1 | 15:15 |
| abentley | +1 | 15:15 |
| flacoste | intellectronica: to me the most immediate benefit is convergence with the python community | 15:16 |
| bigjools | for me, I don't know what benefits ReST brings either | 15:16 |
| intellectronica | flacoste: how is that going to benefit us? | 15:16 |
| BjornT | it would also be interesting to know how many intend to read the sphinx processed doctests | 15:16 |
| * sinzui start next script to PEP-8 all methods | 15:16 | |
| BjornT | i for one wouldn't, that's why i'm a bit against it ;) | 15:16 |
| beuno | uhm, +1. It's easier to manipulate ReST | 15:16 |
| barry | let me ask a different question. what benefit is moin markup to us? | 15:16 |
| barry | especially given the meager markup we have in doctests anyway? | 15:16 |
| bigjools | that's not a good question, you need to justify ReST | 15:16 |
| flacoste | intellectronica: as we push packages to PyPI (lazr.config, launchpadlib, wadlib, etc.) | 15:17 |
| * barry pushes jml's and my branch to sinzui | 15:17 | |
| BjornT | beuno: easier than manipulating what? at the moment the only thing we use are moin headers. moin headers are easier than ReST headers :) | 15:17 |
| intellectronica | barry: it's an agreed standard of which we have many documents and which requires no special effort from us right now | 15:17 |
| BjornT | barry: what benefit is any markup? | 15:17 |
| BjornT | barry: considering that we basically don't use any today | 15:17 |
| intellectronica | flacoste: right, that's a good point. let's consider this again when we're ready to push the first package out, then | 15:18 |
| bigjools | the great thing about standards is that there's so many to choose from! | 15:18 |
| flacoste | intellectronica: we are | 15:18 |
| flacoste | lazr.config, launchpadlib, wadllib are ready to move out | 15:18 |
| barry | bigjools: haven't we done that? convergence with the rest of python. laying down consistency so that our doc reorg and produce meaningful html. | 15:18 |
| flacoste | launchpadlib and wadllib are already out (though not on PYPI) | 15:18 |
| flacoste | and lazr.config is coming out next month | 15:18 |
| flacoste | intellectronica: and remember that launchpad is going open source in less than 10 months | 15:19 |
| flacoste | so it's going to happen more and more | 15:19 |
| barry | BjornT: if we have almost no markup now, what's the objection to using almost no rest vs using almost no moin? :) | 15:19 |
| intellectronica | flacoste: maybe we can use them as a test bed, instead of taking on the mammoth task of converting the entire launchpad codebase just like that | 15:19 |
| bigjools | barry: well my point is that we don't need to justify Moin, we already use it :) | 15:19 |
| BjornT | barry: because is i said, moin headers are easier to write than rest headers :) | 15:19 |
| flacoste | intellectronica: it's not a big deal, sinzui has a script for it, and we used reST headers in the past | 15:20 |
| flacoste | so you can still find some in the tree | 15:20 |
| bigjools | from a pure human readability PoV, moin wins for me | 15:20 |
| barry | bigjools: we can have subjective differences about that :) i find rest headers much more readable | 15:20 |
| bigjools | :) | 15:21 |
| intellectronica | i think that moin is more writable. readability is not very different | 15:21 |
| abentley | bigjools: Not for me. Moin is the only place I've ever seen headlines done that way. But text docs since the 80's have used underlines for headings. | 15:21 |
| barry | abentley: exactly | 15:21 |
| * bigjools is outvoted | 15:21 | |
| barry | let's do a mootbot vote | 15:21 |
| abentley | And we are only arguing about headings because that's all we're using, right? | 15:22 |
| barry | [VOTE] +1 == switch to rest; -1 == stick with moin | 15:22 |
| MootBot | Please vote on: +1 == switch to rest; -1 == stick with moin. | 15:22 |
| MootBot | Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot | 15:22 |
| MootBot | E.g. /msg MootBot +1 #launchpad-meeting | 15:22 |
| barry | abentley: right | 15:22 |
| barry | +1 | 15:22 |
| MootBot | +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1 | 15:22 |
| bigjools | we already changed doctest markup once before, heck let's do it again | 15:22 |
| sinzui | abentley: correct | 15:22 |
| rockstar | +1 | 15:22 |
| MootBot | +1 received from rockstar. 2 for, 0 against. 0 have abstained. Count is now 2 | 15:22 |
| sinzui | +1 | 15:22 |
| MootBot | +1 received from sinzui. 3 for, 0 against. 0 have abstained. Count is now 3 | 15:22 |
| abentley | +1 | 15:22 |
| MootBot | +1 received from abentley. 4 for, 0 against. 0 have abstained. Count is now 4 | 15:22 |
| intellectronica | -1 | 15:22 |
| MootBot | -1 received from intellectronica. 4 for, 1 against. 0 have abstained. Count is now 3 | 15:22 |
| BjornT | -1 | 15:22 |
| adeuring | +0 | 15:22 |
| MootBot | -1 received from BjornT. 4 for, 2 against. 0 have abstained. Count is now 2 | 15:22 |
| MootBot | Abstention received from adeuring. 4 for, 2 against. 1 have abstained. Count is now 2 | 15:22 |
| EdwinGrubbs | +0 | 15:22 |
| MootBot | Abstention received from EdwinGrubbs. 4 for, 2 against. 2 have abstained. Count is now 2 | 15:22 |
| bigjools | -1 | 15:22 |
| MootBot | -1 received from bigjools. 4 for, 3 against. 2 have abstained. Count is now 1 | 15:22 |
| flacoste | +1 | 15:22 |
| MootBot | +1 received from flacoste. 5 for, 3 against. 2 have abstained. Count is now 2 | 15:22 |
| salgado | +0 | 15:23 |
| MootBot | Abstention received from salgado. 5 for, 3 against. 3 have abstained. Count is now 2 | 15:23 |
| barry | 5... | 15:24 |
| barry | 4... | 15:24 |
| barry | 3... | 15:24 |
| barry | 2... | 15:24 |
| barry | 1... | 15:24 |
| barry | rest wins :) | 15:24 |
| barry | flacoste: thanks | 15:24 |
| barry | [TOPIC] * What support can beuno and mrevell offer during the review process? (mrevell) | 15:25 |
| MootBot | Vote is in progress. Finishing now. | 15:25 |
| MootBot | Final result is 5 for, 3 against. 3 abstained. Total: 2 | 15:25 |
| MootBot | New Topic: * What support can beuno and mrevell offer during the review process? (mrevell) | 15:25 |
| mrevell | Hello! | 15:25 |
| mrevell | Just a simply question from me: how can beuno and I help during the review process with UI and any associated text, respectively? | 15:25 |
| intellectronica | reviewers should CC you when they receive a review where input from you would be beneficial, i think | 15:26 |
| barry | mrevell, beuno you are always welcome, nay encouraged to join our reviewers meetings (even the asiapac ones if you want to stay up late :) | 15:26 |
| abentley | mrevell: Ideally people would ping you before it got to review. | 15:26 |
| mrevell | barry: I'd be very happy to attend the meetings if I can be of use. | 15:26 |
| === salgado is now known as salgado-lunch | ||
| mrevell | abentley: Yeah, although that doesn't really happen in my case. | 15:26 |
| barry | intellectronica: you can, and i have, added beuno (but also mrevell) on a merge-proposal review | 15:26 |
| bigjools | for me, review time is a little late for discussing UI changes | 15:27 |
| mrevell | bigjools: UI, sure, but maybe not UI text/documentation/announcements, is it? | 15:27 |
| barry | bigjools: yes, note that's not the the exclusion of including mrevell and beuno in a pre-imp call | 15:27 |
| intellectronica | barry: yes, when i say CC this is really what i mean. email? that's so passe comose | 15:27 |
| * beuno will be happy to assist the meetings, I may just forget, so ping me and I'll be here :) | 15:27 | |
| rockstar | mrevell, maybe it needs to happen. | 15:27 |
| rockstar | Maybe me need to ask "Did you consult with (mrevell|beuno) on <x-feature>?" | 15:28 |
| sinzui | mrevell: Do you start documentation when a branch lands of staging? | 15:28 |
| mrevell | I'd love to take part in pre-imp calls. It's a great way for me to get a feel for what needs announcing etc. | 15:28 |
| bigjools | mrevell: +1 | 15:28 |
| barry | intellectronica: :) | 15:28 |
| beuno | I'm being included in more and more pre-imp calls, so I think that's going rather well from my perspective | 15:28 |
| intellectronica | mrevell: this sort of stuff usually doesn't make it into the codebase, but if you think that it would benefit from the same process we can do that | 15:28 |
| mrevell | sinzui: No, I usually take a look at the milestone and then talk to individual developers to work out if I need to do anything | 15:28 |
| mrevell | intellectronica: Well with the in-line help system it will increasingly affect the code base | 15:28 |
| barry | mrevell: +1 | 15:28 |
| rockstar | I think abentley is right. I think when it gets to review, we should ask whether or not the needed people were in the loop. | 15:28 |
| mrevell | rockstar: Yeah, I too like abentley's suggestion mainly because it's a way to remind people that I (and beuno) are here if you need us. | 15:29 |
| sinzui | mrevell: have you seen our cover letters for branches? they might be a better start for documentation | 15:29 |
| rockstar | mrevell, not if, WHEN. | 15:29 |
| mrevell | sinzui: I haven't. Could you point me at them? | 15:29 |
| intellectronica | rockstar: but we should try to avoid playing chinese whispers. if you think that the branch you are reviewing touches on the work of beuno or mrevell, why not just invite them to join the review? | 15:29 |
| * sinzui looks for examples | 15:30 | |
| rockstar | mrevell, beuno, both of you play a crucial role in what we're doing. I think that by the time the review starts, you should already be familiar with this. | 15:30 |
| barry | mrevell, beuno do you have preferred divisions of interest. by that i mean, what should we ask mrevell about and what should we ask beuno about? | 15:30 |
| * barry thinks he knows but would like to codify it in a wiki page | 15:30 | |
| rockstar | intellectronica, well, if they weren't involved, then yeah, bring them in. Otherwise, let them get other stuff done. | 15:30 |
| mrevell | barry: Anything text: UI instruction, in-line help ,documentation, community announcements, marketing-ish stuff, all that I consider my bag. | 15:30 |
| beuno | well, we will probably overlap in some cases. I participate in some UI text as well, so I think that for some things, either is fine | 15:31 |
| intellectronica | another thing, is the ui review training. mpt tried to initiate something like this many months ago, but we didn't really follow up on that. i think we should try to resurrect it. beuno? | 15:31 |
| intellectronica | and maybe do the same with content review training, led by mrevell | 15:32 |
| mrevell | intellectronica: I'm working on a simply UI text checklist at the moment, which might be useful. | 15:32 |
| beuno | intellectronica, I'm not 100% sure that I see that working, but I'll give it some thought | 15:33 |
| barry | mrevell, beuno thanks. i will attempt to capture this in a wiki page | 15:33 |
| mrevell | thanks barry and everyone else! | 15:33 |
| rockstar | thanks mrevell and beuno! | 15:33 |
| barry | [ACTION] barry to capture in a wiki page, getting beuno and mrevell involved in ui-related pre-imps and reviews | 15:34 |
| MootBot | ACTION received: barry to capture in a wiki page, getting beuno and mrevell involved in ui-related pre-imps and reviews | 15:34 |
| barry | mrevell: thanks! | 15:34 |
| barry | [TOPIC] anything else? | 15:34 |
| MootBot | New Topic: anything else? | 15:34 |
| barry | that's all i have on the agenda except for the boring stuff. does anybody have an issue they'd like to bring up? | 15:35 |
| barry | maybe related to using merge-proposals? | 15:35 |
| * intellectronica <3 merge proposals | 15:35 | |
| intellectronica | heh | 15:35 |
| barry | :) | 15:35 |
| * barry likes them, other than the code signing bug :) | 15:35 | |
| barry | intellectronica: what do you think so far? | 15:36 |
| intellectronica | i miss diff generation, and the email integration needs a bit of work, but other than that i found using mp intuitive and fun | 15:36 |
| flacoste | how effective is it in replacing PendingReviews? | 15:37 |
| flacoste | i haven't used that part | 15:37 |
| barry | flacoste: what's PendingReviews? <wink> | 15:37 |
| intellectronica | flacoste: very, though the ui could be improved a bit (there's a bug for that) | 15:37 |
| flacoste | seeing what needs to be done, what i need to review, etc. | 15:37 |
| flacoste | i have no idea how to find such things | 15:37 |
| flacoste | btw | 15:37 |
| beuno | so, this would be the PendingReviews page: https://code.edge.launchpad.net/launchpad/+activereviews | 15:37 |
| intellectronica | the problem with this page is that it doesn't show the reviewers | 15:38 |
| barry | there's also been talk of a person-centric dashboard | 15:38 |
| intellectronica | the one for the target branch does, but should be formatted more like this page | 15:38 |
| flacoste | yeah you don't know if it's assigned or not | 15:38 |
| flacoste | and when does it get off there? | 15:39 |
| flacoste | once the branch is merged or once the review has one approve vote? | 15:39 |
| barry | flacoste: when the branch lands i think? | 15:39 |
| beuno | flacoste, when it's marked as merged or approved | 15:39 |
| flacoste | beuno: but that's not the same | 15:39 |
| beuno | explicitly, not when voting/reviewing | 15:39 |
| beuno | flacoste, it's either of those | 15:39 |
| beuno | there's another page for approved but not merged | 15:39 |
| flacoste | a ok | 15:39 |
| flacoste | that's fine then | 15:39 |
| beuno | https://code.edge.launchpad.net/launchpad/+approvedmerges | 15:39 |
| beuno | both of those are accesible through the branch listing page, btw: https://code.edge.launchpad.net/launchpad | 15:40 |
| flacoste | and 'Needs fixing' is the equivalent of our old merge-conditional, right? | 15:40 |
| intellectronica | no, i think that's needs-reply | 15:40 |
| barry | btw, i still notice a few devs still using PendingReviews. when we do an old skool review, can we encourage them to try m-p for this or their next branch? | 15:40 |
| flacoste | intellectronica: i thought resubmit was needs-reply | 15:40 |
| intellectronica | oh, maybe | 15:41 |
| barry | needs fixing == needs-reply | 15:41 |
| bigjools | resubmit is scorched-earth I thought? | 15:41 |
| barry | we don't really have an equivalent for resubmit | 15:41 |
| flacoste | bigjools: that would be disapprove | 15:41 |
| bigjools | gah! | 15:41 |
| bigjools | this needs to be re-clarified on the ML | 15:41 |
| flacoste | iirc, needs-fixing is what bzr used for merge-conditional | 15:41 |
| beuno | yeah, "tweak" | 15:42 |
| flacoste | and resubmit is bzr needs-reply | 15:42 |
| barry | projects that don't do the wonderful pre-imps we have use resubmit. in fact, we may end up using resubmits more after we open source lp | 15:42 |
| flacoste | beuno: a tweak is different | 15:42 |
| flacoste | it's not in the list of vote | 15:42 |
| beuno | uhm | 15:42 |
| flacoste | this is so confusing... | 15:42 |
| beuno | it is | 15:42 |
| * barry looks to abentley | 15:42 | |
| beuno | we just need equivalents to what we have now | 15:42 |
| flacoste | that's why I found i always say the Launchpad status in the comments | 15:42 |
| beuno | socially decide them, move on | 15:42 |
| flacoste | so i think | 15:42 |
| flacoste | approve = merge-approved | 15:42 |
| * abentley hasn't worked on the UI in ages. | 15:42 | |
| flacoste | needs-fixing = merge-conditional | 15:42 |
| flacoste | resubmit = needs-reply | 15:43 |
| flacoste | disapprove = you're crazy go do a proper pre-impl call | 15:43 |
| beuno | flacoste, how about needs-fixing == needs reply | 15:43 |
| flacoste | beuno: then what is merge-conditional? | 15:44 |
| flacoste | there is nothing that is close | 15:44 |
| beuno | flacoste, approve + comment? | 15:44 |
| flacoste | that leaves ambiguity | 15:44 |
| EdwinGrubbs | flacoste: merge-conditional doesn't make much as a separate status since you may never go back to the mp to actually approve it. | 15:44 |
| barry | well, remember that both the review and the mp have 'approved' statuses. perhaps needs-fixing on the review + approved the m-p == merge-conditional? | 15:44 |
| flacoste | when the status is needs-fixing, you know you have something to do | 15:44 |
| flacoste | EdwinGrubbs: so? | 15:44 |
| flacoste | barry: that's also confusing | 15:45 |
| flacoste | two statuses! | 15:45 |
| barry | flacoste: i agree with that | 15:45 |
| flacoste | i didn't even think it was possible | 15:45 |
| EdwinGrubbs | flacoste: it seems strange to land a branch in a needs-fixing status. | 15:45 |
| abentley | barry: No, because a review can have many votes and only one status. | 15:45 |
| flacoste | abentley: right, it makes sense from a data modelling case | 15:46 |
| beuno | EdwinGrubbs, yeah, that was my point | 15:46 |
| flacoste | EdwinGrubbs, beuno: in that case, the split status is good | 15:46 |
| barry | abentley, flacoste agreed on both points, but from a usability pov (imho) it's still confusing | 15:46 |
| flacoste | review is needs-fixing, but the branh is approved | 15:46 |
| abentley | flacoste: Potentially means people are ignoring that reviewer. | 15:47 |
| flacoste | abentley: ? | 15:48 |
| * beuno thinks that approve + comment == merge-conditional | 15:48 | |
| beuno | which is what it is | 15:48 |
| beuno | "fix it and land it, don't come back to me" | 15:48 |
| barry | so, our merge-conditional means "i don't want to see this anymore" and includes a trust that the dev will fix the remaining issues | 15:48 |
| barry | that makes sense to be approved | 15:48 |
| abentley | flacoste: People get ignored in open source projects all the time. Perhaps in project foo, three "approve" votes override a "needs-fixing". | 15:48 |
| * barry notes that we're over time | 15:49 | |
| barry | so i think this warrants further discussion an suggest we take it to the ml | 15:49 |
| flacoste | abentley: ok, you're stil arguing why it makes sense to have two statuses! | 15:49 |
| flacoste | i ranted and I moved on :-) | 15:49 |
| flacoste | ok, do we have a consensus | 15:50 |
| beuno | so, MP +1, but need a little bit discussion on how to use them properly? | 15:50 |
| flacoste | approve + comment = merge-conditional | 15:50 |
| flacoste | needs-fixing = needs-reply | 15:50 |
| barry | beuno: yes, flacoste that would be my preference, yes | 15:50 |
| beuno | flacoste, +1 (that is actually what I meant originally, just jumbled everything) | 15:51 |
| barry | okay, thanks everybody and sorry for going over our time | 15:51 |
| barry | #endmeeting | 15:51 |
| MootBot | Meeting finished at 09:51. | 15:51 |
| abentley | flacoste: A merge proposal has 1 status and N reviews. | 15:51 |
| flacoste | abentley: one thing that might removes my confusion is how the mp status is related to the N reviews status | 15:51 |
| flacoste | abentley: i guess that it's a manual process | 15:52 |
| abentley | flacoste: In the code review system, the review outcomes and the status are not linked. This is because Mark doesn't want to impose policy. | 15:52 |
| flacoste | and that's why in the case when the actual workflow in use is 1-1, it's kind of more work | 15:52 |
| flacoste | abentley: right | 15:52 |
| flacoste | well, i understand where the decision comes from | 15:52 |
| abentley | flacoste: But note that even in LP reviews, it's not always that. | 15:52 |
| flacoste | right | 15:52 |
| flacoste | with mentoring | 15:52 |
| abentley | Or with DB patches. | 15:53 |
| barry | tho i wish projects could specify some workflow here so it could be done automatically | 15:53 |
| flacoste | how the permission on the m-p status is controlled? | 15:53 |
| beuno | flacoste, only the owner of the target branch can change it | 15:53 |
| abentley | flacoste: By manually changing the status. | 15:53 |
| flacoste | ok | 15:53 |
| abentley | flacoste: Sorry, misread. | 15:54 |
| flacoste | then I'd suggest that if the reviewer has permission to change the m-p status, they could set it at the same time than the review vote | 15:54 |
| flacoste | that makes thing a little easier | 15:54 |
| flacoste | 'Vote approve and approve the m-p' | 15:54 |
| abentley | flacoste: I can pass that on to thumper. | 15:55 |
| beuno | flacoste, that sounds good, explicitely saying that it's ready | 15:56 |
| beuno | you could approve, and say "fix this" | 15:56 |
| beuno | and the submitter can change it to approve once they actually did fix it | 15:56 |
| beuno | so ti's a way of saying everything was addressed | 15:57 |
| beuno | (I didn't mean to write in old english, just getting used to new keyboard) | 15:57 |
| bigjools | olde Englishe rockes :) | 15:58 |
| === salgado-lunch is now known as salgado | ||
| EdwinGrubbs | sinzui: ping | 17:40 |
| === salgado is now known as salgado-afk | ||
| === mthaddon_ is now known as mthaddon | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!