Thursday, 2018-02-01

*** kumarmn has joined #openstack-tc00:04
*** hongbin has quit IRC00:12
*** kumarmn has quit IRC00:14
*** kumarmn has joined #openstack-tc00:14
*** kumarmn has quit IRC00:18
*** kumarmn has joined #openstack-tc00:18
*** kumarmn has quit IRC00:21
*** kumarmn has joined #openstack-tc00:21
*** kumarmn has quit IRC00:40
*** kumarmn has joined #openstack-tc00:41
*** kumarmn has quit IRC00:45
*** diablo_rojo has quit IRC00:56
*** diablo_rojo has joined #openstack-tc00:57
*** kumarmn has joined #openstack-tc01:12
*** kumarmn has quit IRC01:17
*** kumarmn has joined #openstack-tc01:18
*** kumarmn has quit IRC01:23
*** liujiong has joined #openstack-tc01:27
*** liujiong has quit IRC01:33
*** liujiong has joined #openstack-tc01:33
*** kumarmn has joined #openstack-tc01:39
*** gcb has joined #openstack-tc02:16
*** kumarmn has quit IRC02:48
*** kumarmn has joined #openstack-tc02:48
*** kumarmn has quit IRC02:51
*** kumarmn has joined #openstack-tc02:51
*** kumarmn has quit IRC03:02
*** kumarmn has joined #openstack-tc03:03
*** kumarmn has quit IRC03:08
*** rosmaita has quit IRC03:17
*** coolsvap has joined #openstack-tc04:07
*** harlowja has quit IRC04:12
*** harlowja has joined #openstack-tc04:41
*** harlowja has quit IRC06:12
*** purplerbot has quit IRC07:22
*** purplerbot has joined #openstack-tc07:22
*** purplerbot has quit IRC07:22
*** purplerbot has joined #openstack-tc07:23
*** purplerbot has quit IRC07:23
*** purplerbot has joined #openstack-tc07:23
*** purplerbot has quit IRC07:24
*** purplerbot has joined #openstack-tc07:24
*** purplerbot has quit IRC07:25
*** purplerbot has joined #openstack-tc07:25
*** purplerbot has quit IRC07:25
*** purplerbot has joined #openstack-tc07:25
*** purplerbot has quit IRC07:25
*** purplerbot has joined #openstack-tc07:26
*** kumarmn has joined #openstack-tc08:04
*** kumarmn has quit IRC08:08
*** jpich has joined #openstack-tc08:39
*** liujiong has quit IRC09:27
*** mtreinish_ has joined #openstack-tc11:08
*** mtreinish has quit IRC11:11
*** DuncanT has quit IRC11:11
*** ianw has quit IRC11:11
*** TheJulia has quit IRC11:11
*** ildikov has quit IRC11:11
*** mtreinish_ is now known as mtreinish11:11
*** ildikov has joined #openstack-tc11:11
*** DuncanT has joined #openstack-tc11:12
*** ianw has joined #openstack-tc11:12
*** TheJulia has joined #openstack-tc11:12
*** gcb has quit IRC11:25
*** gcb has joined #openstack-tc11:25
*** kumarmn has joined #openstack-tc12:04
*** kumarmn has quit IRC12:09
*** cdent has joined #openstack-tc12:18
*** dtantsur|afk is now known as dtantsur12:18
*** robcresswell has left #openstack-tc12:34
*** rosmaita has joined #openstack-tc13:05
*** coolsvap has quit IRC13:22
*** dklyle has quit IRC13:34
*** david-lyle has joined #openstack-tc13:34
*** david-lyle has quit IRC13:40
*** kumarmn has joined #openstack-tc14:03
*** alex_xu has quit IRC14:27
*** alex_xu has joined #openstack-tc14:30
*** mriedem is now known as mriedem_afk14:35
*** hongbin has joined #openstack-tc14:46
*** mriedem_afk is now known as mriedem14:58
cdenttc-members and the entire rest of the world, let's have office hours15:00
* smcginnis flips the sign15:00
smcginnisBack in the land of the living cdent?15:00
cdentsmcginnis: no sir, I am the undead15:00
ttxI had a few topics, to continue Tuesday's discussions15:00
ttxRe: PTG the track layout is now mostly frozen15:01
fungihowdy, y'all15:01
* EmilienM in meeting the next hour15:01
ttxWe have room for missing topics though15:02
ttxI started to track ideas15:02
fungiptl nominations are underway and going strong15:02
* fungi needs to go review a few more now15:02
ttxI did add the one idea currently under discussion on the ML15:03
ttx+ one idea that rose from a discussion between ildikov and me this morning15:03
pabelangerfungi: great to hear15:03
ttxPlease add any other idea15:03
ttxRegarding the post-lunch presentations, we have a strawman schedule for the week at
ttxMonday: Welcome to the PTG / housekeeping / set tone / situational awareness / release goals15:04
ttxThat would be done by Erin + interested TC members15:04
ttxTuesday: Infra update, including Zuulv315:04
ttxWe keep Wednesday in case we have a bright idea15:05
ttxThursday we'd do meetings outcome show and tell15:05
ttxand Friday, lightning talks for the survivors15:05
smcginnisSounds like a good logical plan.15:06
ttxAgain, just a default proposal, if there are other ideas lmk15:06
ttxQuick reminder that we are getting low on available tickets, and prices are increasing in a couple of hours15:06
ttxI think all TC members registered already15:06
smcginnisttx: Any preliminary numbers?15:06
ttxlike how many people ? We passed 300 yesterday, even capacity is around 35015:07
ttxso it will sell out15:07
smcginnisDid we sell out with past PTGs?15:07
ttxwe did have a bit more capacity in past PTGs, so not really, but close15:08
ttxwe've been pretty good at estimating the number of people so far. <fingerscrossed>15:08
ttxI'm working to get the track layout linked above on the PTG website15:09
ttxThat's all I had PTG-wise, let me know if you have questions15:09
mugsieOne topic that came up in the interop wg was the tempest test resolution, and they asked me to ping the TC aboiut getting some time to talk about it F2F15:09
mugsie (line 24)15:09
mugsieI suggested the friday 1/2 day TC slot might be useful for them15:10
fungisounds like a good idea to mwe15:11
fungito me too15:11
ttxHmm InteropWG is meeting on that same day ,so we could probably schedule a 90min block on some other day in a free reservable room15:11
mugsieunless that is planned to be the same as Denver and be a retrospective15:12
ttxThe other topic I had is.... Rocky goals!15:13
TheJuliacdent: everything is possible!15:14
cdentbut we _never_ talk about rocky goals15:14
ttxon Tuesday I expressed a soft preference for mutable-debug + mox15:14
ttxas a good mix of opsfacing/tecdebtreduction15:14
ttxmani issue with the mox one seems to be that nova might not complete it in one cycle15:15
mugsieyeah - they seem good15:15
ttxbut I think that's ok15:15
mugsiettx: we have said that is OK though, in the past15:15
smcginnisWe always have some projects that are not able to complete goals, so I don't think nova should be the deciding factor there.15:15
smcginnisAnd I would rather see _some_ work done towards getting rid of mox than having it keep out there as "something that we should do someday."15:16
TheJuliaBut it might be a useful measure of what is reasonable in the cycle15:16
jrolldo we know how many projects still use mox, just out of curiousity?15:16
mugsieI think there may be less projects than we thought for mox - designate doesn't actually have any mox, we just install it as its required by oslotest15:16
* jroll skims
smcginnisjroll: I tried to list all the ones that were directly or indirectly using it in the goal proposal.15:17
jrollsmcginnis: ah cool, I'll take a look, thanks15:17
ttxEmilienM and other tc-members: how do you want to proceed for the final step of goal selection? Gerrit doesn't lend itself too well to select a set of 2 from a set of 615:19
ttxeven condorcet is not that great since you want to judge the set, not individual merit15:19
smcginnisMaybe just reset our votes on goals to only vote for the two we each prefer?15:20
ttxfor example here mox is heavy on nova but they have the other one already covered15:20
ttxso they are a good complentary set, on paper15:21
TheJuliaI like the idea of resetting votes as long as we are all on the same page15:21
dtroyerthat works for me15:22
ttxAnother random question: is anyone interested in running the S name selection ? It's mostly about csetting the geographic rule, collecting names and checking that they match the naming rules15:23
EmilienMyeah, we can do that too15:23
ttxthen set up a Condorcet poll15:24
smcginnisttx: I'm trying to remember what we did in the past. Wiki page to collect ideas, prefiltering, then set up voting?15:24
smcginnisThen letting the lawyers take off the top 3 selections. :)15:24
ttxI'll do it if nobody picks it up / I just realized that I don't have that much time though, and it's always prio 215:24
ttxso if I do it it will probably be delayed a bit15:25
smcginnisI can probably fit it in, but am just fine if someone else wants it.15:25
ttxthe process is described at
ttxrecently updated to set a public poll, which facilitated a lot15:26
smcginnisAh, nice. I missed that it was spelled out so nicely.15:26
fungicatching back up... too many simultaneous conversations for me. on the mox goal, how many projects who think they'll be unable to complete the proposed goal within the cycle are too many? we have other notable goals we've pushed out to future cycles because we don't think enough projects would be willing/able to complete them in the upcoming cycle15:26
smcginnisSo far I've only heard a no from nova.15:27
smcginnisno va15:27
dhellmannfor the python 3 goal I think we only had one no as well and we went ahead with that one15:28
fungiso ~1 project knowing in advance they can't make it in one cycle is probably fine... ~10+ is not15:28
ttxfungi: pretty much yes15:29
dhellmannyeah, and the actual number is probably somewhere in between, depending15:29
cmurphyi think glance voiced concerns about being able to complete goals in general, but i'm not sure whether the mox goal applies to them15:29
smcginnisI don't think that one did.15:29
fungiit sounded like there were at least some deliverables for glance which used mox (or were those only indirect deps)?15:29
dhellmanncmurphy : they do use mox a little, but it looks like only 3-4 files15:29
smcginnisOh wait, I think glance_store had some mox.15:30
dhellmannyes, one set of tests for the swift storage15:30
fungiyeah, the glance deliverable itself was mox-free, but that's not all their deliverables15:30
dhellmannthe tests for glance, the service, do use mox15:30
dhellmannonly in a few places15:30
fungiahh, so a minimal amount of mox in glance, considerably more in glance_store?15:31
dhellmannother way around15:31
fungigot it15:32
dhellmannwe know we're always going to get pushback from teams on these goals because they have pressure to implement other, project-specific, work.15:33
dhellmannThe situation in nova is ongoing, and we can just allow for that.15:33
dhellmannThe situation in glance means we need to help recruit contributors to do some of the work.15:33
fungirosmaita: ^ i know you're stepping down as ptl, but jokke doesn't seem to be in here either... what's the odds glance contributors/reviewers would be able to knock that out next cycle, do you think?15:34
smcginnisEven if nova can reduce mox usage by ~10%, I would consider that a win.15:34
dhellmannsmcginnis : good point. we want at least some forward progress15:34
rosmaitafungi was in searchlight meeting, reading back now15:34
fungiit seemed like nova has been steadily reducing mox usage anyway (between attrition in old tests/not allowing it for new tests and also some direct test rewriting)15:34
dhellmannIf either team flat out refuses to participate in either goal, that is a bigger problem than if they don't complete the work.15:35
fungibut yeah, it does look like the amount of mox usage in glance and glance_store is small by comparison to nova, at least15:35
ttxIn the nova case it was more a case of "it's already WIP, and we won't finish it in 6 months"15:35
dhellmannright, I'm not that concerned that nova won't finish15:36
dhellmannbecause they're already working on it15:36
dhellmannfor glance I think we need to put a call out that help is needed15:37
dhellmannbut I don't think that's a blocker for the other teams -- part of the point of these tech-debt goals is also to help channel some of the "random patch" energy into useful areas15:37
rosmaitayes, so the problem is that we have a small crew working on glance now, and we need to do stuff that has visible impact15:37
rosmaitaeven if other people do the mox conversion, it eats reviewer bandwidth15:38
pabelangerttx: smcginnis: I can help with S naming, if you'd like15:38
rosmaitaand tbh, there's some non-visible stuff that we need to do, like refactor the policy layer15:38
ttxpabelanger: you got it15:38
smcginnispabelanger: All yours then. :)15:39
dhellmannrosmaita : it sounds like you don't consider community goals to have a visible impact15:39
ttxpabelanger: start by proposing a patch to release-naming.rst adding your name and suggestion for geographic area (I'd say Germany as a country but your call)15:39
pabelangerttx: sure15:39
ttxOnce the TC approves that you can start doing a wiki page, pushing to the list etc.15:40
rosmaitadhellmann well, the mox one, anyway15:41
ttxOh, another wild idea I got due to drinking too much rum last week -- to solve the ML disconnect/duplication issue15:41
dhellmannrosmaita : who do you need the work to be visible to?15:41
ttxbasically we have a number of technical topics that span ops+devs. openstack general ML is not so much used those days. And the -sigs list is not as attended as I hoped15:41
TheJuliarosmaita: I agree, mox has no visible operator impact unless they are operator/developers in the specific project. The visible impact that I think we need is to drive and maintain adoption.15:42
ttxCurrently people cross-post or duplicate threads, which is both non-ideal15:42
rosmaitadhellmann at least operators15:42
ttxSolution: We could try to create a virtual list that would dynamically include all -dev and all -ops subscribers.15:43
*** david-lyle has joined #openstack-tc15:43
ttxThat would let people either send to -dev (for pure dev topics), ops (for pure ops topics), or the -all list to reach both15:43
TheJuliattx: would it rewrite the headers so mail servers don't drop the messages on the floor?15:43
dhellmannrosmaita : ok. well, not all goals are going to be directly relevant to operators, beyond the fact that we can continue to maintain the project when tools we use are obsolete15:43
pabelangerttx: how much lead time should we account because opening voting window? is that something we can do before or after PTG?15:43
ttxTheJulia: there are various tricks to force mailman to behave yes15:43
dhellmannrosmaita : so we have to sell *that* rather than ensure that every goal has a shiny thing they can see15:43
TheJuliattx: because that would be my only logistical concern, having run mail servers that were mean and did things like that :)15:44
ttxpabelanger: not sure... maybe ask mordred for experience15:44
pabelangerttx: sure15:44
ttxTheJulia: I need to look deeper in the technical solution, not sure it would work -- but want to know if that remotely sounds like a good idea15:44
ttxbefore we spend more time on it15:45
TheJuliattx: it does to me15:45
ttxMailMan second name is MeanMan15:45
dhellmannttx: how big is the existing overlap in subscriptions to the two lists?15:45
rosmaitadhellmann i agree in principle (and maybe in practice, even)15:45
ttxdhellmann: not sure.15:46
dhellmannit would be interesting to see how high that overlap is15:46
ttxI can probably find out... if there is an easy way to extract the lists15:47
dhellmannwhere would the "all" messages actually go? a fake mailing list? or a new one that just has everyone subscribed?15:47
TheJuliattx: if you have backend access, you can dump it to csv and compare15:47
ttxa new one that is cron-refreshed to include both other lists subscribers15:47
ttxTheJulia: so I don't have backend access, but I know people who do.15:47
dhellmannhow is that different from, aside from the auto-subscription?15:48
TheJuliattx: this is where you get to laugh evilly :)15:48
* ttx whistles innocently and looks to his left and right15:48
* ttx spots fungi15:48
fungirosmaita: TheJulia: i think mox usage does have an operator-visible impact, just not immediately. eventually operators are going to want to be able to use python3-only deployments and we need to have well-maintained tools and tests to support that. mox is a dead-end there and mox3 is a mostly-abandoned hackaround15:49
TheJuliarosmaita: dhellmann: my perception is that it is a goal. A goal would be nice to be completed by the end of the cycle, but in my mind, it doesn't HAVE to be 100% completed for test refactoring work. I think forward progress is the key as smcginnis pointed out15:49
ttxdhellmann: arguably openstack@ is a bit dead because it has no topic15:49
ttxdhellmann: and people carefully ignore it those days15:49
fungittx: sorry, barely treading water in here but i see you're looking for mailman something something...15:49
ttxso a LOT of people are on -dev and -ops and not openstack@15:50
dhellmannI really don't want us to adopt the policy that it's OK by default for goals to not be completed. There are extenuating circumstances for nova (volume of tests) and glance (lack of core reviewers). I don't think that should cause us to change our normal stance that goals are time-boxed for a reason.15:50
ttxfungi: dhellmann had one of THOSE questions you know15:50
ttxwhich require dumps of mailman data files15:50
TheJuliadhellmann: I see your point, and I do agree that there is value in timeboxing, but perhaps  a single cycle timebox is too small then?15:51
ttx(specific question was: what's the overlap in subscription between -dev and -ops)15:51
rosmaitadhellmann agree ... otherwise they start piling up as tech debt15:51
dhellmannttx: ok. It feels like we're trying to solve a social problem with a technical answer again, so I'm interested in seeing what that overlap looks like and even what people think of merging all of the lists back into 1 again before we go build a cron-based autosubsriber15:52
dhellmannTheJulia : maybe we should pick smaller goals?15:52
dhellmannif we think most teams can complete the mox conversion in 1 cycle, and we know about 2 exceptions, we should just go ahead and document those exceptions15:52
ttxdhellmann: some people can get territorial about their ML, but I see what you mean15:52
TheJuliadhellmann: Perhaps, it is definitely less impactful in my mind than trying to migrate to storyboard from launchpad15:53
dhellmannif we think most teams cannot complete the conversion, we should redefine "done" for the goal to something we think they can complete15:53
dimslet them document before and after numbers?15:53
TheJuliadhellmann: I think that is reasonable to document exceptions and expectations that there may be a lag.15:53
dhellmannTheJulia : right, I agree. I just don't want us to say that no team is likely to finish. Because what's the point of saying "done" is something we know we can't do?15:54
TheJuliathat is also a good point and possibility15:54
dimsi kinda like that dhellmann15:55
ttxIn other words, ops are not looking forward to having their discussions drowed in the middle of heaps of dev discussions15:55
TheJuliaActually, saying 50% is the goal with the end-goal of eliminating mox usage does seem like we could see >50% since momentum once started, and the end perception could be greater15:55
dimsby inertia, some teams may end up finishing15:55
ttxwhich is why they asked for their own list in the first place15:55
dimsyep TheJulia15:56
* ttx needs to run15:56
* TheJulia feels like we are reaching reasonable compromise15:56
dhellmanndo we think 50% is too easily achievable?15:56
dhellmannwe do want these goals to push teams a bit15:57
cdentI think the point of the goals is, at least a bit, do get the teams to do the things they've been ignoring for whatever reason15:57
cdentso in a sense it is supposed to be a bit unpleasant15:58
TheJuliadhellmann: I could also see 75% as being entirely reasonable15:58
dhellmannTheJulia: if you think everyone can do 75%, then I think we should just stick with 100%. Because we won't actually be "done" at 75%, we'll have to either do another goal to finish or just hope that teams do.15:58
dhellmannwe want mox *out*, not "mostly out"15:59
dhellmannwith something like the python3 port, we had to stage it because "python 3 by default" was too big of a step16:00
TheJuliaTrue, which then takes us back to placing the goal at 100%, and documenting the likely stragglers16:00
TheJuliaand the expectation that we have upon them completing the goal "soon"16:00
smcginnisIf we can get the list of projects using mox down to 2-3 at the end of the cycle, I see that as a good thing.16:00
dhellmannso we had the previous goal, and we'll need to have another one to get to "3 by default" and then maybe another for "3 only"16:00
smcginnisThen there is more pressure for those 2-3 to catch up and finally get the work done.16:00
dhellmannsmcginnis : I agree16:00
fungittx: dhellmann: so... wrt mailman, yes i can do some quick analysis on exported subscriber lists, and there _is_ a cli which we could use to mash together subscriber lists and add/remove as necessary, would just need some scripting (and a decision that it's something we want to do). i also worry that there may be confusion around limitations like people attempting to manually subscribe to (or moreso,16:00
fungiunsubscribe from) the combined list, so would need some fairly explicit descriptive wording about how that works16:00
dhellmannfungi : yeah, managing that subscription list is going to be a bit hairy.16:01
dhellmanndo we know what the email volume on the lists look like? (messages per day or something?)16:02
dhellmannI had good luck with the docs team (much smaller, I know) moving from their special list to the -dev list16:02
dhellmannif we have some operators who don't want to do that, maybe we can set an example by saying we're closing the -dev list and moving everyone over to the main community list16:03
dhellmannand then we stop cross-posting to encourage people to subscribe to the community list16:03
fungii can also get stats on list message volumes, sure16:05
dhellmannthanks, that would help16:05
fungithe lists.o.o situation is a little more complicated now that it hosts lists for multiple domains in different "focus areas"16:08
fungiincluding now and soon lists.katacontainers.io16:08
fungiso may take me a bit of time to work out the stats16:09
dhellmannfungi : if you look at the subscriber lists, I can do the message volume16:10
dhellmannI'm on all of the lists, I just need to scan my imap folders16:10
fungidhellmann: i can get monthly message volume pretty easily from the archive directories actually16:19
fungiokay, i have monthly message volumes across the openstack, openstack-dev and openstack-operators mailing lists. just getting them into a nicer tabular format now16:27
fungithe paste command is awesome, btw16:28
fungi indicates message volume is similar between openstack and openstack-operators, but an order of magnitude higher on openstack-dev16:34
smcginnispaste command?16:35
fungithough also, january message volume is surprisingly low compared to previous years16:35
fungismcginnis: man paste (provided in the coreutils package on debian and friends)16:36
smcginnisAh, thanks fungi.16:36
fungimerges lines from multiple files interleaved and tab-separated16:36
smcginnisWas actually hoping their was a cool CLI for interacting with paste.o.o for a moment there.16:37
fungithat's called pastebinit16:37
funginote those numbers also don't account for cross-posting, so not sure what that might look like if we were to take it into account (would probably need to crunch message-id headers)16:38
* fungi needs to disappear for a quick errand before the security meeting starts, but will analyze subscribers when he returns16:38
dhellmannfungi : rough numbers like that are good enough16:43
dhellmannnow it will be interesting to see how many people are already signed up for both lists and already getting all of that volume16:46
fungiyeah, i'll have that shortly17:06
*** harlowja has joined #openstack-tc17:09
funginot sure quite how best to slice this... there are 9550 subscribers to openstack, 5396 to openstack-dev and 2541 to openstack-operators17:18
fungi674 subscribers belong to all 317:19
fungi-dev and -operators has 1110 in common17:19
fungiso 44% of openstack-operators subscribers also subscribe to openstack-dev17:19
fungi1090 (43%) of -operators subscribers also subscribe to the general openstack ml17:21
fungi1824 (34%) of -dev subscribers also subscribe to the general openstack ml17:21
fungion the -dev/-operators overlap you could also look at it as 21% of -dev subscribers also subscribe to -operators17:23
fungiif we want to broaden the dataset to additional mailing lists, lmk and i can run those numbers too17:24
dhellmannfungi : thanks, that's good17:25
dhellmannI was most interested in the crossover of -dev and -operators17:26
dhellmannsince those are the 2 we're talking about "merging" somehow17:26
dhellmann44% seems pretty high, but I wonder how many of those people are devs subscribing to operators vs. operators subscribing to dev17:26
dhellmannI guess to tell that we'd have to look at how often people post to each list17:27
fungii'd love to stop thinking that there are people who are one or the other17:27
dhellmannyes, me, too17:28
dhellmannI think that's sort of the point of figuring this out17:28
fungibut yeah, munging up post from stats gets hairy since that's historical information while subscriber lists are a point in time snapshot17:29
dhellmannI'm not sure the stats are clear enough to know how many people would be angered by just merging the lists17:30
dhellmannIt also leaves me wondering how many people will be angered by being automatically subscribed to an "-all" list, though17:30
fungiso the further back we look, the less valid this distinction becomes but the less history we include the smaller the sample size so the less accurate the model17:30
smcginnisWe could start a thread in each now and see how many object.17:30
smcginnisOr unsubscribe.17:31
dhellmannsmcginnis : yeah, we would need to work carefully on the wording17:31
fungimy biggest concern is that when operating a mailing list you really, really, really need to make sure that people who want to opt out of a specific list are able to do so. i don't want someone reporting mail from our listserv as spam because they keep getting readded to a -all list after unsubscribing from it17:31
dhellmannyeah, managing that is going to be very tricky17:32
dhellmannand I don't want us to build a lot of complicated software to do it17:32
fungiand "you have to unsubscribe from -dev or -operators or both, depending on your situation) is not really a good answer17:32
dhellmannfungi : what's the overlap between openstack and openstack-dev?17:36
dhellmannopenstack has way more subscribers17:36
dhellmannI can imagine a huge increase in volume there upsetting some people17:36
dhellmannwhich makes me think my idea of closing -dev and moving over to that list may not fly17:37
dhellmanntime for food, bbiab17:37
cdentI'm not sure I understand the problem(s) that is trying to be addressed?17:37
fungidhellmann: per above, 1824 (34%) of -dev subscribers also subscribe to the general openstack ml17:38
fungiso that's 1824/9550 or 19% of general openstack ml subscribers in -dev17:39
fungii didn't mention the proportion of general ml subscribers on -dev and -operators because the percentages are obviously fairly low17:39
smcginniscdent: I think this started from a conversation quite a while back about not having an artificial separation betwene ops and devs and the recently more common need to cross post.17:40
* cdent misses usenet17:40
smcginnisPersonally I like having two separate lists and find it easy enough to subscribe to both.17:40
fungithe seed of the discussion was the decision in the zuul community to not have (or at least not start with) separate operator/user/developer mailing lists but just announcements and general discussion17:41
smcginniscdent: Hah, need a usenet.o.o server? :)17:41
fungismcginnis: you joke, but we've (infra) discussed it heavily in the past ;)17:41
cdentnntp is the bomb diggity17:41
fungithere are gateways to do mailman<->nntp17:41
smcginnisI do joke, but also don't think it would be an entirely bad idea. :)17:41
fungithe % of people likely to actually use nntp to interact with these lists is likely miniscule (though i count myself among them)17:42
smcginnisI think there's at least 3 potential users right here. ;)17:43
*** jpich has quit IRC17:45
fungithe infra team and tc are likely going to have disproportionate numbers of people who even remember usenet as anything other than a place to download warez and get bombarded with spam17:47
smcginnisHaha, yep.17:47
cdentI broke my sysadmin baby teeth on some very large innd servers17:48
dhellmannI wrote a motif front-end for an nntp client as part of my thesis work. I can't remember which underlying terminal client I built it on now, though18:00
dhellmannbut nntp is also a technical solution to a social problem, which is that we need a place for contributors and users to talk together and pay attention to each other18:01
cdentdhellmann: thanks, that partially answers my question18:12
cdentand presumably the challenge is that not all contributors and not all users wants to see all conversations18:12
dhellmannand also that it's not always clear in advance which conversations might be of interest to both18:14
*** david-lyle has quit IRC18:16
*** openstackgerrit has quit IRC18:18
*** harlowja has quit IRC18:29
*** esberglu has joined #openstack-tc18:41
*** dtantsur is now known as dtantsur|afk18:45
*** melwitt has joined #openstack-tc18:49
*** harlowja has joined #openstack-tc19:09
*** harlowja_ has joined #openstack-tc19:11
*** harlowja has quit IRC19:14
*** david-lyle has joined #openstack-tc19:24
*** diablo_rojo has quit IRC19:24
*** diablo_rojo_ has joined #openstack-tc19:25
*** cdent has quit IRC20:04
ttxyes motivation for exploring the possibility is to avoid cross-posting and facilitate having "common" threads.20:07
fungiwell, nntp is a technical solution to a technical problem, which is that cross-posting between mailing lists is painful because it's an attempt to use them like newsgroups ;)20:08
ttxbut yes the top 3 issues are : administrative pain, force-subscribing people just so that they get the "common" messages, and removing the possibility to ignore either list20:08
fungithe lines between subscriber/non-subscriber ina newsgroup are a lot more blurry, so it's easier to have a thread exist in multiple newsgroups without generating confusion20:09
* ttx remembers deploying a complete information system in 1996 that was entirely NNTP-based. That was way before you'd have things like Sharepoint :)20:11
ttxIt was holding technical documents describing how to manufacture various pieces of glass for a given car model.20:12
fungihowever, the same blurry lines around subscription are what allowed usenet to become a cesspool of spam long before spammers found e-mail20:12
ttxYou would post with a brand.model.position hierarchy :)20:12
dhellmannttx: that actually sounds pretty clever, given a nice enough frontend20:13
ttxthat was my last internship before graduation20:14
ttxallowed to distribute documents across the various factories and all20:14
dhellmannI worked for a while at a company bought by WebMD where they re-invented NNTP.20:15
dhellmannThey didn't care very much for me pointing that out when they explained how proud they were of the features of their system.20:15
ttxAnyway, the whole thing is part of my personal objective of tearing down artificial walls between ops and devs20:16
ttxmight be a bit of a long stretch though, since Mailman amd MLs in general are not really supporting such model20:16
dhellmannyeah. I worry a bit about the complexity of any automated subscription syncing thing20:17
ttxI don't see it as a technical solution to a social problem -- I see it as removing technical obstacles that create social problems :)20:17
dhellmannI guess I can see it that way20:17
dhellmannI'm trying to think of "forcing functions" to get people to move from one mailing list to another, or to sign up for multiple lists20:18
dhellmanndo you think the existing cross-over is high enough that we could just stop cross-posting, for example?20:19
ttxit's hard to prevent people from doing so20:28
dhellmannwell, yes, but we could start encouraging people to not do it20:28
dhellmannI mean, we've spent a bunch of time encouraging people to post cross-links, so maybe that's a bad idea20:29
TheJuliafungi: re: usenet... sooooo true.20:29
* persia remembers NNTP->SMTP gateways existing, to support folk who don't want special clients (although folk not migrating get no benefits from new technical underpinnings)20:29
ttxI used to reply to every cross-post saying it's evil, but stopped doing that after I observed no improvement20:30
fungipersia: yeah, that's basically what we were talking about gluing onto mailman20:38
fungimost of the bits needed exist, just a matter of putting them together20:38
fungiand, you know, someone having time to spend on such an endeavor20:39
persiaThat last is the most precious of resources :)20:41
fungiit's a rare isotope of unobtanium21:00
*** ianychoi_ has joined #openstack-tc21:21
*** ianychoi has quit IRC21:24
*** kumarmn_ has joined #openstack-tc21:34
*** kumarmn has quit IRC21:37
*** openstackgerrit has joined #openstack-tc22:19
openstackgerritMatthew Edmonds proposed openstack/governance master: Add OpenStack-PowerVM project
*** mriedem is now known as mriedem_parent22:20
openstackgerritMatthew Edmonds proposed openstack/governance master: Add OpenStack-PowerVM project
*** hongbin has quit IRC22:23
*** kumarmn_ has quit IRC22:37
*** kumarmn has joined #openstack-tc22:55
*** kumarmn has quit IRC22:58
*** kumarmn has joined #openstack-tc22:58
*** esberglu has quit IRC23:24

Generated by 2.15.3 by Marius Gedminas - find it at!