Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-22
14:18:24 bauzas :D
14:18:42 gibi :)
14:19:35 lyarwood sigh we need to kill mountpoint in the API
14:19:53 lyarwood now that we have attachments
14:23:32 bauzas lyarwood: feel free to triage this bug, not on my radar yet :)
14:32:07 sean-k-mooney gibi: im hoping that we wont use the mailing list to hevialy for converstaion that are not backed by a spec
14:33:17 sean-k-mooney gibi: we can do that but i think its not a great medium to have those kind of disucssions without a lot of pre work
14:33:50 sean-k-mooney that said we used to have a bot that jsut closed them so we could always just do that again :P
14:34:37 gibi sean-k-mooney: what do you suggest, how to prepare for the limited real time ptg discussion?
14:35:41 sean-k-mooney well im hoping our actul contact hours that are don vitually will not be less then we normally have in person but will just be spread over more days
14:37:06 sean-k-mooney i just think if its a spec we should keep most of the discussion in gerrit. if its a process thing i would prefer to have an etherpad for it with a summary after the ptg slot on the mailing list
14:37:52 sean-k-mooney we can certenly do some disucssion on the mailing list but i fount the plamcnet pre ptg and the nova pre ptg we did last cycle very hard to follow
14:38:21 gibi sean-k-mooney: we won
14:38:28 gibi sean-k-mooney: we won't have that much contact hours
14:38:52 gibi and it will be a lot slower discussion
14:39:02 gibi compared to a face to face discussion
14:39:33 sean-k-mooney then we may need to consider doing a midcyle or other 1:1 session around milesotone 1
14:40:06 sean-k-mooney i guess we can cross that bridge after the ptg to see if there are still things that need more dicussion that would be hard to do via gerrit or ml
14:40:18 gibi agree ^^
14:41:18 sean-k-mooney the reason i prefer etherpads for this type of disucsion by the way is just down to how mailing list thread thend to diverge and its hard to reponed quickly to indivigual quetions without having to respond ot everything
14:41:59 sean-k-mooney with etherpad we can just talk on indiviual lines and keep all the context
14:42:06 gibi sean-k-mooney: OK, so before the virtual ptg I will try to kick peole to start looking at the etherpad
14:42:45 gibi I'm fine if we do the pre-discussion in the etherpad
14:43:02 gibi what I need is to have pre-discussion somehow
14:43:10 dansmith etherpad is really terrible for discussions because it's very easy to end up with stuff that you can't attribute to the author
14:43:14 sean-k-mooney we may want to create topic etherpads linked off the main one to keep it clean
14:43:15 dansmith especially with lots of people
14:43:35 dansmith so I'm very much opposed to *directing* people to etherpad for discussions
14:43:53 sean-k-mooney dansmith: for things with a spec i think gerrit si the place to have the disccssion
14:44:05 dansmith I have a huge difficulty distinguishing the colors, even to assign unattributed text to someone that said something elsewhere
14:44:10 sean-k-mooney but do you think we should be using the mailing list for eveything else
14:44:11 gmann i think ML is better than etherpad discussion for pre-ptg.
14:44:34 dansmith agree that gerrit is the place for anything that is a spec. for non-spec, mailing list for sure
14:44:48 gibi that was my default plan ^^
14:44:49 gmann and where discussion going heavy then mark that for PTG discussion instead of overloading ML
14:44:49 dansmith etherpad also doesn't tell you what things you've read and what things are new
14:44:56 sean-k-mooney gmann: i really hated the pre-ptg ml threads we have done in the past
14:45:08 dansmith gibi: ++
14:45:19 sean-k-mooney but if that is what we are going to do i guess ill have to live with it
14:45:32 gibi sean-k-mooney: I hated that too but maybe it was not because of the ML itself but because of the amount of information I needed to process
14:45:40 sean-k-mooney can i just ask that we do not complete any topic only in the mailing list
14:46:06 gmann sean-k-mooney: i think we tried to conclude the things on ML which got too much. I think we can burn lot of light weight topic discussion there
14:46:10 dansmith how many people that hate divergent ML threads are using a mailer that doesn't actually show threads hierarchically like gmail?
14:46:11 sean-k-mooney gibi: for me its the format not the amount of info
14:46:24 gmann and if any topic is going back and forth then say 'let's discuss in ptg'
14:46:41 gibi gmann: ^^ +1
14:46:42 sean-k-mooney dansmith: i use revesr chronolgical order
14:46:48 sean-k-mooney dansmith: not threads
14:46:53 sean-k-mooney dansmith: but that is not my issue
14:46:54 dansmith mmhmm :)
14:47:36 sean-k-mooney dansmith: my issue is that i often feel like people dont see or respond to comment i make on some thread and there is no way to bring that point back into one fo the other divergent threads
14:47:49 dansmith probably because they're using gmail
14:47:56 sean-k-mooney that mainly hapens when people cut out part of the email
14:48:00 dansmith because gmail is the worst thing ever
14:48:22 dansmith non-trimming emails considered harmful
14:48:23 sean-k-mooney well i use evolution locally so i can enable thread view i jsut dont but ya that could be part of it
14:48:52 sean-k-mooney dansmith: i think there are pros can cons to trimming
14:49:18 sean-k-mooney trimming creats divergent tread if there are multipe open topics that dont reconverge
14:49:35 sean-k-mooney but it allows you to focus on that topic
14:49:57 dansmith non-trimming means people take a sub-thread and redirect it to something that was actually a different sub-thread by grabbing something someone said days ago
14:50:19 sean-k-mooney a sorry
14:50:33 sean-k-mooney i tought you ment replying with just a snippit fo the full email
14:52:14 sean-k-mooney dansmith: gibi if you have recommenation of Netiquette for how to conduct a discussion on the mailing list or tools that help that would be good to share
14:52:46 dansmith agree that gibi should try to set some ground rules and police with a big stick
14:53:10 sean-k-mooney im aware of the normal process for the mailing list but if feel that is not quite adequet for design dicussions
14:53:29 gibi I have no stick but I will try
14:55:38 gibi :)
14:59:18 elod lyarwood: thx for the review!
14:59:22 elod gibi: https://review.opendev.org/#/c/721883
14:59:33 gibi elod: ack
15:02:37 gibi elod, lyarwood: thanks! I'm +1
15:03:17 elod \o/
15:59:16 gmann nova-next failure for multi network fix is merged now, feel free to recheck if failing on your patch - https://review.opendev.org/#/c/721767/2
16:14:42 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM: Testing tempest https://review.opendev.org/722060
16:15:53 kashyap lyarwood: Thanks for taking time to give feedback! I answered your questions on the change. (The interesting LM bits are at the end. Hope that makes sense)
16:16:45 openstackgerrit Andreas Jaeger proposed openstack/nova stable/rocky: DNM: Testing tempest https://review.opendev.org/722063
16:41:50 bauzas cores, the prelude section is up for reviews https://review.opendev.org/#/c/721548/
16:41:57 bauzas reminder, we have to merge it before we cut RC1
16:47:18 openstackgerrit melanie witt proposed openstack/nova stable/stein: Add config option for neutron client retries https://review.opendev.org/722077
17:03:27 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP block_device: Rework refresh_connection_info https://review.opendev.org/720769
17:27:54 gmann gibi: stephenfin its ready with gate result too - https://review.opendev.org/#/c/720129/12
17:44:08 melwitt gmann: I think you have a small bug here?
17:44:09 melwitt https://review.opendev.org/#/c/720129/12/doc/source/configuration/policy-concepts.rst@204
17:45:24 gmann melwitt: ah, thanks. fixing
17:57:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
17:57:20 gmann melwitt: updated ^^
18:00:13 melwitt gmann: was there discussion around why this is in the "features" section rather than the "upgrade" section? https://review.opendev.org/#/c/720129/13/releasenotes/notes/bp-policy-defaults-refresh-b8e6e2d6b1a7bc21.yaml@2
18:02:21 gmann melwitt: not yet. I put it in feature as this is disabled via flags to actually not breaking upgrade. if we enable scope or remove deprecated old rules then we can add that in upgrade section. is that correct way to think of upgrade section ?
18:02:52 melwitt gmann: yeah ... this case is not so straightforward I guess. dansmith thoughts? ^
18:04:11 dansmith I don't really think that it's appropriate to call it a feature. With the exception of someone sitting around hoping we'll make our policy more granular, most people will see it as an upgrade-related piece of homework
18:04:42 dansmith upgrade items aren't necessarily things that break or need to happen during the upgrade, they're often "this thing that used to be like A is now like B"
18:05:03 melwitt yeah, my concern is that if we don't put it in the upgrade section, people won't see as clearly that they have homework to do before W
18:05:12 dansmith agree
18:05:16 gmann i see. that is good point
18:05:38 dansmith I would put something general in the prelude as a "hey ya'll, we're refactorin' this shiznat over the next few cycles, just FYI"
18:05:43 gmann should I move the complete section in upgrade or keeping scope things in feature as well ?
18:05:46 dansmith and keep the homework bits in upgrade
18:06:39 gmann dansmith: this is prelude, is it fine/enough - https://review.opendev.org/#/c/721548/6/releasenotes/notes/ussuri-prelude-4b96f1244cefcdf4.yaml@36
18:07:31 gmann I need to add the doc link there once that is ready.
18:08:14 dansmith yeah, seems probably like enough, but definitely "see $link for more details on what is changing"

Earlier   Later