| *** ricolin has joined #openstack-tc | 00:44 | |
| *** diablo_rojo has quit IRC | 01:03 | |
| *** spsurya has joined #openstack-tc | 01:11 | |
| *** ricolin has quit IRC | 01:20 | |
| *** edmondsw has joined #openstack-tc | 01:31 | |
| *** edmondsw has quit IRC | 01:35 | |
| *** ricolin has joined #openstack-tc | 04:03 | |
| *** ricolin has quit IRC | 04:34 | |
| *** edmondsw has joined #openstack-tc | 05:07 | |
| *** edmondsw has quit IRC | 05:12 | |
| *** spsurya has quit IRC | 05:15 | |
| *** edmondsw has joined #openstack-tc | 06:56 | |
| *** edmondsw has quit IRC | 07:00 | |
| *** dklyle has quit IRC | 07:05 | |
| *** dklyle has joined #openstack-tc | 07:05 | |
| *** persia has quit IRC | 07:36 | |
| *** persia has joined #openstack-tc | 07:36 | |
| *** diablo_rojo has joined #openstack-tc | 15:33 | |
| *** lbragstad has joined #openstack-tc | 16:11 | |
| *** mriedem has joined #openstack-tc | 16:17 | |
| *** mriedem is now known as hansmoleman | 16:36 | |
| *** EvilienM is now known as EmilienM | 16:50 | |
| mugsie | https://etherpad.openstack.org/p/stx-faq - the foundation are hosting a fork of openstack ? | 17:03 |
|---|---|---|
| fungi | a distribution | 17:03 |
| mugsie | titanium cloud has diverged from upstream | 17:04 |
| fungi | edge-focused, previously proprietary openstack distro developed inside a vendor, working to upstream as much the divergence they're carrying as quickly as they can | 17:04 |
| mugsie | (based on their own marketing) | 17:04 |
| mugsie | still, I am not sure how I feel about the foundation pushing a fork of the openstack project | 17:05 |
| fungi | yeah, i expect them to not tout that as a good thing going forward. sounds like their dev team wants that to eventually just be tools and configuration for upstream openstack | 17:05 |
| mnaser | i'd like to wait until i see code pop up | 17:06 |
| mnaser | and see how much of a fork we're talking about | 17:06 |
| mnaser | cause it's still not there yet | 17:06 |
| mugsie | Yeah, thats true | 17:06 |
| fungi | the way i see it, this is a positive development since press releases up to this point were that the linux foundation was going to be hosting this "fork" of openstack | 17:06 |
| mnaser | maybe it could be a good first step to working together with the actual upstream teams to allow for these projects to avoid having to fork things | 17:07 |
| fungi | this is what they're saying they want | 17:07 |
| mnaser | ex: <x> team learns about how stx needed to fork to do <y>, so <x> team can help drive changes to increase flexibility so that their fork becomes a "driver" or "Extension" of upstream | 17:07 |
| mnaser | it's a win for both if that's the path it goes towards | 17:07 |
| mugsie | fungi: wind river have had at least 5 years to do that | 17:08 |
| fungi | yep, but more recently efforts in that area are being pushed by dtroyer and davidlyle | 17:08 |
| mtreinish | sounds like a good thing I skipped the board meeting today... | 17:09 |
| fungi | again, if they're going to switch to working on it in the open, it seems better to me that they do it within and together with our community rather than as part of an effort at some other foundation (which judging from press releases seems to have been the plan up until less than a week ago) | 17:11 |
| smcginnis | Us hosting a fork I suppose is better than LF hosting a fork. | 17:12 |
| smcginnis | But still doesn't feel right to me | 17:12 |
| *** gcb has joined #openstack-tc | 17:12 | |
| smcginnis | I appreciate they're wanting to now work in the open, but I would have liked to see some activity earlier trying to get these downstream changes into the community. | 17:12 |
| TheJulia | There are many feelings, but it is a learning experience that we can leverage. | 17:12 |
| smcginnis | Maybe that has happened and I just haven't seen it. | 17:13 |
| smcginnis | TheJulia: That is true. | 17:13 |
| fungi | when dtroyer's not on a plane, he can probably speak authoritatively to what things they already got into our services without it being a really high-profile involvement | 17:19 |
| TheJulia | I seem to remember some patches occasionally get pushed up into some of the projects, but client demands can easily cause divergence. We should take it as a learning experience and remain positive. | 17:22 |
| mnaser | TheJulia: i agree, we have to keep users in mind and maybe this is an exercise for projects to try and learn that we need to be more flexible or people will diverge to serve their users | 17:23 |
| TheJulia | ++ | 17:23 |
| mnaser | i'm not a licensing expert, but it looks like they want to import some gplv2 and gplv3 code | 17:23 |
| mnaser | https://github.com/starlingx-staging/stx-gplv2 and https://github.com/starlingx-staging/stx-gplv3 | 17:24 |
| smcginnis | mnaser: That caught my eye too. | 17:24 |
| smcginnis | I'm trying to approach this with a positive mindset, but I also am concerned about setting this precedent. | 17:25 |
| smcginnis | I know other distros that carry downstream patches for their specific customer needs. | 17:25 |
| mnaser | smcginnis: https://github.com/starlingx-staging/stx-cinder/commit/ac9c475f6f598be8312b7480918525ac87eddf21 | 17:26 |
| mnaser | that might interest you personally and to have an overall idea at the project | 17:26 |
| smcginnis | If we have multiple ones like this that need to do this but want to be open, are we going to end up hosting multiple forks. | 17:26 |
| TheJulia | smcginnis: true, but precedent of rejecting or not encouraging convergence also has repercussions | 17:27 |
| smcginnis | I agree. It's just a concern I think we need to at least consider. | 17:28 |
| TheJulia | ++ | 17:28 |
| mugsie | my view is that (especially wind river) have had the oportunity to do this for years. | 17:28 |
| fungi | are you sure they haven't already upstreamed at least some features? | 17:30 |
| fungi | keep in mind their contributions may have been coming from intel employees | 17:30 |
| TheJulia | but the financial cost of maintaining might have finally become too much. When I was at HPE, after a particularly painful few months I went through to identify and nuke downstream patches. I can see differences starting as being minor disagreements where contributors want things in a very precise way that is just a highly opinionated $thing. | 17:30 |
| fungi | so could have looked like "intel contributions" | 17:30 |
| smcginnis | Looking at the commit mnaser pointed me at, this has never been proposed to Cinder even though I don't think it would be too contentious of a new feature to add. | 17:31 |
| smcginnis | And it would be done with microversions that wouldn't result in a divergent API experience for end users. | 17:31 |
| mnaser | smcginnis: i tihnk that's one squashed commit of all their changes on top of a branch.. some which actaully seem to be pretty useful user facing features | 17:32 |
| hansmoleman | cfriesen works at wind river and pushes up some stuff when we can, but it's not been a secret that they fork a lot of nova | 17:32 |
| hansmoleman | and then use upstream for support / Q&A | 17:32 |
| fungi | yeah, i think dtroyer would be the best person to advocate this piece, but he's in transit until later today | 17:32 |
| mnaser | but again we shouldn't "punish" them for not doing things in a way from the start... | 17:32 |
| mnaser | this could be the start of them doing things the way we do things, or we can learn things together | 17:32 |
| smcginnis | mnaser: That's my concern - they are useful user facing features that have not be proposed to the upstream community. | 17:32 |
| mnaser | this is a good first step from their side | 17:32 |
| mugsie | I just think that before we add something like this, the community voice *should* have been more prevailent | 17:32 |
| mnaser | so i hope it's a good step in a good direction | 17:33 |
| * fungi applauds mriedem's simpsonsesque altnick | 17:33 | |
| mnaser | oh | 17:33 |
| smcginnis | I'm not -1 at this point (other than a lot of things in the Cinder code I would have asked to be changed before merging) but willing to hope it's the first step in the right direction. | 17:34 |
| TheJulia | Looking at the ironic repo, I could see one of those changes being problematic for the contributors, but I also don't have context to why wind river did their changes. That would better help, and maybe this is a case by case thing | 17:34 |
| dhellmann | yeah, I imagine it will be | 17:35 |
| smcginnis | Hopefully we can either add their features upstream or find a good way to meet their user needs in a way that will fit with what's acceptable upstream. | 17:35 |
| TheJulia | Well, ironic seems minimal, still don't understand the why | 17:35 |
| TheJulia | :( | 17:35 |
| mnaser | i think this would be the same if redhat published their spec files with all the patches they carry on top of their customers | 17:36 |
| fungi | it sounds like they started off forking more aggressively than was reasonable, realized that was a poor choice and began working to upstream as much of it as they could but there was a lot to get through, and very recent events have caused them to want to finish doing that with their existing patches presented openly rather than keeping them secret while they continue finding available developer time to | 17:36 |
| fungi | submit them to the corresponding upstream repos | 17:36 |
| mnaser | but the difference is the patches are *already* applied in a sense | 17:36 |
| EmilienM | so OpenStack was forked and now it's asked to move the forked repos into OpenStack? | 17:40 |
| EmilienM | and these repos will be maintained by 2 separated teams, testing 2 separated set of CI jobs, etc etc? | 17:41 |
| * EmilienM sad face | 17:41 | |
| dtroyer | EmilienM: not quite really... | 17:41 |
| mnaser | oh yay we have dtroyer to speak about it here now :) | 17:42 |
| dtroyer | we are starting with a building shipping commercial product, with a lot of market-specific additions | 17:42 |
| dtroyer | ((on a plane, on my way to the meeting)) | 17:42 |
| dtroyer | some of the bits have been upstreamed, many have not for lots-o-reasons | 17:42 |
| EmilienM | why moving the repos to OpenStack? | 17:43 |
| TheJulia | I think, at least on a case by case basis, teams should look at these changes and see if they make sense to pull in, which ultimately makes sense. Some of the changes in cinder actually look more along the lines of hardening | 17:43 |
| dtroyer | and yes, the assessment that carrying custom code did finally catch up with them, that wasn't the driver here but is an accurate descripion | 17:43 |
| mugsie | there is API incompatibility between them - so this i going to be an interesting discussion | 17:43 |
| dtroyer | mugsie: yeah, that part pisses me off actually, and I may be the first in line to attempt to remove it | 17:44 |
| dansmith | does the request to use openstack CI infra come with money to increase quota? because it feels like we're running really thin as it is... | 17:44 |
| smcginnis | Which brings me back to the concern about having several other vendors with downstream patches potentially wanting to follow this lead as a way to get community help with their product maintenance. | 17:44 |
| dtroyer | TheJulia: we have a long list of those patches and many have actually been looked at by current open stack devs. | 17:44 |
| smcginnis | And the API incompat is almost a show stopper IMO. | 17:44 |
| dtroyer | some are ripe to be pushed, many will need work, some just are not going to go | 17:44 |
| dhellmann | maybe we should consider importing these patches as a community goal? | 17:45 |
| TheJulia | dtroyer: yeah, I've seen wind river folks pop up every so often in the past, so not surprising. | 17:45 |
| dhellmann | "let's welcome StarlingX by helping upstream their improvements" | 17:45 |
| TheJulia | dhellmann: +1 | 17:45 |
| mtreinish | dhellmann: why? how is this different then any other product team's fork? | 17:45 |
| mugsie | mtreinish: ++ | 17:45 |
| smcginnis | ++ | 17:45 |
| dhellmann | mtreinish : because they're trying to join us | 17:45 |
| EmilienM | "StarlingX" isn't the first "commercial product" which has special needs | 17:45 |
| TheJulia | Well, this goes back to each team needs to better understand | 17:45 |
| dtroyer | I'd love the help dhellmann… that is a big part of my immediate future | 17:45 |
| EmilienM | and AFIK there is no precedent in having forks of OpenStack being imported into OpenStack namespace | 17:46 |
| mnaser | dtroyer: just an fyi, repos might need a bit more scrubbing -- https://github.com/starlingx-staging/stx-utils/blob/master/README.confidentiality.txt | 17:46 |
| dhellmann | the first step is to understand exactly what differences exist | 17:46 |
| clarkb | EmilienM: we've done it before, debian packaging was effectively a fork in our hosting | 17:46 |
| EmilienM | clarkb: it wasn't a commercial product | 17:46 |
| dtroyer | EmilienM: no there isn't and I'm not going in to the whys of that here… this is an Edge focus area project that is using the infra, unlike Kata whis is doing their own thing | 17:46 |
| clarkb | EmilienM: correct but it was a fork | 17:46 |
| mugsie | clarkb: deb packaging didn't change the API | 17:46 |
| TheJulia | So each team should take time and try to understand, and kind of work from there to help them reduce their debt while reflecting where things might have not worked that caused the differences to begin with. | 17:47 |
| clarkb | mugsie: I'm not arguing the merrits or details just pointing out we have (and actually continue to) host an existing fork of openstack | 17:47 |
| dhellmann | I need to focus on the in-person meeting, but I imagine this will be a big topic for us to discuss over the near future as we learn more about it | 17:47 |
| fungi | also it's worth pointing out that the current proposal is _not_ for starlingx to become part of openstack the project, it's to upstream the divergence from upstream openstack repositories but the starlingx project is simply seeking guidance and support from the openstack foundation at this point | 17:47 |
| smcginnis | But deb packaging did not change the API and make a bunch of incompatible differences. | 17:47 |
| EmilienM | I guess my question is why do you want these forked repos part of OpenStack? | 17:47 |
| mugsie | fungi: this is problem with the foundation and the project having the same name | 17:47 |
| fungi | yup | 17:47 |
| *** edmondsw has joined #openstack-tc | 17:47 | |
| fungi | i predict the foundation may attempt to distance itself from the openstack name in time | 17:48 |
| fungi | to help avoid further confusion in that regard | 17:48 |
| smcginnis | fungi: I was half expecting that to happen today. | 17:48 |
| TheJulia | fungi: I would make the same prediction | 17:49 |
| dtroyer | so, did this and airship get brought up at the meeting already? | 17:49 |
| mnaser | dtroyer: yes | 17:49 |
| mnaser | not discussed much in person however | 17:49 |
| EmilienM | in some slides | 17:49 |
| TheJulia | airship was mentioned briefly, but not in great detail | 17:49 |
| mnaser | mostly discussed on IRC only in here and #openstack-board | 17:49 |
| dtroyer | I'll trade a nice description of how that went for as many questions as I can answer, in person, tonight... | 17:49 |
| EmilienM | dtroyer: are them related from eath other? | 17:50 |
| EmilienM | are they* | 17:50 |
| mnaser | maybe those who have specific questions answered can add them to https://etherpad.openstack.org/p/stx-faq and dtroyer could take time to draft up answers? | 17:50 |
| EmilienM | #sundaymorningtyping | 17:50 |
| dtroyer | that's for story time, but the short answer is they know each other | 17:50 |
| EmilienM | k | 17:51 |
| dtroyer | mnaser: thanks for re-posting that | 17:51 |
| EmilienM | dtroyer: is the long term goal to integrate all the features into their upstream repos and get rid of the forks? | 17:51 |
| EmilienM | if yes, why do we want to move the forks into infra? to use infra tools? (gerrit, zuul, etc) | 17:52 |
| dtroyer | EmilienM: as many as possible. you will hear people say all, bt realistically that isn't going to happen for $REASONS | 17:52 |
| *** edmondsw has quit IRC | 17:52 | |
| dtroyer | EmilienM: this is where the foundation hosts things. Kata could have done the same thing but chose to use github and slack and whatnot | 17:53 |
| dtroyer | oh, so #starlingx is a thing too, fyi | 17:53 |
| dtroyer | pretty quiet so far and not logged yet (on my list) | 17:53 |
| EmilienM | and why moving the repos? | 17:55 |
| EmilienM | err irc refresh error, sorry, I saw your answer now | 17:55 |
| smcginnis | Good to add to the question etherpad if it's not there since I'm sure these are all going to be very common questions. | 17:56 |
| fungi | yes, the foundation executives and marketing team are also going to be very eager to have answers for those sorts of questions since i'm sure they're going to need to field a lot of the same ones | 17:57 |
| dtroyer | WRS+Intel marketing types have a sheet of answers, but mostly not at this level of tech detail. | 17:59 |
| * dtroyer goes back to pushing out staging repos so zuul goes green | 18:00 | |
| EmilienM | I'm afraid to set a precedent if we warmly welcome stx. (my opinion now ->) I don't think like it's done the right way, if a product has feature it should be proposed in the open, with the community, and not proposed in a forked repo to the community | 18:01 |
| mugsie | EmilienM: ++ | 18:01 |
| EmilienM | we have been working HARD over the last years to make people work in the open | 18:01 |
| mugsie | and I really do think that this is one area or project addition, that the foundation should have discussed in advance | 18:01 |
| EmilienM | and now, we're discussing about introducing a new project that use forks of OpenStack | 18:01 |
| EmilienM | I'm probably missing context here but so far the idea sounds terrible to me. | 18:02 |
| mugsie | rather than "surprise - there is mailing lists and repos are being added" | 18:02 |
| * TheJulia is worried we're focusing far too much on an effort to reconcile debt which may have resulted as a resistance to change or an inability to cycle a patch 15-70 times | 18:02 | |
| mugsie | TheJulia: as smcginnissaid before, none of the cinder changes were pushed upstream | 18:02 |
| TheJulia | can we say that for every single line? | 18:03 |
| TheJulia | across every changeset revision ? | 18:03 |
| EmilienM | I've been in hundreds of discussions where we said people to push their stuff upstream first | 18:03 |
| fungi | mugsie: to be fair to "the foundation" they found out a couple of days ago that this team wanted to seek their guidance rather than following their previous plan to host it with a different foundation | 18:03 |
| fungi | it was going to be opened up either way | 18:03 |
| EmilienM | I've joined the TC for that reason in fact, to keep pushing this idea | 18:03 |
| EmilienM | if we go down to the path where we are ok with this model of contribution | 18:04 |
| EmilienM | ... | 18:04 |
| fungi | the other foundation was eager to host "an improved openstack" | 18:05 |
| hansmoleman | we tell windriver people to upstream stuff in nova all the time, | 18:05 |
| hansmoleman | the response is that they are dev constrained for time to do that | 18:05 |
| hansmoleman | sometimes things get pushed up, reviewed and merged, | 18:05 |
| hansmoleman | sometimes they have problems, don't move forward and are abandoned | 18:05 |
| dansmith | well, and to be fair to them and us, some of the stuff they want are things we reject as out of scope or against our other approaches | 18:05 |
| dansmith | but, that also tells you what I think about bringing in all their forked changes | 18:06 |
| dansmith | the bits they propose which are appropriate definitely get ignored as "meh, they didn't take it within two revisions so I give up" | 18:07 |
| TheJulia | Perhaps it is time to re-evaluate approaches or scope as well | 18:07 |
| TheJulia | but that is a pre-project, in-project discussion | 18:07 |
| dtroyer | EmilienM: does RDO carry _any_ patches to openstack code (asking because I actually don't know) | 18:08 |
| EmilienM | dtroyer: not AFIK, if you find one please let me know | 18:08 |
| dansmith | dtroyer: speaking from the OSP nova perspective, we aim to have zero non-bug non-backport changes | 18:08 |
| fungi | at least some distros backport patches from newer branches | 18:08 |
| dansmith | dtroyer: nothing that is a feature before it has landed upstream or will never land | 18:08 |
| EmilienM | dtroyer: and if we do, we don't fork repos, we have .patch files in the rpm repos | 18:08 |
| dtroyer | ok, I just haven't looked yet but someone asked me | 18:08 |
| EmilienM | dtroyer++ yes exactly | 18:08 |
| EmilienM | err, dansmith++ exactly | 18:09 |
| fungi | but yeah, i agree that having features which aren't upstream and api incompatibilities is way different from backporting bug fixes from newer branches that upstream didn't backport | 18:09 |
| dtroyer | EmilienM: yup, and stx has a lot of those too. they are all 'small', I'm not sure how they decided when to make a repo. | 18:11 |
| dtroyer | so question for the group, if we carried all of this debt as patch files and applied them in the build is it diffferent? | 18:11 |
| EmilienM | RDO is really about consuming upstream repos here | 18:11 |
| dansmith | dtroyer: it makes reasoning about the delta quite a bit easier | 18:11 |
| EmilienM | dtroyer: it would be better, IMHO | 18:12 |
| dtroyer | dansmith: I'll have a pile of patch files you can look through soon | 18:12 |
| dtroyer | EmilienM: is it better just because it isn't in the same form as upstream? | 18:12 |
| dansmith | dtroyer: patches against an upstream tend to be well-cultivated and rationalized, and not just a stream of fixup commits you make against your branch | 18:13 |
| dtroyer | ie, would a pre-patched tarball be the same as a repo or as individual patch files? | 18:13 |
| dansmith | dtroyer: just generating the commit delta from a fork branch is very different from cultivated deltas | 18:13 |
| dtroyer | dansmith: I understand that, it isn't the technical process that I thought was the issue | 18:14 |
| dansmith | dtroyer: that said, I'm not likely to ever look at that set of patches unless it's to try to reason about the nefarity of things going on there, because the way I evaluate changes against the projects I work in is via patches in gerrit against the upstream repo :) | 18:15 |
| dansmith | or specs for larger changes | 18:16 |
| dtroyer | dansmith: totally. these are against pike, and we have a lot of work to do to resolve 2 releases of change | 18:16 |
| dansmith | hah | 18:16 |
| * fungi is trying to figure out if the alternatives at this point (hosting the same modified openstack distro with lf, or continuing to keep it private) are options our community would have preferred | 18:18 | |
| dansmith | I think importing it into the openstack namespace implies (to may of us) some level of support for the direction at least, | 18:18 |
| dansmith | which is my reaction to it | 18:18 |
| fungi | i really want to get rid of that namespace | 18:19 |
| dansmith | I hope it's not an ultimatum sort of thing where if we don't own it, another foundation will "get" it | 18:19 |
| fungi | to the contrary, press releases made by that other foundation were already saying they were hosting it | 18:20 |
| fungi | and the devs on it seemed to prefer to seek guidance from the openstack foundation than to have it managed by lf | 18:20 |
| dansmith | being hosted by LF makes it oddly seem like a competitor, which would be unfortunate | 18:21 |
| fungi | my sentiments as well | 18:21 |
| dansmith | but it also feels like a big slap in the face to those of us working upstream to have "our" foundation bless it, when I think most of us feel like that's the wrong way to contribute | 18:21 |
| fungi | i'd rather help them fix this than to have lf talking about their improved openstack that the openstack community rejected | 18:22 |
| EmilienM | dansmith: I really feel the same thing as you described | 18:22 |
| dansmith | fungi: I guess I'm not sure why we have to choose between them going to LF and competing, or us blessing it.. if what they really want is counsel and collaboration, I would think we could do that without them needing to join one or the other | 18:23 |
| EmilienM | dtroyer: imho it would be better to have .patch files per repo and per feature/bug (no squad) | 18:23 |
| * TheJulia makes mental note to buy dtroyer a drink because this must be very stressful at the moment | 18:24 | |
| fungi | dansmith: corporate pressure on large projects like that usually is that there needs to be a foundation on hand to deal with the trademark issues | 18:24 |
| dansmith | fungi: like, meaning, I hope they're not shopping one against the other if their intentions are really noble | 18:24 |
| dansmith | fungi: well, I guess that's part of my question.. if the goal is keep the trademark and have this live on as a thing, then that really affects my feeling of what we should do with it :) | 18:24 |
| dtroyer | EmilienM: the squash is a legal requirement by the code owners, I did manage to get them to let me release a curated set of commits as docs, otherwise upstreaming is just not possible from that squash | 18:25 |
| dtroyer | those will be out later just due to time constraints | 18:25 |
| mugsie | The trademark issue is the exact problem for me - we have used the trademark program to hold distros to account, and now that is not a tool for the starlingx repos | 18:26 |
| dansmith | mugsie: exactly | 18:26 |
| dtroyer | dansmith: those choices don't get made for the reasons you and I think about unfortuantely… I hoestly do not know what went in to that decision | 18:26 |
| fungi | to reiterate, they're not proposing to have it become part of the openstack project, but yes having the openstack foundation handle their trademarks and legal needs does muddy that perception (as does our technical baggage of having "openstack" stamped all over our infrastructure, which i hope to help fix soon, some is already underway) | 18:26 |
| dansmith | dtroyer: yeah I know :) | 18:26 |
| *** mgagne has quit IRC | 18:27 | |
| *** dansmith has quit IRC | 18:27 | |
| *** mgagne has joined #openstack-tc | 18:27 | |
| dtroyer | mugsie: WRS was/is working on passing refstack, but with the api mods it is impossible… | 18:27 |
| *** mgagne is now known as Guest74322 | 18:27 | |
| *** dansmith has joined #openstack-tc | 18:28 | |
| *** dansmith is now known as Guest92049 | 18:28 | |
| fungi | mugsie: i wasn't referring to the openstack trademark, but rather distinct trademarks for the separate project | 18:30 |
| fungi | e.g., a "starlingx" wordmark and related logos | 18:31 |
| *** Guest92049 is now known as dansmith | 18:31 | |
| fungi | obviously having it claim to be openstack or use the openstack logo without meeting openstack trademark requirements would be a definite no-no | 18:32 |
| EmilienM | fungi++ thanks for explaining that, it makes more sense. | 18:37 |
| mugsie | does the LF host the Wind River linux kernel forks? | 18:38 |
| dtroyer | mugsie: no, or I should say I'm not aware of anything else from wrs hosted at LF | 18:41 |
| fungi | this has been one of my concerns... i'm mildly worried about perceptions if we host forks of ceph and qemu, but i don't know if the starlingx devs have approached those projects about hosting those | 18:41 |
| dtroyer | stx is the complete Titanium, kernel and all | 18:41 |
| EmilienM | dtroyer: you flying to YVR? hope we can discuss more in person, maybe today | 18:41 |
| dtroyer | fungi: no we haven't. the considerations are all the same | 18:41 |
| dtroyer | EmilienM: about to land, I'm headed to the board meeting | 18:42 |
| fungi | thanks dtroyer! | 18:42 |
| *** tbarron has quit IRC | 18:43 | |
| *** amotoki has quit IRC | 18:43 | |
| *** amotoki has joined #openstack-tc | 18:44 | |
| *** tbarron has joined #openstack-tc | 18:44 | |
| fungi | from an infra team perspective i don't have any significant concerns with the proposal to host these repos (though it does increase the urgency for reducing the "openstackiness" of our infrastructure). with my tc hat on, starlingx is not asking to be part of openstack itself and so wouldn't be governed by the openstack tc | 18:44 |
| dansmith | fungi: you're not worried about lack of resources? | 18:45 |
| fungi | i do think our (tc members) opinions matter because it's related to openstack, but it isn't entirely tc jurisdiction | 18:45 |
| fungi | dansmith: resource consumption will be mostly determined by the volume of contributions/change proposals their repositories get | 18:45 |
| smcginnis | fungi: Would it be possible to host these repos NOT under the openstack namespace? | 18:45 |
| dtroyer | dansmith: resources do matter, and I am concerned about that too | 18:46 |
| mugsie | fungi: as members of the foundation, our opinions matter | 18:46 |
| fungi | mugsie: i concur | 18:46 |
| dansmith | fungi: right, if it's ignored then no real change, but if not... | 18:46 |
| clarkb | reality is ~3 projects eat like 80% of our resources | 18:47 |
| mugsie | and as members of the community, who build the reputation, and the legitimacy in the open infra space, we should have a say on who we allow to share that with | 18:47 |
| fungi | smcginnis: it's possible to host them in a different git namespace on gerrit today, but we'd rather just work on getting rid of the namespacing | 18:47 |
| clarkb | everything else is an extremely long tail so I typically don't worry about new projects | 18:47 |
| clarkb | (nova neutron tripleo if you are wondering) | 18:47 |
| dansmith | clarkb: I guess it's the precedent I'm concerned about | 18:47 |
| fungi | smcginnis: and we already have solutions to put them on their own git servers, documentation site, mailing list site, et cetera with no mention of openstack | 18:47 |
| smcginnis | fungi: Seems more of a reason to not put them under the openstack namespace if we want to move things out of there anyway. | 18:47 |
| dansmith | increasing or fattening the long tail of things we give quota to which are loosely related to openstack | 18:47 |
| mnaser | dansmith: hopefully we can have multiple tenants inside zuul so specific providers can decide/agree to provide quota to the "umbrella" of projects that they'd want to give resources to | 18:48 |
| fungi | smcginnis: so the "openstack" namespace is mainly relevant to gerrit itself | 18:48 |
| fungi | (that is, if you ignore github, which we'd like to get someone else to manage so we can stop replicating everything there ourselves) | 18:49 |
| smcginnis | fungi: On a technical level. But I also think the openstack namespace for this is relevant for a mindset/perception level. | 18:49 |
| dansmith | mnaser: that'd be nice -- I can see some providers of quota not wanting to contribute to a forked ceph development, for example | 18:49 |
| fungi | smcginnis: "namespace" where, is what i wonder | 18:49 |
| mnaser | because as things continue and if OSF onboards more projects, the infra donations that are for "openstack" (the cloud software) start being used by other things under the "openstack" (the foundation) | 18:49 |
| dansmith | mnaser: yeah | 18:50 |
| dansmith | mnaser: it used to be more clear, but lately that line is getting super fuzzy :) | 18:50 |
| smcginnis | I would be slightly more inclined to be supportive of this if we arent putting it under something that makes it look like it is OpenStack. | 18:50 |
| dansmith | smcginnis: that was my point before.. there's a lot of unwritten implication behind putting it under openstack/ even if that isn't really technically important | 18:50 |
| smcginnis | PrivacyScreenStack maybe. :) | 18:50 |
| mnaser | i think if openstack "the foundation" was called something else.. we'd all be a bit happier overall | 18:50 |
| clarkb | fwiw the tc explicitly agreed to that use o fthe namespace iirc | 18:50 |
| clarkb | like I get the concern but infra implemented what the tc asked for | 18:51 |
| clarkb | its painful to change that all again at hte direction of the tc | 18:51 |
| clarkb | (granted some of that was via input from the infra team saying moving thing saround every week was painful) | 18:51 |
| fungi | smcginnis: the other big change is that most of the shared services need to be renamed to a domain which isn't openstack.org so that we don't imply things using/relying on those are part of openstack | 18:51 |
| smcginnis | I'm fine with it using resources and libs from openstack, as long as we are not implicitly conveying that it IS openstack. | 18:52 |
| clarkb | smcginnis: right there is a tc resolution that killed stackforge/ and uses openstack/ globally instead related to that | 18:52 |
| fungi | there are lots of things the infra team would like to do in the vein of de-openstacking services, but there is also only so much we can do to influence what random people might assume | 18:53 |
| smcginnis | I feel like two different things are getting lumped into one here. | 18:54 |
| smcginnis | I'm not talking about the overall removal of the openstack namespace. | 18:54 |
| smcginnis | I'm saying this particular set of repos only, just adding it under a different namespace would make a difference to a lot of people. | 18:54 |
| *** mriedem has joined #openstack-tc | 18:54 | |
| clarkb | smcginnis: right and I'm saying the existing tc resolution is to not do that | 18:55 |
| smcginnis | So removal of stackforge/ doesn't seem relevant here. | 18:55 |
| clarkb | stackforge would've been the lace we hosted this if it still existed | 18:55 |
| mugsie | clarkb: that is for the TC projects - nothign to do with the OSF | 18:55 |
| clarkb | mugsie: no... | 18:55 |
| *** hansmoleman has quit IRC | 18:55 | |
| clarkb | it literally said unofficial projects no longer go in stackforge/ they go in openstack/ | 18:55 |
| mtreinish | clarkb: I dont think there is anything in that tc resolution about adding new namespaces. IIRC its just about moving stackforge into openstack/ | 18:56 |
| smcginnis | OK... but I still don't think any of that is relevant here. | 18:56 |
| fungi | smcginnis: for what's already been done, see http://lists.zuul-ci.org/ and https://git.zuul-ci.org/ and https://zuul-ci.org/docs/ for examples of a non-openstack project avoiding making itself look like openstack but still sharing common infrastructure. kata, airship and starlingx can get similar treatment | 18:56 |
| smcginnis | fungi: ++ | 18:56 |
| fungi | and that effort is already underway in those cases | 18:56 |
| clarkb | right we'd do ^ with the gerrit (and consequently github side) still being openstack/ until we dropped the namespacing entirely | 18:57 |
| fungi | for other stuff like gerrit, where we'd probably not like to be stuck running a bunch of separate gerrits, is to move it to some neutral (non-openstack) domain name | 18:57 |
| smcginnis | clarkb: But is there a technical reason to have to do that? | 18:57 |
| clarkb | smcginnis: yes repo replication and my sanity | 18:57 |
| smcginnis | :) | 18:57 |
| clarkb | smcginnis: if we weren't consistent every project would need a config entry in gerrit to tell it where ti replicate | 18:58 |
| clarkb | nd anytime a ne wproject was added gerrit would have to be restarted | 18:58 |
| clarkb | until such a time as we can remove the namespacing entirely and use pull rather than push replication | 18:58 |
| smcginnis | OK, that's at least a technical reason. | 18:59 |
| fungi | yeah, dropping management of github replication and letting someone else take care of deciding what github orgs get which projects (even if the infra team hosts whatever daemon/process is configured to perform the shuffling) would make things saner | 18:59 |
| *** cesarlara has joined #openstack-tc | 19:00 | |
| fungi | i suppose we _could_ transfer all the openstack namespace repos on gh to a neutral org namespace and leave the openstack namespace empty there, but there's no good api to automate that in gh so the manual work to do that for ~2k repos would be monumental | 19:01 |
| mtreinish | fungi: heh, I've automated things like that using selenium to push buttons in the ui :) | 19:02 |
| clarkb | expect for the web | 19:02 |
| fungi | eww | 19:03 |
| fungi | but noted | 19:03 |
| smcginnis | fungi loves GUIs. | 19:04 |
| mtreinish | fungi: sdague actually maintains a lib for something like that for his chevy bolt, to harvest data from their terrible website: https://github.com/sdague/mychevy/blob/master/mychevy/mychevy.py | 19:05 |
| fungi | wow! | 19:05 |
| dansmith | selenium is amazing, fwiw | 19:09 |
| dansmith | I use it to automate a stupid web ui for a bunch of devices | 19:10 |
| clarkb | as far as dropping namespaces entirely goes the big need there is the replicaton tool that can pull to push rather than relying on the built in gerrit configs aiui. Then we'll need a flag day since chances are some redirects will break and things will get sad for a little while. Nothing in that task requires infra root or really any infra involvement beyond making sure openstack is replicated to where | 19:10 |
| clarkb | we want it afterwards | 19:10 |
| clarkb | I think ttx was going to work on this in his bounty of freetime? | 19:11 |
| clarkb | maybe we need to resync on that and find someone who can spend a few days getting that done and go from there? | 19:12 |
| *** lbragstad has quit IRC | 19:18 | |
| *** diablo_rojo has quit IRC | 19:27 | |
| *** cesarlara has quit IRC | 19:28 | |
| *** edmondsw has joined #openstack-tc | 19:36 | |
| *** edmondsw has quit IRC | 19:41 | |
| *** lbragstad has joined #openstack-tc | 20:28 | |
| ttx | mnaser: +1... I feel like if the Foundation was called something else, people would be a lot less concerned | 20:50 |
| ttx | also if we had completed the git namespace flattening | 20:50 |
| ttx | starlingx is not meant to be a part of openstack, it's just the start of an open collaboration on an edge-oriented / IoT-oriented distro of openstack | 20:51 |
| ttx | But being piloted under the "OpenStack foundation" you can read it as blessed by "OpenStack" | 20:52 |
| ttx | Anyway, looking forward to discussing with dtroyer how to set it up so that we encourage convergence rather than divergence | 20:53 |
| EmilienM | so it wouldn't be part of OpenStack but blessed by OpenStack? | 20:53 |
| ttx | define "OpenStack" | 20:53 |
| ttx | not a part of OpenStack the product | 20:53 |
| EmilienM | :) | 20:53 |
| ttx | suported by the OpenStack Foundation | 20:54 |
| EmilienM | I have 404 on https://github.com/starling-staging/ now, (it was working this morning) - dtroyer: did you move it? | 21:04 |
| cmurphy | even if the openstack foundation was called something different, i don't like the idea of the foundation supporting a fork of their founding project (openstack), it feels like a dismissal of their roots | 21:05 |
| mtreinish | cmurphy: ++ | 21:06 |
| smcginnis | And a dismissal of the work some have done to get features merged upstream in a community accepted way rather than just doing it on their own and getting their customers using it, then throwing it back to the community as now something that needs to be accepted or look like we don't care about these user's needs. | 21:08 |
| mugsie | EmilienM: https://github.com/starlingx-staging/ | 21:09 |
| mugsie | (the gerrit review has the wrong org) | 21:09 |
| EmilienM | ok | 21:09 |
| EmilienM | mugsie: thx :) | 21:10 |
| dtroyer | EmilienM: it was up when the wifi shutdown on the plane, I'll go look, nothing intentional | 21:17 |
| dtroyer | oh, it's starlingx-staging note the x | 21:17 |
| dansmith | ttx: an "edge oriented *distro* of openstack" is quite different from "a fork of openstack with incompatible changes...for edge" | 21:18 |
| dtroyer | mugsie: thanks, it'll be in the next rev | 21:19 |
| smcginnis | dansmith: ++ | 21:19 |
| mugsie | dansmith: ++ | 21:19 |
| dtroyer | so what process would you all suggest if you were writing the rules today? Start with a 4 year old proprietary product with users and the need for backward compatibility, then bring the good bits upstream and deal with the rest after that… | 21:20 |
| dtroyer | some folk who are not so open source conversant think this is telling us to go away | 21:20 |
| smcginnis | Yeah, I'd like to see the necessary functionality brought in to normal upstream, then the downstream figure out how to migrate their users to the "standardized" way. | 21:21 |
| dansmith | dtroyer: the need for backward compatibility for your users that you sold a fork to is the price you pay for having taken the easy early path of "meh just fork". it's going to be hard and expensive | 21:21 |
| dtroyer | smcginnis: ++ | 21:21 |
| dansmith | smcginnis: right, migration is the fork's cross to bear | 21:22 |
| smcginnis | Unless they propose the feature, we can't tell them to go away. ;) | 21:22 |
| dtroyer | dansmith: right. how do we start? given the thought that we migrate off the oddball functionality,do we have to be perfect before we come here? | 21:22 |
| dtroyer | do those comments address the concerns you raised earlier? | 21:22 |
| dansmith | dtroyer: I think the process is (1) get enough stuff into upstream that you're willing to switch (2) figure out how to switch | 21:22 |
| dtroyer | I'm trying to decide which conversation we need to have first | 21:23 |
| EmilienM | smcginnis: ++ | 21:23 |
| fungi | a big part of the question though... are they supposed to keep their modified source code secret while they work to upstream parts of it? | 21:23 |
| mugsie | they can, or not, it is up to them | 21:24 |
| smcginnis | GitHub repos are free. | 21:24 |
| dtroyer | I can point to how that worked for 4 years, not well | 21:24 |
| fungi | or just form their own foundation to take responsibility for it in the meantime? | 21:24 |
| dansmith | fungi: making it unsecret is great for sure, but needing it to be owned by OSF is a different thing | 21:24 |
| *** edmondsw has joined #openstack-tc | 21:24 | |
| fungi | smcginnis: github repos don't cover legal needs | 21:24 |
| smcginnis | Since it's currently a proprietary fork of OpenStack, what do they need for governance other than their own existing business processes? | 21:25 |
| mugsie | fungi: for a product that is moving into open source, there is no need to have a foundation | 21:25 |
| mugsie | it is still owned by wind river | 21:25 |
| fungi | they're not going to form their own foundation for it, and the responsible organizations are going to force them to put it under a foundation, so the question is whether it goes under the same foundation we're under, or another existing foundation (and which one would you suggest as more appropriate?) | 21:25 |
| dansmith | I guess the cynic in me assumes the real reason they want the foundation umbrella is for the free marketing and free instant legitimacy | 21:26 |
| dansmith | not for real legal reasons, but IANAL and IANACIO | 21:26 |
| dansmith | (thank goodness) | 21:26 |
| fungi | companies like intel are not going to be in favor of their source code not covered by a foundation | 21:26 |
| mugsie | fungi: the tooling for deployment - sure that makes sense for edge focus areas in the foundation | 21:26 |
| smcginnis | Which is fine | 21:26 |
| mugsie | forks of the code, not so much | 21:26 |
| smcginnis | And why they should propose those features upstream. | 21:26 |
| mugsie | fungi: and if they can't get the feature in upstream, deal with it like every other vendor | 21:27 |
| pabelanger | +1 | 21:27 |
| fungi | other vendors in that situation aren't trying to make their versions open | 21:28 |
| smcginnis | For me, this still comes back to setting an incredibly bad precedent. | 21:28 |
| mugsie | and the optics look *terrible* | 21:28 |
| smcginnis | If other vendors in that situation see this success for them as a way to push their downstream changes, that would be Very Bad. | 21:28 |
| dansmith | smcginnis: yeah, like big company X can force their stuff into the upstream by open-sourcing their proprietary product and making it uncomfortable for everyone until we absorb the delta | 21:28 |
| dansmith | smcginnis: exxxxxactly | 21:29 |
| mtreinish | fungi: having things be truly open and publishing a fork on github are different | 21:29 |
| *** edmondsw has quit IRC | 21:29 | |
| fungi | i still feel like their original plan to have lf host their openstack distribution was even less great | 21:29 |
| pabelanger | smcginnis: ++ | 21:29 |
| mugsie | the community couldn't do it, so we have to get Wind River to do it, and make it a separate thing from the rest of openstack | 21:29 |
| fungi | yep, separate thing from the rest of openstack is important here | 21:29 |
| mugsie | fungi: it would not look like the foundation has decided that the community can't do edge, that it has to be this group of other people | 21:30 |
| fungi | should we expect openstack contributors to be doing everything? does zuul being a separate project mean the foundation has decided the openstack community can't do ci/cd? | 21:31 |
| dansmith | fungi: no, we're not saying that everything has to be in openstack to be good | 21:32 |
| mugsie | no, but no one forked zuul, and then pushed that fork into a new project, while the original is still being developed by the original devs | 21:32 |
| dansmith | fungi: clearly that's not true, it's the approach that matters | 21:32 |
| *** lbragstad has quit IRC | 21:34 | |
| fungi | would this conversation be different if the openstack foundation had a different name? | 21:35 |
| mugsie | No, it would be less of an issue, but it is still an issue | 21:36 |
| mugsie | it would be* | 21:36 |
| mtreinish | not for me | 21:36 |
| dansmith | same | 21:36 |
| mugsie | I would think hosting a fork of your own software is not great | 21:36 |
| EmilienM | mugsie: very good point | 21:36 |
| mnaser | i like to imagine the name of the openstack foundation.. as say.. open infrastructure foundation. and then projects sit inside of it | 21:37 |
| mnaser | i don't feel as super opposed to it when it's labeled as that | 21:37 |
| dansmith | mugsie: unless you're hosting the "this is before we cleaned up our game" or "this is where we're headed" which is exactly why it's confusing here I think | 21:37 |
| mnaser | because starlingx is just a project of the "open infrastructure foundation", so is kata, so is airship, so is zuul | 21:37 |
| mugsie | dansmith: yeah - that can be normal | 21:39 |
| fungi | does, e.g., kata's choice to use github/jenkins for their code review and testing while still being managed by the same foundation make that distinction from the openstack project easier? | 21:40 |
| mugsie | fungi: and the scopes don't overlap | 21:40 |
| mugsie | one is a CRI, one is an IaaS | 21:40 |
| fungi | does airship's overlap with existing official openstack projects not pose similar concerns? | 21:41 |
| dansmith | fungi: if kata came out of some company forking an openstack component making changes and then coming _back_ to the foundation to say "we made this thing better, so now it's a new thing" such that it overlapped with the original thing instead of just collaborating, then it would be the same thing | 21:41 |
| dtroyer | so one thing LF was going to require for DCO-like reasons was to squash all of the upstream history under the new code squash. would that help in the messaging for anyone? It wouldn't look nearly as much like the upstream repo | 21:41 |
| dansmith | fungi: that there are different things with different scopes, or even some overlapping scopes, but that were built from different bones is not a problem for me | 21:41 |
| dansmith | dtroyer: it's mechanics, which isn't really relevant to the actual messaging I think | 21:42 |
| dtroyer | ok, I couldn't decide how that would come across | 21:42 |
| mugsie | dtroyer: it might depend on the commit messages :) | 21:43 |
| fungi | so if the starlingx team had written an openstack competitor to focus on edge computing use cases rather than starting from a basis of reusing (and modifying) openstack, that would have been an okay thing for the openstack foundation to manage? | 21:43 |
| mugsie | not OK, but better imho, yeah | 21:44 |
| dansmith | fungi: I think it'd be a different conversation | 21:44 |
| dtroyer | based on our history of not really liking any overlap, that would be a bigger "no"… how can you attempt to bring things together in that situation? | 21:44 |
| fungi | so we'd rather see competing but separate implementations rather than building on the source code openstack has published? | 21:45 |
| dtroyer | in this case I believe the intention of the sponsors, it is certainly my intention, is to bring everything back upsream that makes sense and is beneficial | 21:45 |
| dansmith | fungi: I think you're headed down a path of assuming or implying that we don't like competition, and that's not really it at all | 21:45 |
| dtroyer | I chose this solution, help me find the one that works here if this isn't it | 21:45 |
| fungi | i get that the way they initially built their solution on top of openstack was not a great way to go about it | 21:46 |
| dtroyer | dansmith: the TC votes over the years make that one clear | 21:46 |
| mugsie | publishing 2 OpenStack (image|orchestration|server) APIs from the same foundation is not OK | 21:46 |
| dansmith | fungi: I, at least, see this as a very dangerous way that wind river/intel would have somewhat forced our hand on things by taking the easy way out initially, and then a subsequent easy way out of making their changes our problem by heading this way | 21:46 |
| dtroyer | so what if it had been the TC's idea to "adopt" a project to bring it into the fold? would it be different if then? | 21:47 |
| smcginnis | Kind of like showing at a keynote something that you just rewrote and saying it's better than what everyone is there for. | 21:47 |
| dtroyer | dansmith: the easy way out is to not open it up, honestly. the lat 6 months have shown me that first hand | 21:47 |
| fungi | i concur, but it doesn't change my opinion on the options that i see. the alternative ways this can play out still seem worse to me | 21:47 |
| dtroyer | smcginnis: I xan neither confirm not deny my agreement on that… | 21:48 |
| smcginnis | ;) | 21:48 |
| dtroyer | it still pisses me off | 21:48 |
| dansmith | dtroyer: depends on what the desired end goal is, I was assuming the end goal is getting things upstream, not to customers | 21:48 |
| dansmith | lucky for all of you, I'm about to get on a plane with no wifi :) | 21:48 |
| dtroyer | it is both. get the code upstream, serve the community, sell to customers, all the usual stuff | 21:49 |
| dtroyer | there will be changes that can not come upstream, even if it just rbanding | 21:49 |
| dtroyer | some of them could have been better thought out, many of them were done in kilo and liberty and have not gone away yet | 21:49 |
| dtroyer | fly safe dan | 21:50 |
| fungi | see you soon dansmith! | 21:50 |
| EmilienM | I like the intent, dtroyer | 22:02 |
| EmilienM | could we add that topic on https://etherpad.openstack.org/p/YVR-TC-brainstorming maybe? | 22:03 |
| EmilienM | maybe capture a bit of what was said this week, so we have food for thoughts this week when we meet in merson | 22:03 |
| dtroyer | I'll be there either way | 22:04 |
| dtroyer | TheJulia: love the shades! | 22:04 |
| TheJulia | dtroyer: thanks, migraines are fun \o/ | 22:05 |
| dtroyer | omg, you are on the wrong side of the room for that! | 22:06 |
| TheJulia | i know :( | 22:06 |
| TheJulia | I should have moved once it started to set in, but *shrugs* | 22:06 |
| fungi | there's an open seat between anni and zaneb | 22:06 |
| TheJulia | they raised all the blinds after the session started, I guess they only wanted to cut down on sunrise/early morning light | 22:06 |
| TheJulia | I think at this point it doesn't really matter. | 22:07 |
| fungi | looks like there might be an open seat next to spotz too | 22:07 |
| fungi | ahh, well bummer about the headache | 22:07 |
| ttx | Personally I'm happy that (1) that code is open sourced, (2) that they are happy doing it on our project infra, and (3) that they want to upstream all the delta. We should facilitate that upstreaming rather than making it more difficult... | 22:23 |
| ttx | and (4) create an open collaboration on that going forward, too | 22:23 |
| fungi | i've also got a (5) that they decided openstack was a basis worth building that on rather than rewriting their edge suite from scratch | 22:24 |
| mriedem | they can easily follow the same upstream process everyone else does, by proposing their changes | 22:24 |
| fungi | and sounds like they will | 22:24 |
| mriedem | but they will not get prioritized any higher than anything else simply because they did a big code dump | 22:25 |
| fungi | i wouldn't expect their changes to be prioritized higher than anyone else's, and i hope they don't expect that either | 22:26 |
| * fungi thinks back to all our early projects (besides swift) which also started out as forks of nova | 22:27 | |
| mriedem | forks? | 22:29 |
| mriedem | cinder was nova-volume yeah? | 22:29 |
| mriedem | split out / decomp isn't the same as a fork imo | 22:29 |
| fungi | sure, functionality was able to get deleted from nova afterward | 22:29 |
| fungi | which is again not really the same at this case | 22:29 |
| fungi | er, not really the same _as_ this case | 22:30 |
| fungi | so anyway, as the openstack tc we have the opportunity to tell the openstack foundation either that we acknowledge this is a non-ideal situation but we're not opposed to them managing it, or that we're opposed to it and would rather they tell the starlingx team to go somewhere else | 22:33 |
| fungi | the whole community has the opportunity to express opinions on these sorts of choices really, though the tc can as a body draft a resolution or something if we feel strongly about it | 22:34 |
| fungi | we're not being asked to govern it, we're just being asked to coexist with it | 22:35 |
| *** lbragstad has joined #openstack-tc | 22:59 | |
| dtroyer | mriedem: we don't expect special treatment, was planning to spec/blueprint the features, and submit bugs. I couldn't do that before yesterday… | 23:01 |
| ttx | the idea is to facilitate convergence -- those patches should not get priority just because they are part of the stx delta | 23:03 |
| *** diablo_rojo has joined #openstack-tc | 23:10 | |
| *** edmondsw has joined #openstack-tc | 23:13 | |
| mriedem | dtroyer: ack | 23:13 |
| mriedem | regarding "we're not being asked to govern it, we're just being asked to coexist with it" i will need to call saul | 23:14 |
| dtroyer | sorry, I already called him, he'll have to recuse | 23:16 |
| TheJulia | heh | 23:17 |
| *** edmondsw has quit IRC | 23:17 | |
| *** diablo_rojo has quit IRC | 23:19 | |
| *** pabelanger has quit IRC | 23:38 | |
| *** pabelanger has joined #openstack-tc | 23:38 | |
| *** gcb has quit IRC | 23:46 | |
| *** lbragstad has quit IRC | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!