| *** bauzas_ is now known as bauzas | 01:13 | |
| opendevreview | Tim Burke proposed openstack/governance master: Appoint Tim Burke as PTL for Swift https://review.opendev.org/c/openstack/governance/+/928881 | 03:50 |
|---|---|---|
| *** bauzas_ is now known as bauzas | 05:24 | |
| *** bauzas_ is now known as bauzas | 08:09 | |
| opendevreview | James Page proposed openstack/governance master: Retire all single charm repositories https://review.opendev.org/c/openstack/governance/+/903490 | 11:51 |
| *** bauzas_ is now known as bauzas | 12:12 | |
| *** bauzas_ is now known as bauzas | 12:21 | |
| *** bauzas- is now known as bauzas | 13:03 | |
| *** whoami-rajat_ is now known as whoami-rajat | 14:04 | |
| *** bauzas_ is now known as bauzas | 15:35 | |
| gmann | tc-members not sure if we have any policy for that but are we ok to allow mix/inconsistency of name for current development branches 'master', 'main', 'current' or something else. example https://opendev.org/openstack/sunbeam-charms has 'main' branch instead of 'master' and in future other project can adopt the same or their own name. | 17:40 |
| gmann | I remember the past discussion where we wanted to get rid of 'master' but due to large work/impact required, we did not do that | 17:41 |
| dansmith | I do not want to get rid of master, FWIW, so I object to using "we" there | 17:41 |
| fungi | i think sunbeam already had at least some repos with a default branch name of "main" | 17:41 |
| * gouthamr was writing a long form response on the patch: https://review.opendev.org/c/openstack/governance/+/903490 | 17:41 | |
| gmann | yes, most of them are retiring which is ok for me but current active repo also have 'main' | 17:42 |
| gmann | discussion started here https://review.opendev.org/c/openstack/governance/+/903490/comment/17fe6fe7_c095919b/ | 17:42 |
| fungi | zuul/gerrit and opendev support arbitrary default branch names, though integration testing may get complicated if you're combining repos with different branch names | 17:42 |
| frickler | I noticed some issue with codesearch and "main" being the default branch. but I'll support anyone who tries to use proper language | 17:43 |
| gmann | yeah, testing, release, and many more tooling will be complicated if we have inconsistency in name | 17:43 |
| gouthamr | gmann: from what i can tell, opendev, gerrit accommodate a custom "default-branch" - which has made it possible for these charms projects to exist so far | 17:44 |
| fungi | for the most part it's already been exercised though | 17:44 |
| gmann | agree to use the proper language but I am not ok with introducing inconsistency. If anyone can change all 'master' branch name to 'main' I am ok otherwise not | 17:44 |
| frickler | we cannot move all of openstack in one step, but we shouldn't block projects who start this IMO | 17:45 |
| gouthamr | hmmm, why? | 17:45 |
| * gouthamr agrees with frickler | 17:45 | |
| gouthamr | i feel like you and i went searching for a note around this, and didn't find one where we "require" the default/development branch to be called "master" | 17:45 |
| gouthamr | ^ please help if you're aware of any such requirement | 17:46 |
| gmann | I need to search but we might not have explicit policy for that but we also do not say any branch name is ok to try by projects | 17:46 |
| gouthamr | ack | 17:47 |
| gouthamr | [1] https://docs.openstack.org/project-team-guide/stable-branches.html#processes | 17:47 |
| gouthamr | [2] https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#branches | 17:47 |
| gmann | it is charm so it is less impact but if any more integrated project say cinder, neutron, nova change branch name then it will break many tooling | 17:47 |
| gouthamr | ^ couple of places where we've spoken about branches.. the documentation assumes the development branch is called "master" all over.. but, technicality - we don't explicitly say it has to be "master" | 17:48 |
| gouthamr | gmann: agreed | 17:48 |
| gouthamr | changing branch names needs to be done in a coordinated way... today, these projects can have feature branches and setup releases from those branches if necessary | 17:49 |
| gouthamr | but, things will break if they change "master" to "main" - i think they can't even do it without the infra team helping them? :) | 17:49 |
| gmann | those are ok I am mainly concern about 'master' branch with mix of names | 17:50 |
| frickler | just ftr this is an example search that has broken links to opendev https://codesearch.openstack.org/?q=skip_kpartx&i=nope&literal=nope&files=&excludeFiles=&repos= | 17:50 |
| gmann | that is the key point, we need to do a coordinated effort if we want to get rid of 'master' | 17:50 |
| gmann | until then I do not think we should allow the inconsistency | 17:51 |
| JayF | I think the rough thing that intersects with this is that the word, itself, is considered offensive by some; and moreso in certain parts of the world and to certain minorities. | 17:51 |
| gouthamr | frickler: AH! nice find | 17:51 |
| frickler | in [1] we have "Current development branch: This is the master branch in a repository." one could read that as a requirement | 17:51 |
| gmann | I do not care much about name but care about consistecy | 17:51 |
| gmann | consistency | 17:51 |
| JayF | Regardless of whether OpenStack is ready for the change overall or not, it seem morally rough to force someone to use that term. | 17:51 |
| gouthamr | gmann: ack; maybe we make a recommendation that we have a small set of acceptable names for the development branch? | 17:52 |
| gmann | well, it should be single name whatever we choose either stay as 'master' name or other. otherwise set of names still introduce the inconsistency | 17:53 |
| fungi | opendev's stance so far is that the default-default (what gets used if no default name is specified) matches the default-default of the current git release (what you get when you `git init` in a directory with no overriding configuration) | 17:53 |
| TheJulia | I'm just going to note this topic has come up in joint meetings with the board in the far past where the board expressed a desire to see a move (to use main as opposed as master), but the fear, uncertainty, and amount of work required basically torpedoed the overall topic from even being scoped. Since this is coming up again, I would encourage evolution and inclusion. | 17:54 |
| fungi | other than that, we've tried to stay out of it | 17:54 |
| gmann | inconsistency always introduce continuous more work which is the key here considering current community bandwidth | 17:55 |
| gmann | it makes support tooling (testing, release etc) more worst which already suffer for less contributors | 17:56 |
| TheJulia | We're always going to punt things, the value is estimating, sizing. The issue is the overall punt creates more of this since the default for new git repos is now "main" from running git init. In other words, it *will* keep coming up. | 17:56 |
| fungi | what the openinfra board has said, through supporting a statement written by delegates in the diversity and inclusion working group, can be found at https://wiki.openstack.org/wiki/Governance/Foundation/Inclusive_Language | 17:57 |
| gouthamr | ack, that's where i read "but the discussion is far from settled yet" | 17:58 |
| fungi | the inclusive terminology article linked at the bottom there distinguishes between use of the term "master" in slavery-related contexts vs in other contexts | 17:58 |
| TheJulia | I'd advocate taking a little time and creating an actual plan. It doesn't have to be perfect, and could include "hey, we can do 2-3 of the 8 things quickly and easily" and that could just be enough. I'd hate for the revisit to the topic to just end up in the figurative "toss hands up" and keep the status quo. | 17:58 |
| gouthamr | TheJulia: +1 | 17:58 |
| TheJulia | The status quo does nothing but hurts us through things like inconsistency, codesearch user experience, etc. | 17:59 |
| TheJulia | And that is just on the technical level, not the social impresison level | 17:59 |
| * TheJulia gets off her soapbox | 18:00 | |
| gmann | I disagree with any plan which does not handle 'master' -> 'something' change as a coordinated effort and leave tooling broken | 18:00 |
| gmann | if it is a coordinated effort and plan to fix tooling then I am ok otherwise it can go more worst | 18:01 |
| TheJulia | gmann: any plan can have many steps, just putting that first as requirement zero does not help the overall effort be sizable because we're staying we have to make the giant leap as an initial state through impression. | 18:02 |
| gmann | in general effort we can say that but if talking about specific 'master' -> 'something' change then I would prefer the coordinated and complete plan instead of step by step or leaving tooling broken | 18:03 |
| TheJulia | any plan, to be able to be executed in a community of our size with our constraints *has* to be step by step to be decomposible into smaller, more independently executable steps. Some of that may be fixes in the short term along a complete plan. | 18:05 |
| TheJulia | bottom line, we can't boil the ocean *either* | 18:07 |
| * TheJulia goes back to backport land | 18:07 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!