| *** ianychoi has quit IRC | 00:56 | |
| *** gagehugo has quit IRC | 01:21 | |
| *** gagehugo has joined #openstack-tc | 01:30 | |
| *** whoami-rajat has joined #openstack-tc | 01:35 | |
| *** lbragstad has quit IRC | 01:40 | |
| *** ricolin has joined #openstack-tc | 04:45 | |
| *** ricolin has quit IRC | 05:25 | |
| *** ricolin has joined #openstack-tc | 05:28 | |
| *** lpetrut has joined #openstack-tc | 06:02 | |
| *** ricolin has quit IRC | 06:26 | |
| *** ianychoi has joined #openstack-tc | 06:57 | |
| *** jpich has joined #openstack-tc | 07:09 | |
| *** adriant has quit IRC | 07:10 | |
| *** adriant has joined #openstack-tc | 07:11 | |
| *** ricolin has joined #openstack-tc | 07:23 | |
| *** ricolin has quit IRC | 09:09 | |
| *** e0ne has joined #openstack-tc | 09:52 | |
| asettle | o/ | 10:05 |
|---|---|---|
| *** jpich has quit IRC | 10:05 | |
| *** jpich has joined #openstack-tc | 10:06 | |
| *** tosky has joined #openstack-tc | 12:14 | |
| *** ijolliffe has joined #openstack-tc | 12:33 | |
| *** jaypipes has joined #openstack-tc | 12:54 | |
| *** lbragstad has joined #openstack-tc | 13:02 | |
| *** mriedem has joined #openstack-tc | 13:02 | |
| *** ricolin has joined #openstack-tc | 14:53 | |
| *** lpetrut has quit IRC | 14:57 | |
| fungi | lookie there, it's office hour time once more! | 15:00 |
| fungi | i think clarkb has something to bring up, if he's around | 15:00 |
| clarkb | I do | 15:00 |
| gmann | o/ | 15:00 |
| mugsie | o/ | 15:00 |
| clarkb | There are a couple openstack related project renames queued up for tomorrow. https://review.opendev.org/#/c/657154/ and https://review.opendev.org/#/c/661684/ | 15:00 |
| clarkb | I wanted a sanity check on those before we proceed with them tomorrow | 15:01 |
| clarkb | so if you can take a look and either say yes or no that will be a big help | 15:01 |
| evrardjp | o/ | 15:02 |
| fungi | basically projects renaming into the openstack/ git namespace prefix | 15:02 |
| ricolin | o/ | 15:03 |
| fungi | these should be known to us, but the question is whether we include them in tomorrow's project rename maintenance or put them off until the next time we're able to schedule an outage for another batch of renames | 15:03 |
| zaneb | o/ | 15:03 |
| fungi | to those of you who were around for the stackforge/ namespace days, this should feel familiarly painful ;) | 15:04 |
| dhellmann | o/ | 15:05 |
| zaneb | compute-hyperv has already been approved as an official project, so I don't see any obstacle to renaming that one immediately | 15:05 |
| mugsie | yeah, that one seems good to go IMHO | 15:05 |
| evrardjp | fungi: I guess all hail to the infra team? | 15:05 |
| fungi | something like that | 15:05 |
| gmann | +1 on doing it before rename maintenance | 15:06 |
| evrardjp | thank you infra team, in all cases. | 15:06 |
| jroll | \o | 15:06 |
| fungi | i guess the bigger question is can we use our expedited house rules for repository additions in the liberasurecode and pyeclib cases | 15:06 |
| fungi | or are those contentious enough we want to give the most recent patchset a full week | 15:07 |
| zaneb | liberasure code one now has a majority (thanks gmann) so it's probably safe to assume it will pass | 15:07 |
| dhellmann | the house rules for those say they can be approved on 5 June | 15:07 |
| fungi | "In corner cases where the change is time-sensitive (like a deliverable reorganization which blocks a release request), the chair may fast-track the change, but should report on that exception in the TC update." https://governance.openstack.org/tc/reference/house-rules.html#other-project-team-updates | 15:08 |
| dhellmann | side node, we have a lot of open tickets that could use some voting or cleanup | 15:08 |
| mugsie | we are at 8/13 on the swift one - so that seems like it could be expediated | 15:08 |
| clarkb | ok so what I'm hearing is that we should be good on both unless someone were to object nowish? (given voting activity that has already happened) | 15:08 |
| dhellmann | yeah, sure, I think it's probably safe to say that addition is going to pass and there's no particular reason to wait if going ahead lets us do the rename | 15:08 |
| gmann | +1 | 15:08 |
| dhellmann | are either mnaser or asettle around to do the honors? | 15:09 |
| fungi | or we can do the rename on the assumption the governance change will pass, and let the governance change approval lag | 15:09 |
| mnaser | I can push it through. I think it was mostly okay, we had majority approval before asking for the x/<abc> change | 15:09 |
| mnaser | so that Zuul passses | 15:09 |
| dhellmann | ++ | 15:10 |
| zaneb | would be nice to approve before the rename otherwise timburke will have to rev the patch _again_ :) | 15:11 |
| fungi | basically as long as the openstack tc says it's okay for those projects to move to the openstack/ git namespace, the opendev sysadmins are happy to proceed with the renames for them. that can be signalled by approving the associated governance changes, or just by some consensus in irc, or a mailing list post, or... we don't really care | 15:12 |
| clarkb | fungi: exactly | 15:12 |
| mnaser | the compute-hyperv one was already approved | 15:12 |
| mnaser | the change pending is just the rename one | 15:12 |
| mnaser | afaik | 15:12 |
| evrardjp | Is the depends on for the latest patch on compute-hyperv correct ? | 15:13 |
| mnaser | I think the difference between compute-hyperv and swift is that: swift change actually needs an approval to accept or not, the compute-hyperv is just a repo rename | 15:13 |
| mnaser | https://review.opendev.org/#/c/655484/ | 15:14 |
| clarkb | evrardjp: I think our renaming docs said to set things up in that direction when we just blanket approved additions to openstack/ we may need to tweak that doc to not do that anymore | 15:14 |
| evrardjp | clarkb: it makes sense semantically | 15:14 |
| clarkb | evrardjp: it shouldn't affect anything now though other than ordering those commits | 15:15 |
| dhellmann | it would be nice if we could come up with a process to let teams create new repos under the openstack/ namespace directly, instead of forcing a rename on all of them | 15:15 |
| evrardjp | ok so that's good. thanks clarkb. | 15:15 |
| clarkb | dhellmann: you can create new repos directly. Maybe I misunderstand? | 15:15 |
| clarkb | dhellmann: we are renaming to preserve history in our tools | 15:15 |
| clarkb | but you can also create repos directly | 15:15 |
| dhellmann | well, if a team comes and wants a completely new repo, how does the opendev infra team know whether openstack/blah is ok as the name? | 15:16 |
| dhellmann | we can't land a governance patch to add the repo to the team until the repo exists | 15:16 |
| dhellmann | so how do we signal that the name is ok? | 15:16 |
| clarkb | from my side of things I think I'm happy of an official project says we are doing new official work in an official repo to just go with it (but I'm not the TC). | 15:17 |
| clarkb | dhellmann: what forces the governance patch to wait for the repo to exist? | 15:17 |
| clarkb | maybe we can relax that constraint and then enforce things the other direction | 15:17 |
| fungi | dhellmann: "in the stackforge days" the infra team waited for a governance change with the project addition to merge before approving the corresponding project-config change | 15:18 |
| dhellmann | there's validation in place to avoid adding repos that don't exist | 15:18 |
| dhellmann | at least I think so? | 15:19 |
| fungi | when we folded stackforge into the openstack/ namespace we reversed the suggested dependency order so we created projects and then people proposed governance additions for them if they were going to be official deliverable repos | 15:19 |
| dhellmann | yeah, I'm just pointing out that we need to look at that process and update it | 15:20 |
| fungi | it likely makes sense to go back to the previous "stackforge ordering" | 15:20 |
| mnaser | dhellmann: yes, the ci check would fail to create a new repo.. but I have a silly idea... | 15:20 |
| mnaser | we make a new job that is non-voting which checks if repo exists or not (that we use generally) | 15:20 |
| dhellmann | personally, I'd be fine with saying that PTLs of official teams can ask to have repos created at will as long as there is also a request to have the repo added to governance immediately | 15:20 |
| mnaser | and it's okay for that to fail when there's a new project.. and then in the gate, that job is voting | 15:20 |
| clarkb | dhellmann: ya that is sort of my thinking on it | 15:20 |
| fungi | that wfm | 15:20 |
| fungi | the project-config reviewers just need some clear signal they can go on | 15:21 |
| mnaser | but yeah. a depends-on/needed-by for governance/infra would be good, because the chair can +W the change | 15:21 |
| fungi | we *do* have ideas for how to make this simpler down the road | 15:21 |
| mnaser | and that will be the signal for infra to know that it's approved | 15:22 |
| openstackgerrit | Merged openstack/governance master: Add liberasurecode and pyeclib as Swift team deliverables https://review.opendev.org/657154 | 15:22 |
| fungi | at the ptg we came up with a plan for meta-repos per namespace and the ability to farm out project addition approvals to the bodies maintaining those meta-repos | 15:22 |
| mnaser | project-config being a trusted project means we can't do depends-on and use a checked out version, right? | 15:22 |
| fungi | so the openstack/__config__ repo (name made up right now on the spot) would have its own projects.yaml which the reviewers of that repo would be in control of | 15:23 |
| gmann | or considering the patch proposed and minimum number of recall vote (2 or 3) can be good signal. We do the same with one +2 on project side change when tempest test block the change to land on project side. | 15:23 |
| fungi | mnaser: correct, you can't test via depends-on but you can still rely on that to block merging of the change until the dependency lands | 15:23 |
| *** e0ne has quit IRC | 15:23 | |
| mnaser | but yes, having a namespace 'owner' is something I'm in favor of eventually | 15:25 |
| dhellmann | this feels like something we could easily just communicate about instead of setting up yet another repo to manage. We require ptl/liaison sign off for releases, and that works pretty well most of the time. | 15:25 |
| clarkb | dhellmann: the idea with the extra repo is to be able to have whoever the tc delegates do all the work | 15:26 |
| clarkb | rather than the infra team being an intermediary | 15:26 |
| fungi | well, the idea is to get the opendev sysadmins out of the way of projects approving additions | 15:26 |
| fungi | er, what clarkb also said | 15:27 |
| clarkb | (automation will still do the deployment work, but you can approve the changes as desired and then automation takes over) | 15:27 |
| mnaser | I guess that delegates trust down to PTLs to make sure they don't create repos that don't follow the mission or whatnot | 15:27 |
| mnaser | (If we let a PTL create any repo they want) | 15:27 |
| fungi | sure, the review team for openstack/__config__ could just review for technical correctness and not need the tc's blessing on every requested addition | 15:28 |
| fungi | but could still also raise questions to the tc if something seems cross-purposes | 15:28 |
| asettle | dhellmann, sorry, was outside | 15:29 |
| fungi | the tc could also be the review team for openstack/__config__ but that's probably worth delegating in my opinion | 15:29 |
| mnaser | I (feel) like we're still pretty far away from meta-repo right now | 15:29 |
| mnaser | the split is still good, regardless | 15:29 |
| clarkb | ya thats something that needs work to get to from the infra side | 15:29 |
| mnaser | at first stages of that 'split', things could still be the same (i.e. infra-core reviews that repo) | 15:30 |
| mnaser | and then eventually moves on | 15:30 |
| fungi | we're first rewriting our manage-projects automation, and then after that we can consider splitting projects.yaml up | 15:30 |
| mnaser | ++ | 15:30 |
| fungi | the ultimate goal there, in my opinion, is to put opendev reviewers in charge of approving new namespaces, but still let repository creation within namespaces be self-service for whoever controls that namespace | 15:31 |
| fungi | allowing the namespace maintainers to follow whatever policies they desire | 15:32 |
| fungi | we may eventually get to the point where new namespace creation is also self-service, but haven't really dug into the implications or come up with solid ideas on how to make it happen | 15:33 |
| *** tosky has quit IRC | 15:44 | |
| *** lpetrut has joined #openstack-tc | 16:48 | |
| *** jpich has quit IRC | 16:58 | |
| ricolin | asettle, about doc for explain the differentiate between team format, could you give a look on the draft etherpad and see if that looks right to you? | 17:36 |
| ricolin | https://etherpad.openstack.org/p/explain-team-formate-differentiate | 17:36 |
| ricolin | asettle, 01:36 for me, so catch with you later:) | 17:37 |
| *** ricolin has quit IRC | 17:42 | |
| fungi | the last section of https://lists.debian.org/debian-devel-announce/2019/05/msg00002.html makes me wonder whether the statusbot's parsing of #success and #thanks should be extended with the addition of something like #til | 17:44 |
| dhellmann | I like #til | 18:03 |
| fungi | or #tip or whatever makes the most sense for that | 18:46 |
| *** diablo_rojo has joined #openstack-tc | 19:06 | |
| mnaser | tc-members: I was looking at starting to revive the 'osops' tooling (because we need tooling here, and felt it would be better for the community to do it in the open). the osops repos have been fairly abandoned, under x/ namespace (not part of openstack official repos) and as part of reviving them, I wanted to create an openstack-operators org (from the very term 'osops') and move these inside them | 19:16 |
| smcginnis | ++ | 19:17 |
| mnaser | do folks feel that it's okay for us to put things under openstack-operators/tools-monitoring or something like that? should this be a deliverable of an actual sig/wg/foobar called 'openstack-operators' and repos are openstack/tools-monitoring ? | 19:17 |
| mnaser | there was some concern brought up around the idea of using a 'copyright' in the org name | 19:17 |
| fungi | wfm, though also if they were adopted by the uc or a sig that would allow them to be in openstack/ based on our earlier criteria | 19:17 |
| mnaser | to me it doesn't feel like it fits under any.. its just a bunch of scripts hosted somewhere | 19:18 |
| jroll | the trademark question seems like a question for legal-discuss, right? | 19:19 |
| jroll | I have no issues with it other than that | 19:19 |
| fungi | by "trademark" you mean "openstack"? if so, we grant unlimited use of the wordmark and logo for community activitiers | 19:19 |
| fungi | er, activities | 19:19 |
| * fungi finds official statement... | 19:20 | |
| jroll | ok, cool, that was the concern brought up in the infra channel | 19:20 |
| fungi | https://www.openstack.org/brand/openstack-trademark-policy/ | 19:20 |
| jroll | thanks | 19:21 |
| jroll | I'm fine with mnaser's proposal, then | 19:21 |
| mnaser | fungi, jroll: I sent something out to the ML to have a more documented 'ask' | 19:24 |
| fungi | the section on logo use is a bit more explicit than for the wordmark | 19:24 |
| mnaser | if you want to leave your comments there for future reference, I'd appreciate it, otherwise I can just paste your IRC logs there ;P | 19:24 |
| fungi | i am sort of curious why these can't be in some way "officially" endorsed by the user committee, at which point they could just go in openstack/ | 19:26 |
| fungi | but happy to follow up on the ml | 19:26 |
| mnaser | fungi: seems like it's a one person effort right now so I rather make life simpler.. for now heh | 19:29 |
| fungi | k | 19:30 |
| *** tosky has joined #openstack-tc | 19:38 | |
| TheJulia | Endorsed also puts a huge support connotation on them which might not be true. From an ops standpoint, it is more a specific problem solving YMMV kind of thing... at least from my POV. That being said, I like the openstack-operators namespace idea because it delineates where delineation might be good to provide that initial context. | 19:54 |
| fungi | i just dislike that it reinforces that our community is divided into developers and operators and you're assumed to be one or the other | 19:57 |
| *** lpetrut has quit IRC | 19:57 | |
| fungi | and perpetuates the "i can't do that i'm an operator not a developer" (or vice versa) | 19:57 |
| fungi | would love to be able to find new ways of reminding everyone that openstack was (and still is) developed by operators | 19:58 |
| smcginnis | I don't think the ops I've worked with feel like that distinction prevents them from doing anything. | 20:00 |
| smcginnis | I've actually seen the counter case where if they are lumped in with the rest of the community (read "the developers") then they feel like they are getting cut out and not recognized as an important piece of the overall community ecosystem. | 20:01 |
| clarkb | I feel like those are two sides of the same coin | 20:01 |
| fungi | definitely seen plenty of responses over the years along the lines of "i don't know why you're suggesting i fix this, i'm just an operator" | 20:11 |
| fungi | (implying there's are not-operators who will solve their problems for them) | 20:12 |
| fungi | and so would like to make it clearer to those people that the things they care about won't get better without someone who cares about those things rolling up their sleeves and tackling the problems head on | 20:13 |
| fungi | so if the only person who cares about $thing is you, then realistically your options are to take care of $thing or live with it not being done | 20:14 |
| fungi | but hiding behind artificial labels like "operator" and "developer" just makes it easier to pretend that's not how things actually work | 20:15 |
| fungi | ultimately creating false hopes leading to frustration and disappointment when faced with the reality of it | 20:17 |
| fungi | anyway, mnaser made the point in #openstack-infra that the real impetus for not putting them in the openstack/ namespace is that they're not really maintained by a cohesive group, that there's currently just one person taking care of them these days | 20:19 |
| fungi | though if there are concerns around insufficient quality to associate them with the openstack namespace, then painting them with the openstack-operators brush does perhaps also cast folks who self-identify as openstack operators in a negative light | 20:21 |
| *** ijolliffe has quit IRC | 20:22 | |
| *** diablo_rojo has quit IRC | 20:32 | |
| TheJulia | fungi: I totally agree with you. Is there no way we can provide light on some of the work and the importance of the work of operators? | 20:46 |
| fungi | TheJulia: likely worth following up on the ml thread and see if that message resonates beyond our echo chamber | 20:57 |
| fungi | (i did just a few minutes ago) | 20:57 |
| TheJulia | Will try to remember to do so on my flight | 20:59 |
| clarkb | fungi: "nebulous cloud" like nebula? | 20:59 |
| clarkb | >_> | 20:59 |
| fungi | carefully chosen words ;) | 20:59 |
| *** whoami-rajat has quit IRC | 21:24 | |
| *** mriedem is now known as mriedem_away | 22:35 | |
| *** zhurong has quit IRC | 22:52 | |
| *** ianychoi has quit IRC | 23:13 | |
| *** tosky has quit IRC | 23:33 | |
| *** tjgresha has joined #openstack-tc | 23:50 | |
| *** tjgresha has quit IRC | 23:55 | |
| *** tjgresha has joined #openstack-tc | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!