| frickler | oh, wow, we are saved. for now. https://github.com/pypa/setuptools/issues/4976 | 06:20 |
|---|---|---|
| *** elodille1 is now known as elodilles | 07:57 | |
| opendevreview | Lukas Kranz proposed zuul/zuul-jobs master: Add limit-log-file-size role https://review.opendev.org/c/zuul/zuul-jobs/+/945795 | 08:17 |
| opendevreview | Lukas Kranz proposed zuul/zuul-jobs master: Add limit-log-file-size role https://review.opendev.org/c/zuul/zuul-jobs/+/945795 | 08:21 |
| fungi | never the less, we need to figure out how to migrate pbr off those interfaces before the next attempt at removal | 15:42 |
| mordred | if they're wanting to walk away from ScriptWriter, we could just pull that class into pbr pretty easily | 15:49 |
| JayF | I'd suggest just asking them in an issue | 15:59 |
| fungi | yeah, also need to address the current bitrot in pbr's tests since the last patch we merged over 3 months ago | 16:02 |
| dan_with | Hey, I was wondering I could talk to you about your branching strategies in your repos. Currently, I'm hashing that out with my team about our Genestack repo. Right now, people want to basically follow this: https://wiki.openstack.org/wiki/Branch_Model. However, this diagram doesn't show how/where dev work is being done. I'm assuming that that each OpenStack team does have dev and testing branches? I'm of the opinion that a dev branch | 19:48 |
| dan_with | exist where people make PRs against a staging/testing branch that is CI tested. When everything passes on staging/testing branch, I would make a merge commit to main, then make a release candidate off of main. Additionally cherry picks would be back ported at that point to previous releases. I'm trying to short circuit arguments and it may help to hear how OpenStack teams are actually doing their entire repo workflow. Thanks. No rush on | 19:48 |
| dan_with | an answer. | 19:48 |
| JayF | dan_with: no, we don't have dev or testing branches | 19:50 |
| JayF | master branch, every commit put to it must pass CI | 19:50 |
| JayF | and CI includes integration testing | 19:50 |
| JayF | dan_with: workflow is basically: checkout master; create a branch if you want (not required); add a commit on that branch (usually exactly one); git review | 19:51 |
| JayF | when we get code review +2 twice, and workflow +1, it goes into a queue to be CI checked again then merged into master | 19:51 |
| JayF | we create alternate branches at major release time, using tooling from https://opendev.org/openstack/releases | 19:52 |
| JayF | e.g. https://opendev.org/openstack/releases/src/branch/master/deliverables/dalmatian/ironic.yaml describes the creation of 4 releases and 3 stable/bugfix branches | 19:52 |
| JayF | if we have a backportable patch, we cherry pick from master to the latest stable, all the way back in chronological order, like a backport chain | 19:53 |
| JayF | I've never once seen an openstack project use a traditional "feature branch" style dev model, although I suspect it has happened ever in some project for some kinda major change, but it's def abnormal | 19:53 |
| JayF | dan_with: sorry wasn't 100% sure what you were asking so I gave you the full brain dump; is that helpful? | 19:54 |
| dan_with | Ok, so do you have the ability in this workflow to make a PR to master, but designate it as WIP? How do you flag/tag it for that versus "I'm ready for a review and CI testing"? | 19:54 |
| dan_with | Thanks. That is helpful | 19:55 |
| JayF | so gerrit has an idea of "work in progress" | 19:56 |
| dan_with | Ah Gerrit. We are using Git. | 19:56 |
| JayF | but a lot of folks who work with gerrit ... well, I'll speak for me ... *I* don't really have an idea of using branches around my patchsets | 19:56 |
| JayF | I use `git review` to push the patchset to gerrit, and `git review -d` to download it again if it needs edits | 19:56 |
| JayF | if I push a change and don't want people to waste time reviewing it, there's a gerrit concept of WIP that is used rarely (mainly because it's newer) and many projects just use a self-vote of Workflow-1 as a symbol that it's not ready | 19:57 |
| JayF | if I have a real **branch** with multiple dependant commits, `git review -d [last patchset]` pulls the whole chain | 19:57 |
| JayF | dan_with: fwiw, gerrit is the code review at review.opendev.org; it's still git behind it | 19:58 |
| JayF | if you're using a pure push-to-master-using-git workflow, that's sorta antiquated by a lot of modern standards :/ | 19:58 |
| dan_with | I see. okay thanks. I'll review Gerrit and see how that would change how we would approach this. | 19:59 |
| JayF | dan_with: https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html may be useful? | 20:00 |
| dan_with | Nice! thank you | 20:00 |
| JayF | basically: throw away everything you think about PRs and github, gerrit looks at things a little differently but it leads to a lot of really nice outcomes (personal favorite: commit message as a code reviewable item) | 20:01 |
| dan_with | Ah yeah, this is the way to go (Gerrit) for sure. On the sandbox, I guess I have to have a Gerrit user within Opendev? | 20:12 |
| JayF | yeah if you haven't gone thru that whole guide, it's useful if you're planning on contributing to opendev projects | 20:16 |
| JayF | https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html | 20:16 |
| fungi | dan_with: one way to look at it is that we have an infinite number of "testing branches" like the github pull requests you're familiar with, and a continuous integration/project gating system called "zuul" which takes care to merge them to master once they've been positively reviewed, approved, and are passing all required test jobs | 20:57 |
| dan_with | gotcha | 20:58 |
| fungi | dan_with: if you're just wanting to play around with opendev's gerrit then the infra-manual and sandbox repo are the way to go. if you're considering contributing to openstack on the other hand you'll want to start at the beginning of the openstack contributor guide which will walk you through some additional openstack-specific bits: https://docs.openstack.org/doc-contrib-guide/ | 21:00 |
| dan_with | Thanks | 21:01 |
| JayF | What /is/ the meta-reason for the ask? | 21:01 |
| fungi | dan_with: oh, wait, wrong contributor guide... this one: https://docs.openstack.org/contributors/ | 21:02 |
| fungi | my first link was to the docs contributing instructions not the general openstack contributing instructions | 21:02 |
| fungi | i blame dodgy airplane wifi | 21:02 |
| opendevreview | Harald Jensås proposed openstack/diskimage-builder master: Fix growvols multipath partition_delimiter detect https://review.opendev.org/c/openstack/diskimage-builder/+/924074 | 22:08 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!