| *** odyssey4me is now known as Guest822 | 00:38 | |
| *** tobias-urdin5 is now known as tobias-urdin | 02:09 | |
| *** odyssey4me is now known as Guest925 | 09:22 | |
| fungi | out of curiosity, has anyone proposed making fwaas a separate project in openstack, rather than forcing it to be revived outside openstack? seems like it's in scope, is an existing (if deprecated) deliverable of an existing team, and has fresh volunteers to get it back in shape | 17:03 |
|---|---|---|
| gmann | fungi: yes, that has been discussed in neutron team. continuing in neutron stadium (separate project not needed as such if it cannot be continue in neutron stadium) | 17:06 |
| fungi | i meant, since the neutron team seems to no longer want it as part of the neutron statement, just making a new official fwaas project team in openstack | 17:09 |
| fungi | s/statement/stadium/ | 17:09 |
| gmann | discussion in neutron team meeting was that inspur can continue it in x/ namespace and later if it become active or so then neutron team is good to accept it as neutron stadium project. https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-01-14-14.01.log.html#l-49 | 17:14 |
| gmann | let's wait for that and if neutron team does not accept it for any reason and neutron-fwaas want to add as separate project then we can discuss the possibility | 17:15 |
| fungi | it would probably be good to talk through what that workflow would be like, in that case. it seems like we're adding/retiring/restoring multiple projects solely on the appearance of whether it's "in the stadium" | 17:16 |
| gmann | yeah because of maintainers. they goes and come again | 17:16 |
| gmann | tap-as-a-service was another example | 17:17 |
| fungi | however, the churn makes extra work for other people uninvolved in that | 17:17 |
| fungi | it would be far less work for governance, code hosting, and the new volunteers if they just contributed directly to the existing repository | 17:18 |
| gmann | agree. hope new maintainer get in touch at the right time when old maintainer disappear and we deprecate/retire the things | 17:18 |
| fungi | temporarily spinning it out into a new project team so that the neutron team doesn't have to claim responsibility for it would address most of that | 17:19 |
| fungi | without needing to retire the old repo, create a new one, et cetera | 17:20 |
| fungi | and then later if neutron wants to absorb it again and the new maintainers agree, the team could just be folded back in (like placement and nova) | 17:20 |
| gmann | well, creating new project and then folding seems unnecessary process and lot of work as separate team. I will say two option could be good 1. continue in neutron stadium itself 2. current agreed way, do it in x/ and then neutron team discuss about adding it back in stadium. | 17:23 |
| fungi | or if the new maintainers decide it's not worth the effort any longer, then openstack can still proceed with retiring it at that point | 17:23 |
| clarkb | 2) is a lot of work for fungi and I | 17:23 |
| clarkb | beacuse we have to figure out what to do with all these redundant repos | 17:23 |
| gmann | deliverable in neutron stadium is no different than new project in openstack | 17:23 |
| clarkb | and force pushing updates and so on | 17:24 |
| fungi | well, for project-config reviewers, but also for the people proposing the changes to project-config, and hassle for the new volunteers who would like to focus on getting the software back into a maintained shape | 17:24 |
| gmann | sure, but that is what neutron team discussed, If I am right they want to check activeness or how it goes before they consider it in neutron stadium. or may be other reason which is good to know from them. | 17:25 |
| fungi | deliverable in neutron stadium is different from a new project in openstack insofar as the tc can agree to take responsibility for nurturing its resurrection rather than the neutron team having to take responsibility for it (as they seem to not want to do) | 17:25 |
| gmann | slaweq: may know | 17:25 |
| fungi | if there are ways to "check activeness" without kicking it out of openstack, that would be a win for everyone involved | 17:26 |
| gmann | it is lot more as separate project, election, releases, QA, meeting etc. in neutron stadium all these are combined | 17:26 |
| gmann | I am not against of continue in neutron stadium which is what i thought of but its neutron team discussed and inspur agree on that. it is ok if they want to reconsider that | 17:27 |
| fungi | it's already being released so that would continue, meetings are optional anyway, dpl eliminates the need for a ptl election... | 17:27 |
| fungi | it just seems like a lot of hassle for everyone involved if we're moving the project out of openstack with the expectation that we'll be putting it right back again making that entire dance unnecessary for the sake of what the repository name appears to be | 17:28 |
| gmann | adding right back is also not known but that is possible as discussed in neutron meeting | 17:29 |
| fungi | what this decision implies is that nobody except the new volunteers believes they'll be able to do it, and we'd rather just be rid of the whole thing | 17:29 |
| fungi | which is not a particularly welcoming attitude, even if it's only an impression | 17:29 |
| fungi | (but it certainly does seem to me like it's a way of being able to tell them that we don't expect to ever reintroduce fwaas as an official part of openstack and want to avoid telling them so) | 17:31 |
| gmann | I do not want to interprete the decision until neutron team can explain it in detail. But if you think project renaming is difficult things due to resources then we can discuss that as separate things to solve in TC/board level. | 17:34 |
| gmann | hopefully we could get more people to help you guys there like ELK services. | 17:34 |
| fungi | when we split all the non-openstack repos out of the openstack namespace, it was with the expectation there would be some additional churn from projects growing outside openstack and then becoming an official part of it, or from projects forking out of openstack to continue maintenance in a separate namespace, but removing a project when there's some clear evidence it's being worked on by | 17:35 |
| fungi | people who want to get it back in shape is creating unnecessary work for others | 17:35 |
| fungi | that's my primary concern | 17:35 |
| gmann | sure, and I agree on that. let's wait for neutron team to explain the detail about deciding it for x/ I am sure there is some valid reason there too as per their experience with other deliverables of neutron stadium | 17:37 |
| gmann | fungi: would you like to put it on current ML thread or we can add it in TC agenda too and invite neutron folks on Thursday | 17:38 |
| fungi | basically, there is a hidden cost (to people outside the neutron team) in their decision to move a project out of openstack only to put it back again later | 17:38 |
| fungi | sent | 18:05 |
| gmann | thanks | 18:09 |
| slaweq | gmann: fungi what should I know? | 19:36 |
| slaweq | how I can help You? | 19:36 |
| fungi | slaweq: i was proposing alternatives for keeping neutron-fwaas in the openstack namespace while still satisfying the neutron team's need to declaim responsibility for it | 19:37 |
| slaweq | fungi: we basically didn't want to do that right now as we are not really sure how much the Inspur team will really want to maintain it | 19:38 |
| fungi | the added churn of taking the repo out of the namespace and putting it back in again, both in terms of changes in the infrastructure and to workflow for the new maintainers of it, has costs borne by people outside the neutron team | 19:38 |
| slaweq | so we thought that it will be better to have it in the x/ namespace, at least for some time | 19:39 |
| slaweq | but if that's a lot of work, we can probably discuss it again in the neutron drivers meeting on Friday | 19:39 |
| slaweq | I will tomorrow ping lajoskatona about that | 19:39 |
| fungi | it's more that the work is doubled if the new maintainers succeed | 19:39 |
| fungi | so still some work if we expect them to fail, but twice as much if they don't | 19:40 |
| fungi | which seems... backwards | 19:40 |
| slaweq | ok, I will talk about it with lajoskatona tomorrow morning and we will discuss it again | 19:41 |
| gmann | slaweq: key point here is, if neutron team think that it will be considered to added back to neutron stadium then it is good to continue as it is and if not then moving to x/ is good | 19:42 |
| slaweq | personally I think it would be good to have it in stadium if new maintainers will really maintain it. I would be happy to see that | 19:43 |
| gmann | slaweq: and in case of continuing as it is and you see later that it is not going in the way neutron team want (they want to maintain fully or some part) then we can always retire it that time | 19:44 |
| slaweq | gmann: fungi ok, I see Your points here | 19:44 |
| slaweq | but I can't make that decision on my own :) | 19:44 |
| gmann | ah sure, whatever neutron team discuss and agree. | 19:45 |
| fungi | understood, i just wanted to raise it as an opportunity to hopefully welcome some new developers into openstack officially, we need more to offset attrition | 19:45 |
| slaweq | sure, thx for bringing this topic for the discussion | 19:46 |
| fungi | and it saves me some work if we don't have to bounce around multiple repositories | 19:46 |
| slaweq | ++ | 19:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!