| opendevreview | Wu Wenxiang proposed openstack/governance master: Appoint Wenxiang Wu as PTL of Skyline https://review.opendev.org/c/openstack/governance/+/915108 | 02:37 |
|---|---|---|
| opendevreview | Dr. Jens Harbott proposed openstack/openstack-manuals master: DNM: test running build jobs on newer distro https://review.opendev.org/c/openstack/openstack-manuals/+/915086 | 06:07 |
| frickler | tc-members: ^^ I added my response to the application by Wenxiang Wu, feedback welcome | 06:42 |
| frickler | completely unrelated, we should keep in mind to update the openstack map when projects are retired or made inactive, see https://review.opendev.org/c/openinfra/openstack-map/+/914948 , this was discovered while checking docs pages during the release earlier this week | 06:48 |
| ttx | It can be tricky as the list of deliverables in a release can be different from the list of official project teams. I feel like the map should represent what's in the latest release, so it's probably up to the release team to keep it updated to match planned deliverables (for caracal there were quite a few late changes) | 07:00 |
| gtema | frickler: your comments in the skyline patch are so valid, that especially in the light of xz issue we need to keep an extra eye there | 07:32 |
| frickler | tc-members: two changes to the version selector code in openstackdocstheme, the second one may be a bit controversial: https://review.opendev.org/c/openstack/openstackdocstheme/+/915128 Fix series selection and sorting, https://review.opendev.org/c/openstack/openstackdocstheme/+/915129 Don't offer to show unmaintained versions | 12:42 |
| frickler | cf. also https://review.opendev.org/c/openstack/governance/+/914950 and I will now make a change for gerritbot to also show these changes here directly | 12:43 |
| fungi | frickler: keep in mind that openstackdocstheme is technically an oslo team deliverable: https://governance.openstack.org/tc/reference/projects/oslo.html#openstackdocstheme | 12:46 |
| fungi | with the dissolution of the tech writing sig, the oslo team got its libraries/tools and the tc ended up with the content repositories | 12:47 |
| frickler | fungi: yes, this is what I proposed to change with https://review.opendev.org/c/openstack/governance/+/914950 | 12:48 |
| fungi | aha, i missed that | 12:48 |
| fungi | i'll follow up there, thanks | 12:49 |
| frickler | "... per its current convention of applying animal names to each fresh version of the project." (from https://www.theregister.com/2024/04/04/openstack_caracal_released/) has this actually been decided somewhere or did the writer just extrapolate that from recent names? | 13:01 |
| fungi | i think it was probably a bit of the snark that publication is reknowned for | 13:03 |
| fungi | but our community does seem to like the animal names, can't deny that | 13:03 |
| dansmith | frickler: I think that once the foundation took over naming they started the animal thing and mentioned that convention, no? | 13:36 |
| ttx | well, there were other non-animal candidates in the poll but the animal won | 13:54 |
| fungi | that's what i meant by "our community does seem to like the animal names" | 13:54 |
| ttx | trademark lawyers do too! | 13:54 |
| fungi | every poll has included a variety of options, but animals seem to win consistently | 13:54 |
| ttx | I was a Daikon person | 13:55 |
| fungi | i do like me some radish | 13:55 |
| dansmith | ah okay I thought they stated they were going for animals | 14:04 |
| fungi | well, after four animals in a row, it's possible they'll decide it's a theme | 14:09 |
| fungi | though with ubuntu also naming its release cycles after animals intentionally, it might seem like copycat behavior (pun intended) | 14:10 |
| *** hberaud is now known as hberaud_PTO | 15:00 | |
| frickler | tc-members: one final question from me before the weekend (or so I hope): we don't have anyone yet who at least admitted to think about becoming the next TC chair, right? or did I miss something? | 15:58 |
| gmann | frickler: yes, we do not have any nomination or interest for Chair yet | 17:07 |
| gmann | +1 on both of the openstackdocstheme changes | 17:13 |
| gmann | on this, I added my opinion. I am not 100% sure if we should include doc tooling under TC, looking for more opinion https://review.opendev.org/c/openstack/governance/+/914950 | 17:15 |
| gmann | ttx: I think considering only the latest release projects in openstack map will confusing, especially from Inactive project side. If any project moving to Inactive but become Active again then map will have that project in map will be disappearing and coming back. | 17:51 |
| gmann | This can be really confusing for users (who does not know about these Inactive/Active/release model things) thinking XYZ project was OpenStack project but not now and it came up again. | 17:51 |
| gmann | I think keeping it with official projects will give users more clarity on what is 'Current OpenStack project' and what is not. | 17:54 |
| gmann | if we are reflecting the release status in map then we should make it per release map not a general map | 17:54 |
| fungi | i guess it depends on what "current" means. currently official, but not necessarily currently being maintained | 17:54 |
| gmann | Current official | 17:55 |
| gmann | maintained or not for sometime or long time is internal matters and the end visibility for users is project retirement | 17:55 |
| gmann | if map audience is not just community but outside community too then we should not reflect internal status which can be confusing for them. Project moving to Inactive to Active is good example | 17:56 |
| fungi | but also, there are some currently official projects which aren't listed on the map for other reasons like being test-focused or being a component of something else. conversely there are components listed which don't map 1:1 to different teams | 17:56 |
| fungi | what is "official" in the projects list is teams of developers working on various deliverables, while what's on the map is a selection of notable deliverables produced by some of those teams | 17:57 |
| gmann | I am not sure the what is policy to include in map as that is maintained by foundation staff side but seeing that in top page of site seems like this is "complete current picture of OpenStack" and not the "what is maintained, released, services only" https://www.openstack.org/software/ | 17:59 |
| gmann | maybe we can clarify more in the overview statement of the map because if we keep only "latest released projects" then current definition seems not matching or less clear "OpenStack is broken up into services to allow you to plug and play components depending on your needs. The openstack map gives you an “at a glance” view of the openstack landscape to see where those services fit and how they can work together." | 18:00 |
| gmann | then it should include "these are currently maintained and released services/tool" | 18:00 |
| fungi | which is also potentially misleading, since cycle-trailing deliverables that haven't (yet) made 2024.1 releases are included even though there's no guarantee they will do so (but maybe having made releases in the previous cycle is a sufficient indicator that they likely will) | 18:02 |
| gmann | that is where we can mention 'latest released' and not per cycle release or not | 18:03 |
| gmann | or "maintained and released" can be simple one which can cover both they are maintained and released whenever they are suppose to be released | 18:04 |
| fungi | i'm starting to think that relying on purely governance-based rules might not result in a map that makes the most sense to users | 18:05 |
| dansmith | I think that has been the case for a long time | 18:06 |
| fungi | how we organize and/or list projects for purposes of governing their development is necessarily a good fit for how users are going to look at the software | 18:06 |
| fungi | er, is not necessarily a good fit i mean | 18:06 |
| gmann | so what is best way to make decision "what is ready/better project for users" and can be shown to map? IMO, landscape map means what are there in that and which is better-fit for what use case is up to users to "try and adopt" | 18:09 |
| fungi | we list nova and placement on the map, but those are both handled by the nova team. we list ceilometer and aodh on the map, but those are both maintained by the telemetry team | 18:09 |
| fungi | openstackclient and openstacksdk... | 18:10 |
| fungi | kolla and kolla-ansible... | 18:10 |
| fungi | we list tempest and rally but not devstack or grenade | 18:14 |
| fungi | we don't list any oslo libraries | 18:15 |
| fungi | so, yeah, i'd be hard pressed to come up with any clear ruleset for determining what does or doesn't get listed, much less how they're classified. seems like it's the sort of thing someone with an opinion has to decide and make some hand-wavy compromises on | 18:16 |
| gouthamr | on the tempest and rally thing - these projects/tools can be used with production clouds; devstack and grenade can't / shouldn't be | 18:42 |
| * gouthamr is thinking that's the train of thought here regarding their exclusion.. | 18:43 | |
| fungi | that makes sense, yep | 18:44 |
| opendevreview | Ghanshyam proposed openstack/governance master: Add timeline to remove enforce_scope in RBAC goal https://review.opendev.org/c/openstack/governance/+/915179 | 19:31 |
| spotz[m] | Map is definitely more condensed then in the past | 19:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!