| *** openstack has joined #openstack-tc | 13:13 | |
| *** ChanServ sets mode: +o openstack | 13:13 | |
| *** mtreinish has joined #openstack-tc | 13:56 | |
| *** Luzi has quit IRC | 14:02 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Separate goal definition from goal selection https://review.opendev.org/667932 | 14:09 |
|---|---|---|
| *** lpetrut has quit IRC | 14:13 | |
| fungi | tc-members: the osf staff heard our feedback at the denver leadership meeting and are planning to do a spotlight piece on one of our help wanted entries in next week's foundation newsletter... now we just need to pick which one! (repeated for the benefit of people in other timezones who may not read scrollback) | 14:46 |
| fungi | dhellmann suggested we could just have a few interested tc members pick which one we'll do first, expecting that we'll cycle through them all in the coming months | 14:47 |
| fungi | maybe the folks who were most involved with the recent round of rewrites have a preference/suggestion? | 14:47 |
| fungi | i'm happy to work on the prose for the piece so that it's appropriate for the newsletter audience | 14:48 |
| dhellmann | zaneb was involved in that, and asettle-PTO (though she's out) | 14:50 |
| dhellmann | maybe lbragstad or mugsie? or jroll? | 14:50 |
| lbragstad | https://governance.openstack.org/tc/reference/help-most-needed.html | 14:51 |
| fungi | because otherwise i'll just throw a dart at my web browser | 14:51 |
| lbragstad | side note: it would be nice to get zaneb's refactor in prior to sending that out - but not sure if that will be possible by next week | 14:51 |
| lbragstad | https://review.opendev.org/#/c/657447/ | 14:51 |
| fungi | and then i'll need a new monitor :/ | 14:51 |
| dhellmann | I hear diablo_rojo_phon has a suction dart gun | 14:52 |
| fungi | dhellmann: ooh! monitor-safe darts! great idea | 14:52 |
| dhellmann | lbragstad : I think we should land that patch and address any language issues later | 14:53 |
| fungi | lbragstad: the spotlight piece will link to the help wanted list, so yeah the sooner we get it updated the better, but if it lands concurrently with the newsletter going out that's not terrible | 14:53 |
| lbragstad | dhellmann yeah - i agree | 14:54 |
| * dhellmann notes lbragstad has not voted on that patch | 14:54 | |
| fungi | looks like i owe that change another review. going over it again now | 14:54 |
| lbragstad | same | 14:54 |
| dhellmann | it looks like it may need a rebase | 14:54 |
| fungi | and it's office hour once again | 15:00 |
| jroll | sorry, a couple minutes late | 15:02 |
| jroll | oh, the pings were pre office hours heh | 15:02 |
| ttx | o/ | 15:03 |
| ttx | Had two topics... | 15:04 |
| ttx | What fungi raised already -- which help-most-needed to pitch in upcoming newsletter | 15:05 |
| jroll | fungi: I think I would have to vote designate or glance for the newsletter, they're probably the clearest for someone to dive into, and the existing contributors can help people onboard. aside from ease of jumping in I'd choose rbac just because I think it's important | 15:05 |
| evrardjp | o/ | 15:05 |
| mugsie | I would do glance for now, as we are working on something for designate at the moment | 15:06 |
| mugsie | and, honestly, glance is more foundational for openstack than designate, and they both need people | 15:07 |
| jroll | fine with me | 15:07 |
| fungi | sounds like some consensus around highlighting the glance entry then? wfm! | 15:07 |
| zaneb | do the problem is that we received two lots of feedback about the help most wanted: one was that the foundation is happy to help amplify it, and the other was that the current format of them is at best not conducive (and at worst worse than useless) at achieving our goals | 15:07 |
| fungi | yeah, the newsletter isn't going to parrot the content of the help wanted entry so much as restate/summarize it in ways appropriate for the audience of the newsletter | 15:08 |
| zaneb | leaving us with the risk that we might end up amplifying something counterproductive | 15:08 |
| zaneb | fungi: ok, that's good, but it would still be nice to be able to link to an updated one | 15:09 |
| zaneb | +1 for starting with glance btw | 15:09 |
| zaneb | here's what I'd suggest... | 15:09 |
| lbragstad | zaneb a few of us have reviewed your refactor of that list based on the PTG session we had on it | 15:09 |
| fungi | i concur, which is why i also agree we should get 657447 rebased and pushed through and then work on the remaining comments as a follow-up patch (similarly under documentation update house rules so shouldn't take long to get in) | 15:10 |
| zaneb | we treat the upcoming inclusion of a goal in the newsletter as a forcing function to get us to rewrite/reformat the text we currently have | 15:10 |
| *** jeremyfreudberg has joined #openstack-tc | 15:11 | |
| zaneb | so e.g. we've chosen to highlight glance, so we need to get the business case for glance rewritten before the deadline for the newsletter | 15:11 |
| zaneb | I didn't realise that 657447 needed rebasing until just now, but I will get that done today | 15:12 |
| lbragstad | sweet | 15:12 |
| lbragstad | zaneb once you get that rebased - i'll address asettle-PTO's comments for the RBAC initiative | 15:13 |
| lbragstad | in a follow on review | 15:13 |
| zaneb | cool cool | 15:13 |
| lbragstad | does anyone want to take a shot at the glance one? | 15:13 |
| mnaser | can i ask for tc members to have a look at https://review.opendev.org/#/c/657142/ later please? it's a bit stalled out (and not sure why stephenfin has a -w on that too) | 15:14 |
| fungi | mnaser: ahh, yeah, that one wasn't on my radar because it's marked wip. i usually take that as a sign than it's not ready to be reviewed by anyone yet unless the author explicitly requests my input on it | 15:17 |
| ttx | My second topic was re: GitHub org maintenance work | 15:18 |
| openstackgerrit | Zane Bitter proposed openstack/governance master: Convert 'Help Most Needed' to 'Upstream Investment Opportunities' https://review.opendev.org/657447 | 15:18 |
| fungi | thanks zaneb! | 15:18 |
| zaneb | there we go ^ | 15:18 |
| zaneb | it was literally just the s/openstack.org/opendev.org/ that caused the conflict <rolls eyes> | 15:18 |
| fungi | heh | 15:18 |
| ttx | zaneb: gratuitous changes can be harmful | 15:19 |
| ttx | So jroll started a thread on how much the TC wants to directly drive openstack gitHub content | 15:19 |
| ttx | I invite you to give your opinion on that :) thread or here | 15:19 |
| jroll | ++ | 15:20 |
| ttx | My working assumption was that the TC would define how we want to appear there (like.. which repo to mirror), but would not do the grunt work | 15:20 |
| jroll | I quite like the idea of the OSF managing the "presence and visibility" stuff | 15:20 |
| ttx | But if we have volunteers, I'm happy to have that off my plate :) | 15:20 |
| ttx | jroll: what I like about it is that it places GitHub where it should be: as a marketing effort | 15:21 |
| jroll | yes | 15:21 |
| openstackgerrit | Lance Bragstad proposed openstack/governance master: Address minor grammatical issues in RBAC initiative https://review.opendev.org/667959 | 15:21 |
| ttx | so we can tap into the OSF marketing team resources to help | 15:21 |
| fungi | there was an excited response from someone misunderstanding and thinking this meant we were going to start enabling github issues for openstack projects who request it | 15:21 |
| ttx | fungi: eh yes | 15:21 |
| ttx | jroll: there are still interesting choices for the TC to make... Like which repos to mirror in the org | 15:22 |
| ttx | or which to "pin" | 15:22 |
| ttx | and how exactly to phrase the redirection | 15:23 |
| jroll | I think pinning is part of the marketing effort | 15:23 |
| ttx | I was kind of hoping that we could just add the standard "mirror" message that GitHub applies to some repos | 15:23 |
| jroll | a pin just decides which show up at the top of https://github.com/openstack/ | 15:23 |
| ttx | but I learned that it's a manual thing you have to ask GitHub support to do for you | 15:23 |
| ttx | so not sure that scales really | 15:24 |
| * mnaser thinks that we decide what lives under openstack/ and then the osf can decide how it wants to market whats on github | 15:25 | |
| jroll | anyway, re: what to mirror. I want to mirror everything in opendev.org/openstack to github.com/openstack, and archive anything else on github, per the plan on the ML before | 15:25 |
| mnaser | i dont think we'll do a good job in maintaining that tbh. | 15:25 |
| evrardjp | jroll: what's the problem with that plan? | 15:27 |
| evrardjp | sorry it seems I have missed that ball | 15:27 |
| jroll | evrardjp: nothing | 15:27 |
| *** jeremyfreudberg has quit IRC | 15:28 | |
| evrardjp | I agree with that plan. It's clear. | 15:28 |
| evrardjp | what help do you need? | 15:28 |
| evrardjp | let me rephrase that -- how can I help? | 15:28 |
| jroll | evrardjp: this discussion is about the TC/OSF owning admin on the openstack github orgs | 15:28 |
| evrardjp | yup I got that part -- I am just not sure what's expected in this convo | 15:29 |
| evrardjp | agreement? | 15:29 |
| jroll | there's some questions on the ML, lemme see | 15:29 |
| jroll | this is the thread: http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007378.html | 15:30 |
| jroll | right now it seems like we're just continuing that discussion | 15:30 |
| evrardjp | yup I am on it. | 15:30 |
| evrardjp | oh ok | 15:30 |
| jroll | I'm not looking to make any decisions here, but maybe this afternoon I can collect everyone's thoughts and make a proposal | 15:31 |
| jroll | hopefully this afternoon, anyway, I'm out til tuesday otherwise | 15:31 |
| evrardjp | ok. I answered through the ml. | 15:31 |
| evrardjp | good work, and thanks for leading that | 15:31 |
| mnaser | something that i'd like to bring up is the current health state of magnum | 15:32 |
| mnaser | i have not had any luck getting things to land and as someone who's interacted with the project it seems like there is a lot of "pet versions" with all the little workarounds that users are using which arent being documented more upstream | 15:33 |
| jroll | evrardjp: no problem | 15:33 |
| mnaser | which means every single new user of magnum that comes has to go and play with all these little knobs that the deployers are using (and no one is fixing those bugs).. and getting code reviewed has been hard | 15:34 |
| mnaser | it seems like there's only 4 cores? | 15:34 |
| evrardjp | isn't that more than glance? :p | 15:34 |
| evrardjp | (joking!) | 15:35 |
| mnaser | https://review.opendev.org/#/admin/groups/473,members this is it righht now | 15:35 |
| evrardjp | what can we do about it? Try to have this in the initiatives for the new help wanted list? | 15:36 |
| mnaser | actually | 15:36 |
| mnaser | hongbin liu seems to have not made a review in 5 months | 15:36 |
| evrardjp | so that's worse than 4 | 15:36 |
| mnaser | yatin last was 3 weeks then 8 weeks ago | 15:36 |
| mnaser | then 7 months before | 15:37 |
| evrardjp | so there is a real problem there, what can we do then? Do you know ppl wanting to step up? | 15:37 |
| mnaser | i see 2 individuals doing a lot of good +1s | 15:37 |
| evrardjp | Did we contact those cores? | 15:37 |
| mnaser | and seeming to care about the projects | 15:37 |
| mnaser | i dont think we are in a place to put them there | 15:37 |
| mnaser | but i think we should at least ask. | 15:38 |
| evrardjp | what do you mean "we are in a place" ? | 15:38 |
| evrardjp | yeah if they are reviewing and interested in the project, it's the occasion for them to be core? | 15:38 |
| evrardjp | so asking existing cores what's going on would be helpful? | 15:38 |
| evrardjp | but keep in mind it's probably holidays time, so I wouldn't expect a quick answer either... | 15:38 |
| evrardjp | but at least let's open the communication? | 15:39 |
| zaneb | mnaser: are you suggesting that there are reviewers who could be made core but aren't, and that we should prod the actual cores into adding them? | 15:39 |
| mnaser | zaneb: i feel like they are reviewers who seem to be caring about the project (and i'm getting +1s on the changes from them) | 15:39 |
| mnaser | as well as they have even done things like express questions on the ML why there hasnt been a meeting for the past 2 weeks i think | 15:40 |
| zaneb | one thing I've learned working on open source is that, especially on a small project, it usually pays to add people who are interested as cores even when it feels a little to early, and there's virtually no downside | 15:42 |
| evrardjp | zaneb: totally agreed with that assessment | 15:42 |
| zaneb | as leaders in the community it seems appropriate for us to be sharing that wisdom | 15:42 |
| jroll | ++ | 15:43 |
| zaneb | while obviously not being seen to tell projects who they should and should not make core :) | 15:43 |
| evrardjp | and ppl break stuff it's normal. Ppl shouldn't feel bad about it. Else there would be no revert button on gerrit/git | 15:43 |
| mnaser | i'll formulate a short personal email to current cores, is that ok? | 15:44 |
| evrardjp | (I am usually using both messages for encouraging ppl) | 15:44 |
| evrardjp | mnaser: sounds great | 15:44 |
| zaneb | +1 | 15:44 |
| evrardjp | zaneb: nope but we can still say "Oh, did you notice that x ..." ? | 15:44 |
| evrardjp | ;) | 15:45 |
| zaneb | for sure | 15:45 |
| jroll | mnaser: thanks for doing that | 15:45 |
| evrardjp | mnaser: with your experience in the project, do you think ppl have enough resources to "onboard" | 15:45 |
| evrardjp | or is there more effort we should put in helping ppl step up? | 15:46 |
| mnaser | with 2 more cores magnum should be ok imho | 15:47 |
| *** tdasilva has joined #openstack-tc | 15:50 | |
| evrardjp | ok | 15:50 |
| evrardjp | thanks for tackling that | 15:50 |
| evrardjp | I wanted to raise another topic | 15:53 |
| evrardjp | Should we be stronger in applying tag policies, and how do the tag matter to ppl (Are ppl more likely to use a project because it's tagged stable?) | 15:54 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Separate goal definition from goal selection https://review.opendev.org/667932 | 15:55 |
| mnaser | i think the tag matters for enforcing standards (and not to people as much) | 15:55 |
| mnaser | i very much doubt our project consumers look and say "oh look this is a project tagged stable" | 15:55 |
| evrardjp | For the first part: Stronger in applying tag policies, I thought we could change the old practice (recently documented), to NOT allow reapplying for the stable tag at all. You remove it, you impact the public "image" of the project | 15:55 |
| mugsie | I know some do | 15:55 |
| evrardjp | mugsie: care to tell a little more about that? | 15:56 |
| mugsie | I have been asked before is Designate production ready, because it doesn't have the online upgrade tag | 15:56 |
| *** imdigitaljim has joined #openstack-tc | 15:56 | |
| mugsie | it was worse when the software navigator highlighted it, but I think some people still look at them | 15:56 |
| mnaser | not allowing someone to reapply is just telling anyone that wants to pick up a dying project: "you can't fix the stable releases and you have almost 6 months before you can produce a functional thing" | 15:57 |
| evrardjp | yeah ppl look at the software navigator, I have seen that a lot | 15:57 |
| mnaser | from a "someone i have to pay people" pov, i'd be like "well screw that, we'll find something else." | 15:57 |
| mnaser | and i'd be a lot of other folks who want to pick up a project that slowly fell apart want to do it so they can make it functional | 15:57 |
| mnaser | telling them "either live with the stuff you just picked up or forever be an unstable project" is harsh | 15:58 |
| zaneb | if someone wants to pick up a dying project the first thing they should do to save themselves work is EOL all of the stable branches | 15:58 |
| mnaser | remember, we have to balance between people and policy | 15:58 |
| zaneb | imho | 15:58 |
| mnaser | strict and perfect policy is great but it will probably be awful for users/contributors | 15:58 |
| mugsie | and branch an unstable/release-name if they need to backport | 15:59 |
| evrardjp | I think I linked this with mugsie's convo during PTG: It's fine to have projects dying, because ppl can create new ones, taking what's good in the existing one. But that's indeed a lot of effort, sometimes more than taking a dead project. | 15:59 |
| mnaser | can people really create new ones | 15:59 |
| mugsie | we were going to allow trove to EOL, and horde to start in the 1st DEN | 15:59 |
| persia | Depends how easy one makes it to change state. The example of immediately EOLing all stable branches when picking something up is a good one: if it's trivial to perform the EOL, one can have strict policy and a good experience using it. | 15:59 |
| mnaser | if i don't like the current architecture of $foo and start my own, can i really do that? because that would be two projects competing for the same goal | 15:59 |
| evrardjp | persia: agreed with that | 16:00 |
| zaneb | mnaser: we explicitly allow that | 16:00 |
| mugsie | I think that should be allowed - there are fundimental issues with the arch / api of some projects, and having to maintain an API is going to make any changes to them close to impossible | 16:00 |
| mnaser | so if i want to rewrite nova in golang and push that as an openstack project, it won't be rejected? :p | 16:01 |
| mugsie | and if you remove the stable API entirely, is it the same project? | 16:01 |
| mnaser | just making sure we're being honest with ourselves | 16:01 |
| evrardjp | we want to embrace innovation, not to hinder that with rules. A renewed project doesn't have to abide its old roots rules | 16:01 |
| mnaser | right but are you going to accept a fork of an old projects that aims to replace it? | 16:01 |
| *** e0ne has quit IRC | 16:02 | |
| evrardjp | yes, "x is dead, long live x!" | 16:02 |
| mugsie | I would have accepted horde | 16:02 |
| zaneb | mnaser: the only criterion is "not gratuitous" https://governance.openstack.org/tc/reference/new-projects-requirements.html | 16:02 |
| mugsie | if amrith had actually done something about it | 16:02 |
| mnaser | fair nuff | 16:02 |
| mnaser | in that case what motivation do we give those new contributors to build this thing out inside openstack | 16:02 |
| evrardjp | the thing is -- if tags matter, then it's important to keep them meaningful, while still have the opportunity for changes should someone step up | 16:03 |
| ttx | it depends a lot on where in the stack it fits. A replacement for trove not the same as a replacement for keystone | 16:03 |
| evrardjp | ttx: you mean because keystone is a base service? | 16:04 |
| mugsie | thats the hard question - how do you encourage collaboraiton, while not hampering innovaiton | 16:04 |
| mnaser | cause then its gonna be like: well im just gonna be an outlier | 16:04 |
| ttx | evrardjp: not really, it's just a lower layer than multiple things depend on | 16:04 |
| mugsie | if you know the answer, let me know, I am prettysure I can sell that for millions | 16:04 |
| mnaser | let me just fork this thing put it on github and not worry about it | 16:04 |
| ttx | same with glance vs. ec2api | 16:04 |
| mnaser | if we can't explain the value and find a way to encourage people to keep building this thing out inside openstack | 16:05 |
| mnaser | they just won't imho. | 16:05 |
| mugsie | and we had a glance "replacement" in the past | 16:05 |
| ttx | mugsie: and we ahd a hard time accepting it for that very reason | 16:05 |
| ttx | Actually I'm more concerned when a piece does not architecturally fit. | 16:06 |
| ttx | Like what the old magnum did before it was split into Zun+Magnum | 16:06 |
| mugsie | was there somethign with keystone and keystone-lite as well? I am having trouble remembering | 16:06 |
| mnaser | going back to the original discussion | 16:06 |
| mnaser | i dont think we should have an ultimatum | 16:07 |
| mnaser | "drop this tag and you will never be official openstack, ever again" | 16:07 |
| evrardjp | it's not what I said | 16:07 |
| evrardjp | drop this tag, and you'll never be able to claim it again | 16:07 |
| fungi | mugsie: very early on the original keystone was a thing some folks in rackspace had written in java i think? and keystone-lite was the python rewrite which eventually became our keystone project | 16:08 |
| mnaser | bob dropped the tag, worked on it some, made it better, bob moves on, billy comes in and billy's like hey i want to make this thing stable | 16:08 |
| mnaser | nope billy, sorry, bob dropped it and you're sol | 16:08 |
| mnaser | forever an unstable project | 16:08 |
| mugsie | ah, OK. | 16:08 |
| lbragstad | fungi ++ | 16:08 |
| zaneb | evrardjp: I'm not sure that is the right solution, for the reason that mnaser said | 16:09 |
| mugsie | mnaser: well, unstable until they have proven they have kept to the stable policy for all support branches (> 18 months) | 16:09 |
| fungi | you could also consider neutron to have been a parallel reimplementation significant pieces of nova, which coexisted for years | 16:09 |
| lbragstad | the OG keystone is essentially rackspace's public cloud identity service (the thing that keystone, the python project, was based on) | 16:09 |
| evrardjp | mnaser: in this case, creating a new stable project would go by far faster than having to wait EOL of all existing stable branches before applying. | 16:09 |
| ttx | fungi: keystone v1 was in Python, but was translated Java code with lots of Java-isms and boilerplate | 16:09 |
| fungi | ahh | 16:09 |
| zaneb | I'd prefer we say e.g. you can drop the tag but you must EOL all existing stable/branches first | 16:09 |
| evrardjp | zaneb: I agree on mnaser's example. | 16:09 |
| fungi | ttx: so python-not-python ;) | 16:09 |
| mnaser | ok but now they have to rename a whole project | 16:10 |
| ttx | class AuthenticationFactoryIdentityFactory | 16:10 |
| fungi | eww | 16:10 |
| ttx | (made it up) | 16:10 |
| fungi | i'm sure it's not far from the mark | 16:10 |
| mnaser | and cause even more confusion down the line "is it trove? is it potato? trove is not stable? potato is stable?" | 16:10 |
| evrardjp | I think with all that convo I have the impression it doesn't matter, and establishing a policy for taht seems more time consuming than bringing benefits | 16:10 |
| evrardjp | thanks for the time | 16:11 |
| mnaser | i think the *reasonable* approach is tags per branch | 16:11 |
| mnaser | from X to Y, this was not a stable project. ymmv | 16:11 |
| mnaser | from Y onwards, it is now stable | 16:11 |
| evrardjp | I have the impression no tags would be better :p | 16:11 |
| mnaser | stable can mean a lot of things, in our case, stable just means only receives security and bugfix changes | 16:12 |
| mnaser | i guess stable might imply something else like "its broken and dont use it" | 16:12 |
| zaneb | ideally we'd find a way around the technical issues with giving branches different names depending on the policies applied (stable/stein vs. unstable/stein) | 16:12 |
| fungi | i think more specifically it's "receives selective/minimal backports of important bug fixes (including those for security vulnerabilities)" | 16:13 |
| mnaser | yeah but stable generally means 'good for production use' | 16:13 |
| mnaser | but thats opening a whole another can of worms :) | 16:13 |
| fungi | we don't update willy-nilly, for example we don't even change the versions of dependencies we test against | 16:13 |
| fungi | also yes, risky to suggest the branch itself is good for production use. it's a good source of patches for production distributions | 16:14 |
| *** jpich has quit IRC | 16:20 | |
| *** whoami-rajat has quit IRC | 16:44 | |
| *** whoami-rajat has joined #openstack-tc | 17:06 | |
| *** ricolin has joined #openstack-tc | 17:12 | |
| *** diablo_rojo has joined #openstack-tc | 17:30 | |
| openstackgerrit | Graham Hayes proposed openstack/governance master: Add support for liasons to project pages https://review.opendev.org/668003 | 17:49 |
| openstackgerrit | Graham Hayes proposed openstack/governance master: Inital random assignment of liasons https://review.opendev.org/668004 | 17:49 |
| *** tdasilva has quit IRC | 17:53 | |
| *** ricolin has quit IRC | 18:09 | |
| openstackgerrit | Kendall Nelson proposed openstack/project-team-guide master: Add Project Update info to Events Section https://review.opendev.org/667709 | 18:39 |
| *** diablo_rojo has quit IRC | 18:50 | |
| *** diablo_rojo has joined #openstack-tc | 18:51 | |
| *** diablo_rojo_ has joined #openstack-tc | 18:51 | |
| *** diablo_rojo_ has quit IRC | 18:51 | |
| *** ijolliffe has quit IRC | 18:55 | |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Enable doc8 linting https://review.opendev.org/668027 | 19:13 |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Enable doc8 linting https://review.opendev.org/668027 | 19:22 |
| *** whoami-rajat has quit IRC | 19:54 | |
| *** diablo_rojo has quit IRC | 19:59 | |
| zaneb | I just want y'all to know how hard I'm working to avoid using the word "leverage" in the upstream investment opportunities | 20:38 |
| openstackgerrit | Sean McGinnis proposed openstack/governance master: Retire release-schedule-generator project https://review.opendev.org/668047 | 20:50 |
| *** diablo_rojo has joined #openstack-tc | 21:10 | |
| openstackgerrit | Zane Bitter proposed openstack/governance master: Add Glance upstream investment opportunity for 2019 https://review.opendev.org/668054 | 21:18 |
| mnaser | zaneb: synergy | 21:41 |
| *** mriedem is now known as mriedem_afk | 21:45 | |
| fungi | maybe you need to think outside the box | 21:54 |
| fungi | (that's the only way to really leverage those synergies) | 21:55 |
| dhellmann | zaneb : regarding branch names: at one point we discussed using series/foo for all of them, which would be a one-time change across all of the places that need to support branches (releases, CI, etc.). I think we just didn't have the energy to do it when it came up back then, so it was dropped. | 22:23 |
| *** tosky has quit IRC | 23:00 | |
| zaneb | fungi: that's the way to make a paradigm shift | 23:10 |
| *** tonyb has quit IRC | 23:32 | |
| *** tonyb has joined #openstack-tc | 23:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!