| *** bauzas_ is now known as bauzas | 00:24 | |
| gmann | Considering Kuryr merged in Zun team, only three projects are leaderless in this election (Watcher, Swift, and Mistral). This shows that previous cycle cleanup/retirement has filtered out many repetitive inactive/leaderless projects. | 02:40 |
|---|---|---|
| gmann | timburke ^^ not sure if missed the election for swift | 02:42 |
| *** bauzas_ is now known as bauzas | 03:02 | |
| *** bauzas_ is now known as bauzas | 11:33 | |
| opendevreview | Walt proposed openstack/election master: Withdrawing Walt Boring Candidacy for cinder PTL https://review.opendev.org/c/openstack/election/+/927506 | 13:15 |
| *** bauzas_ is now known as bauzas | 14:56 | |
| frickler | jamespage: do you know why there is no charms install guide for 2024.1? cf. https://docs.openstack.org/2024.1/deploy/ | 17:06 |
| frickler | also question to all: why does that page still say " This is documentation in progress for the next release. "? | 17:07 |
| fungi | charms follows a cycle-trailing model, and i vaguely recall them being late or completely missing the trailing deadline for 2024.1? | 17:08 |
| frickler | 2023.2 says the same, seems this should have been cleaned up | 17:08 |
| fungi | oh, if it's a separate manual process that would make sense | 17:08 |
| frickler | a user in #openstack noticed the guide missing and wonders above the future of charms as a deployment tool and I don't know what to tell them | 17:09 |
| frickler | s/above/about/ | 17:10 |
| frickler | I also don't know whether sunbeam is to be a replacement or just an alternative | 17:10 |
| frickler | but I also guess it is up to canonical to be better at documenting things | 17:11 |
| frickler | seems I did the update for 2023.1 myself some time ago https://review.opendev.org/c/openstack/openstack-manuals/+/885754 , will do a matching patch now | 17:14 |
| opendevreview | Jens Harbott proposed openstack/openstack-manuals master: Update deployment guide indices for active releases https://review.opendev.org/c/openstack/openstack-manuals/+/927531 | 17:17 |
| timburke | oh dang, i did miss it again... | 17:18 |
| frickler | timburke: now you're going to stand in the corner for a cycle ;-P | 17:19 |
| * timburke puts on the sad hat | 17:20 | |
| frickler | timburke: well seriously, I think the TC will have to appoint you after the election period has finished. or maybe it can happen earlier if there are no PTL elections? | 17:20 |
| frickler | I'm not sure whether this is a task that the current TC should perform or rather wait for the next TC to be established | 17:21 |
| gmann | yeah, we need to get election closed and then do the appointment. process can be started early though | 17:22 |
| timburke | 👍 | 17:23 |
| gmann | basically once election official propose the governance change for PTL election result and then timburke can propose the appointment request on top of that. | 17:25 |
| gmann | timburke: not sure if you considered DPL model but if you think election process is extra step for swift then that also once option. Though we need to reset DPL model every cycle and DPL liaisons can ack to continue the DPL model which will avoid reset. | 17:26 |
| gmann | but its your call | 17:26 |
| gmann | *one option | 17:27 |
| gouthamr | so effectively, its an extra step either case :) | 17:27 |
| gmann | not same as election which is lot of work for election official also | 17:27 |
| gmann | DPL reset means just TC propose DPL reset and liaison -1 will consider to continue the DPL model | 17:28 |
| gmann | with election, it is nomination, election official track of project to remind nomination/reminder, update the result as PTL appointment, TC need to discuss the appointment and another change to appoint PTL | 17:29 |
| gouthamr | yes, its simpler.. but, i hope its not the reason why Swift (or any project) would consider the DPL model.. | 17:29 |
| gmann | * update the result as 'PTL appointment needed' | 17:29 |
| gmann | I am not saying this is the only reason to consider DPL. timburke is continuing PTL in every cycle for swift and if there is no other member raising hand for leadership then DPL model is best suit for such project to avoid unnecessary elections steps | 17:31 |
| gmann | we have both options, and the project can check what is best suited for them. Especially to reduce process overhead, which can help in actual maintenance work. | 17:33 |
| gmann | That is why we have process to consider leaderless projects to move to DPL as first choice unless we have request of keeping leaderless project as PTL | 17:34 |
| gmann | timburke: this is the DPL process doc just in case you missed our recent doc restructure/DPL monitoring modification. https://governance.openstack.org/tc/reference/distributed-project-leadership.html | 17:36 |
| gouthamr | gmann: ah; yes.. ty for the context, and for the recommendation.. i haven't kept up with the velocity of the swift project.. i see that its pretty active; with a number of contributors from Nvidia.. it might be desirable to delegate things across a number of contributors - this is possible with both PTL and DPL models; except in DPL, there could be several "formal" points of contact. | 18:07 |
| *** bauzas_ is now known as bauzas | 20:34 | |
| clarkb | Elastic.co posted a blog post about how elasticsaerch will be agpl as a license option in the near future | 21:38 |
| clarkb | just want to put that out there since there was recent discussion about source available license problems and I think elasticsaerch was one of the examples | 21:38 |
| spotz[m] | clarkb: Hey don't forget a power adapter! | 23:50 |
| clarkb | spotz[m]: ya its the european plug already in my bag | 23:50 |
| spotz[m] | I almost forgot and just reminded Helena:) And I remembered Allison said you were going | 23:51 |
| fungi | clarkb: oh neat, so elastic is sort of backpedalling on their move away from open source licensing? | 23:56 |
| spotz[m] | That's been all the news this afternoon:) | 23:56 |
| fungi | i guess they figured out opensearch made their decision somewhat pointless | 23:56 |
| clarkb | fungi: ya the post is interesting in a "we're doing this because we succeeded" manner | 23:57 |
| clarkb | personally it feels like AGPL would've been fine all along | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!