| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: Oslo Releases for Aug 24, 2015 https://review.openstack.org/216415 | 00:57 |
|---|---|---|
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: [WIP] Fix list-changes https://review.openstack.org/216475 | 00:57 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: Oslo Releases for Aug 24, 2015 https://review.openstack.org/216415 | 01:20 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: list-changes breaks because of bad start_range https://review.openstack.org/216475 | 01:20 |
| *** dims__ has quit IRC | 01:55 | |
| *** bnemec has quit IRC | 04:42 | |
| *** armax has quit IRC | 06:16 | |
| ttx | dhellmann: yes | 07:02 |
| ttx | lifeless: around? | 07:02 |
| ttx | lifeless: I'm a bit unclear on the process we need to follow to drive the last stage of the dev cycle and creation of release (or stable) branches -- and the proximity of the action has me stressed out. Wanted to doublecheck a few things with you in those very few work hours we have in common | 07:05 |
| lifeless | ttx: hi | 07:13 |
| lifeless | ttx: should I get some hard complex carbohydrates out? | 07:13 |
| lifeless | ttx: I don't want you stressed ;) | 07:14 |
| ttx | lifeless: hey | 07:16 |
| ttx | lifeless: I posted my questions on an ML thread but I think we need a lower-latency discussion to flush things out | 07:17 |
| ttx | lifeless: My assumption was that we'd follow the process we came up with in Vancouver | 07:17 |
| lifeless | righto | 07:18 |
| lifeless | we put that in a doc somewhere | 07:18 |
| ttx | So my first question is, is there any reason why that wouldn't work, now that the contraints stuff is actually in place | 07:18 |
| ttx | see raw list at http://lists.openstack.org/pipermail/openstack-dev/2015-August/072725.html | 07:19 |
| ttx | lifeless: we may question the utility of stable branches for some things (like libs) in the future but I'd rather make one change at a time | 07:19 |
| lifeless | http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html | 07:19 |
| lifeless | ttx: Right, I haven't proposed changing anything that we didn't discuss in vancouver | 07:20 |
| lifeless | ttx: There are two things we haven't fully done | 07:20 |
| lifeless | one is the stable<->master cross check for the release 'period' | 07:20 |
| lifeless | to ensure co-installability | 07:20 |
| lifeless | we can achieve that another way (e.g. by care on reviews and good team communication) | 07:21 |
| lifeless | this bit: During that period we’ll gate any requirements changes on both master and any branched projects, branching openstack/requirements last when we’re finally ready to decouple the release from master. | 07:21 |
| lifeless | its possibly just infra configuration | 07:22 |
| lifeless | 'just' | 07:22 |
| ttx | so instead of gating we'll just apply extra care there ? Or is it worth trying to push it ? | 07:22 |
| ttx | need some analysis I guess | 07:22 |
| ttx | but plan B would be to soft freeze requirements and apply extra care before approving anything | 07:22 |
| lifeless | yeah | 07:24 |
| lifeless | we should talk to fungi about having cross-gating | 07:24 |
| ttx | lifeless: I was wondering if the constraints stuff was designed to work on stable->stabel once everything is branched out, or if we would update it very carefully and very manually | 07:24 |
| lifeless | that is on having master requirements run the jobs from the new branches as well | 07:25 |
| lifeless | ttx: stable->stable yes, should be fine | 07:25 |
| lifeless | hells no, I'm all about the lazy | 07:25 |
| lifeless | and careful and manual is not lazy | 07:25 |
| ttx | just checking, just checking | 07:26 |
| ttx | Re-Reading thoise vancouver plan, I also wondered what the heck we meant by "Converge constraints". I remebner that was a simple thing but I can't remember what we meant by that | 07:26 |
| lifeless | gone | 07:27 |
| ttx | No more need for that? | 07:27 |
| lifeless | from memory | 07:28 |
| ttx | You were the one adding it originally, so I'll trust you on that | 07:28 |
| lifeless | teehee | 07:28 |
| ttx | OK, so in summary... the plan is still on. We need to immediately evaluate if we can have stable/master cross-check in time for end of next week, but otherwise we follow the plan (minus "converge constraints") | 07:29 |
| lifeless | yeah | 07:30 |
| lifeless | IIRC the infra discussion more | 07:30 |
| lifeless | it was simple | 07:30 |
| ttx | The stable/master crosscheck is what? Having stable branches tests run on master requirements ? | 07:30 |
| lifeless | we setup the liberty jobs | 07:30 |
| lifeless | they all fallback to master on missing branches | 07:31 |
| ttx | right, that's what I was thinking.. not even sure we need to set up anything | 07:31 |
| lifeless | we just need to trigger them on changes to master requirements, and they'll run with the branches that have been made | 07:31 |
| ttx | oh! I see | 07:31 |
| lifeless | and we fork requirements last | 07:31 |
| lifeless | s/last/at the end of the critical section/ | 07:32 |
| ttx | so stable branches should test with master requirements already, due to the fallback. But we need to gate any master requirements change on stable tests as well. Got it | 07:32 |
| lifeless | IIRC converge constraints was making sure that no project has outstanding openstack/requirements sync patches | 07:32 |
| lifeless | at the time of release | 07:32 |
| lifeless | (because if they do, they are not consistent across the release) | 07:33 |
| ttx | I agree some soft freezing and care on requirements update could do the trick if we can't figure it out | 07:33 |
| ttx | ok, makes sense to do that | 07:33 |
| ttx | OK, I think I have all the bits. I'll discuss the cross-check with fungi and see what we can do in the remaining time | 07:34 |
| lifeless | the other thing we haven't yet gotten is constraints in tox jobs | 07:34 |
| lifeless | but thats close and we can add that as and when stable tox jobs break | 07:34 |
| ttx | right, so we might miss a few breaks | 07:34 |
| lifeless | not that thats ideal | 07:34 |
| lifeless | but it won't wedge the sstable gate | 07:34 |
| lifeless | it will make individual projects unhappy at most | 07:34 |
| ttx | easier to untangle | 07:35 |
| ttx | lifeless: last question on that topic -- on master we have new upper-contraints being proposed and tested all the time. Would we have any of that on stable branches ? Should we ? | 07:36 |
| ttx | My gut feeling is "no" and that we'd do manual bumps only | 07:36 |
| lifeless | we will | 07:36 |
| ttx | oh? | 07:36 |
| lifeless | remember that constraints bumps are not requirements bumps | 07:37 |
| lifeless | if its passing tests we have no reason to publish an older known-good than works | 07:37 |
| ttx | sure, but I thought minimizing constraints bump was the way to not push caps | 07:37 |
| lifeless | right | 07:37 |
| lifeless | stepping up | 07:38 |
| lifeless | theres a dial | 07:38 |
| lifeless | we can tune it | 07:38 |
| ttx | we want stable/liberty nova tested with stable/liberty oslo.messaging... how do you do that without capping and with constant bumps ? | 07:38 |
| lifeless | I think knowing that things are / are not working for ecosystem libraries is useful | 07:38 |
| lifeless | the automated proposals would tell us that | 07:38 |
| lifeless | but equally we can turn them off | 07:38 |
| ttx | Totally agree, on the 3rd-party lib front | 07:38 |
| ttx | (which we didn't really cap before anyway) | 07:39 |
| lifeless | well, I want us to get oslo.messaging back to run-latest-release-on-stable-branches as a thing | 07:39 |
| lifeless | but we have to unwind this hole we dug ourselves into first | 07:39 |
| lifeless | which constraints is just the first leg | 07:39 |
| ttx | sure, long term we might just do that. In the mean time with liberty we stil want to relay on "stable/liberty everywhere" as a unit of versions to test | 07:40 |
| ttx | relay* | 07:40 |
| ttx | rely* | 07:40 |
| ttx | so that means carefully updating stable/liberty upper-constraints as far as oslo libs go | 07:41 |
| ttx | the system won't enforce that we only use stable/liberty oslo.mesdsaging versions there | 07:41 |
| ttx | we'll have to (as long as we want to keep using stable/liberty as a unit of versions to test together) | 07:41 |
| ttx | I'm just trying to picture what we replace the oslo capping we did in kilo with | 07:43 |
| ttx | My understanding is: we replace it with a branch of upper-constraints that we carefully bump | 07:43 |
| ttx | until we are ready to completely get rid of oslo stable branches. | 07:44 |
| lifeless | yes | 07:45 |
| lifeless | your understanding is copacetic | 07:45 |
| lifeless | now | 07:45 |
| lifeless | you also wanted to talk about the release notes proposal I believe? | 07:45 |
| * ttx looks up copacetic | 07:45 | |
| lifeless | "in excellent order." | 07:46 |
| ttx | thx | 07:46 |
| lifeless | https://en.wiktionary.org/wiki/copacetic | 07:46 |
| ttx | Yes, about the release notes stuff. Some people object that it's too complex and given the rate of changes in the branch we could deal with merge conflicts on a single directly-maintained doc | 07:47 |
| ttx | I'd say that's the two options we have at this point | 07:47 |
| lifeless | so | 07:47 |
| lifeless | master | 07:47 |
| lifeless | not so slow | 07:47 |
| ttx | Another benefit of plan B being that it doesn't require any code | 07:47 |
| lifeless | so start with plan B:) | 07:48 |
| ttx | hmm, yes, good point on master. I focused on stable needs | 07:48 |
| lifeless | About 10-15% of my time doing commits to cPython is manual NEWS file entries. | 07:49 |
| lifeless | it is precisely a manual release notes thing | 07:49 |
| lifeless | in a single doc | 07:49 |
| lifeless | by hand merge fixups on merges across branches | 07:49 |
| ttx | it looks like we need to iterate a few times on solutions that would work around the merge conflicts issues | 07:50 |
| ttx | dhellmann wondered if some sphinx-powered solution could not work as well | 07:51 |
| ttx | How feasible would you say it is to have something ready for start of mitaka ? | 07:51 |
| ttx | If unlikely (and better discussed at the summit) then let's do plan B for stable/liberty | 07:52 |
| lifeless | sphinx or markdown are equally easy, there's no structural difference | 07:52 |
| lifeless | you run the preprocessor, it makes the tree ready to render anyway you want | 07:52 |
| lifeless | rst / md. Big deal. | 07:52 |
| lifeless | merge conflict issues? There aren't any in my proposal from memory... | 07:52 |
| ttx | lifeless: I think he argued it uses code and triggers that are alreday there (but that was before we discovered that doc is not generated in tarballs) | 07:53 |
| lifeless | I really don't think this belongs in pbr | 07:53 |
| lifeless | I am not 100% stuck on that | 07:53 |
| lifeless | but its not a build-and-install problem | 07:53 |
| ttx | "merge conflicts issues" = solving the challenge of multiple people editing release notes in parallel changed, nothing specific to your solution (which solves it) | 07:53 |
| ttx | changes* | 07:54 |
| lifeless | ttx: my solution means they are each editing separate docs | 07:54 |
| * ttx should not type before showering | 07:54 | |
| ttx | lifeless: yes, totally | 07:54 |
| lifeless | ttx: unless they are editing the prelude or the notes on the same change | 07:54 |
| lifeless | ttx: oh, got you | 07:54 |
| lifeless | my solution is a solution. yes :) | 07:54 |
| ttx | what I meant there is: "we need to discuss more all the possible solutions to the problem (of which your proposal is a good one) | 07:54 |
| lifeless | righto | 07:55 |
| lifeless | sure | 07:55 |
| lifeless | anyhow - the reason I think this doesn't belong in pbr is that pbr is our bootstrap mechanism | 07:55 |
| lifeless | it can't have dependencies | 07:55 |
| lifeless | we can't depend on sphinx, or markdown, or anything else | 07:55 |
| lifeless | this isn't something you want running in an sdist based install | 07:56 |
| ttx | I just can't sign up to do anything, I'm almost in the pre-release pre-summit tunnel and my capacity for code writing nears zero in that period. So unless someone tells me "as long as we decide before end of month I'll get it done in the next week" I prefer to have a plan B | 07:56 |
| ttx | lifeless: so to solve the "people should be able to take any commit and have release notes" challenge you would just tag more often ? | 07:57 |
| lifeless | ttx: no, I'd say 'here is how you get release notes. 1) ...' | 07:58 |
| lifeless | ttx: if its in pbr but not running automatically (which e.g. is the case for our sphinx glue) then you still need such instructions | 07:59 |
| lifeless | ttx: plan B: put it in a file in the tree and do by hand. Lowest denominator, see how it goes. Call me when you start to die of merge conflicts. | 07:59 |
| ttx | and just include them in tagged versions ? Or also direct tagged versions users to the generation instructions ? | 08:00 |
| lifeless | ttx: I can't sign up to do anything either. But I can sign up to put that spec in an oslo specs spec and ask around for wolunteers | 08:00 |
| lifeless | ttx: so my design can generate release notes for any commit | 08:00 |
| ttx | ok, I think I have a complete picture | 08:00 |
| lifeless | ttx: users pulling stuff out of git would just run the make-my-release-notes tool | 08:00 |
| ttx | right | 08:01 |
| lifeless | ttx: users pulling out of an sdist would get the notes from whomever gave them the sdist | 08:01 |
| lifeless | (which might be a website doing stuff from cron, or whatevs) | 08:01 |
| ttx | lifeless: thanks for the update. On the stable release stuff I kinda hoped we'd more more far along but the stable team didn't exactly run with the issue | 08:03 |
| ttx | and by the time I woke up it was a bit late for revolutionary solutions | 08:04 |
| ttx | but then, incremental steps is not a bad thing | 08:04 |
| ttx | lifeless: ttyl, will shower now | 08:04 |
| lifeless | au revoir | 08:04 |
| ttx | (I'll be around for office hours in a few minutes) | 08:06 |
| *** katyafervent has joined #openstack-relmgr-office | 09:18 | |
| katyafervent | Hi all! | 09:19 |
| katyafervent | let's merge this commit to global requirements! Our ci is blocked until it will be merged https://review.openstack.org/#/c/216105/ | 09:20 |
| lifeless | why is your CI blocked? | 09:23 |
| SergeyLukjanov | dhellmann, hi, when will have stable/liberty in clients? and will it be created from the latest tag? | 09:42 |
| *** dims__ has joined #openstack-relmgr-office | 09:48 | |
| *** dims__ has joined #openstack-relmgr-office | 09:49 | |
| *** gordc has joined #openstack-relmgr-office | 11:42 | |
| ttx | SergeyLukjanov: starting end of week and yes | 12:15 |
| SergeyLukjanov | ttx, ok, thx | 12:15 |
| SergeyLukjanov | ttx, dhellmann, please, don't create branch in sahara client without my acknowledgement - we need to release one more version and it's very important - bunch of important features client support not yet merged | 12:16 |
| ttx | SergeyLukjanov: no problem, we are still working on the timeframe anyway | 12:17 |
| dims__ | ttx: dhellmann: please take a look at a script problem https://review.openstack.org/#/c/216475/ - Need it to merge the review for Oslo releases yesterday (https://review.openstack.org/#/c/216415/) | 12:51 |
| ttx | dims__: on it | 12:53 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:00 | |
| ttx | dhellmann: about liberty library timing, I think we could extend past liberty-3. The hard stop imho is when we start cutting stable branches for services, i.e. when we start issuing release candidates there. In theory that can happen any time after FF, but in practice it's likely to be FF + 2 weeks | 13:10 |
| ttx | So we have some wiggle room there | 13:10 |
| *** dims__ has quit IRC | 13:24 | |
| *** dims__ has joined #openstack-relmgr-office | 13:25 | |
| *** dims has joined #openstack-relmgr-office | 13:36 | |
| *** dims__ has quit IRC | 13:36 | |
| *** dims_ has joined #openstack-relmgr-office | 13:39 | |
| *** dims__ has joined #openstack-relmgr-office | 13:41 | |
| *** dims has quit IRC | 13:42 | |
| *** dims_ has quit IRC | 13:45 | |
| dhellmann | dims__: sorry about that, +2a | 14:56 |
| dhellmann | ttx: started late today, so I'm catching up on scrollback. It looks like you and lifeless worked out the end-of-release process question, right? | 14:57 |
| dhellmann | ttx: as far as "extend past liberty-3" do you mean for creating branches for the libraries? | 14:58 |
| *** armax has joined #openstack-relmgr-office | 15:01 | |
| ttx | yes | 15:04 |
| openstackgerrit | Merged openstack/releases: list-changes breaks because of bad start_range https://review.openstack.org/216475 | 15:05 |
| dhellmann | ttx: ok, yeah, I don't think there's any rush to create the branches | 15:05 |
| ttx | So if Oslo wants to have one extra week and do releases next week (or the week after) it's probably fine. We can leave it up to dims | 15:07 |
| dims__ | ttx: will try to hold the line and only let things in if absolutely needed | 15:07 |
| openstackgerrit | Merged openstack/releases: Oslo Releases for Aug 24, 2015 https://review.openstack.org/216415 | 15:09 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: use git describe to find the last tag https://review.openstack.org/216754 | 15:10 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: make release_postversion.sh work for unofficial projects https://review.openstack.org/216755 | 15:10 |
| devananda | dhellmann: we ran into a gate issue last night with the oslo versoined objects release, fyi. fix has been landed and the switch to post-versioning also landed this morning | 15:12 |
| dhellmann | devananda: do you need dims__ to release another oslo.vo? | 15:17 |
| devananda | I dont think so? | 15:18 |
| dhellmann | ttx, devananda : I have fixed up the release notes generation for ironic, so I can send an announcement email. Should I do that? | 15:18 |
| dhellmann | devananda: was the fix in ironic? | 15:18 |
| devananda | https://review.openstack.org/#/c/213601/ is the fix we landed | 15:18 |
| devananda | yes | 15:18 |
| dhellmann | ah, ok | 15:18 |
| dhellmann | devananda: do you need another release of ironic, then? :-) | 15:18 |
| devananda | dhellmann: it means the SHA ... right, that | 15:18 |
| dhellmann | cool | 15:18 |
| dhellmann | do you want to land my readme fix, too? https://review.openstack.org/216758 | 15:19 |
| devananda | it's only an issue in unit tests afaict | 15:19 |
| devananda | also yes, that's good. lemme see if any other bug fixes came in last night | 15:19 |
| * krotscheck grumps about the requirements gate build being flaky | 15:19 | |
| ttx | dhellmann: could your +2/APRV https://review.openstack.org/#/c/216736 I'd like to trigger a project-team-guide publication | 15:22 |
| devananda | dhellmann: should we land the gr patch which bumps oslo.service to >= 0.7 as well? | 15:23 |
| dhellmann | ttx: +2a | 15:27 |
| ttx | thx | 15:27 |
| dhellmann | devananda: if you need that as a lower bound, then yes | 15:28 |
| devananda | dhellmann: i'm rebuilding my venv to make sure, but it looks like 0.6.0 still works for us | 15:34 |
| dhellmann | morgan: do you still want keystoneauth 0.4.0? https://review.openstack.org/#/c/213573/ | 15:38 |
| dhellmann | oh, that's not as old as I thought at first | 15:39 |
| morgan | dhellmann: hm. | 15:39 |
| morgan | No. Not yet. | 15:39 |
| dhellmann | oh, ok. Want to -1 the patch until you're ready? | 15:39 |
| morgan | We might be jumping to 1.0 this week | 15:39 |
| morgan | Yeah. | 15:39 |
| dhellmann | cool, thanks | 15:39 |
| morgan | -1 on it now | 15:40 |
| *** Daviey has joined #openstack-relmgr-office | 15:47 | |
| dhellmann | devananda, ttx: I'm unclear on whether we want to be sending release notes emails about server projects. | 15:50 |
| dhellmann | devananda, ttx: Now that we're releasing whenever, it seems like something we want to do. | 15:51 |
| devananda | dhellmann: I believe swift has done this in the past | 15:51 |
| devananda | and I agree, it makes sense to start doing that | 15:51 |
| ttx | dhellmann: we should send curated messages at least | 15:51 |
| ttx | swift sends a handcrafted one which also points to the LP milestone page | 15:51 |
| ttx | I don't think we would use the same template as for libs | 15:52 |
| ttx | but something along the lines of what I posted for the integrated release / what notmyname posts for swift intermediary releases | 15:52 |
| dhellmann | devananda: do you want to write up an announcement? | 15:53 |
| dhellmann | ttx: hand-crafted makes more sense than the template thing we get for libs | 15:54 |
| devananda | dhellmann: sure | 15:54 |
| ttx | I could totally see that being replaced by the continuous release notes system from lifeless in the future though | 15:55 |
| ttx | but as for now, handmade organic notes are probably the best bet | 15:55 |
| devananda | aside from "hey look, our first semver versioned release! dont worry - it wont be our last." I'll have to think of what else to say :) | 15:55 |
| dhellmann | yes, for libs, too | 15:55 |
| dhellmann | devananda: bonus points for including the phrase "chock full of features" | 15:55 |
| devananda | hah | 15:55 |
| devananda | "not ..." :) | 15:55 |
| devananda | at least compared to what I hoped we'd have. anyhow, I'll write something up after breakfast | 15:57 |
| devananda | dhellmann: so we have two fixes in the gate right now - one for the readme, and one for mock (this one doesn't have to land, but it's ahead in the gate, and i see no reason to yank it) | 16:03 |
| devananda | dhellmann: do you want to do a 4.0.1 after those land, and then I'll notify the team to resume normal reviewing/approving? | 16:03 |
| dhellmann | devananda: now that you're switched over to post-versioning, they can resume normal operations. You can then submit a request at any time using a valid SHA to cut a release, and it doesn't have to be HEAD. | 16:05 |
| devananda | oh - great | 16:05 |
| devananda | makes sense :) | 16:05 |
| dhellmann | :-) | 16:06 |
| *** bnemec has joined #openstack-relmgr-office | 16:25 | |
| *** mestery has quit IRC | 17:14 | |
| *** mestery has joined #openstack-relmgr-office | 17:23 | |
| devananda | dhellmann: re: your comment about beta releases, it looks like swift has been doing that for a while, eg, 2.0.0.rc1 | 18:01 |
| dhellmann | devananda: I don't know the history there. | 18:02 |
| *** _sigmavirus24 has joined #openstack-relmgr-office | 18:17 | |
| *** sigmavirus24 has quit IRC | 18:17 | |
| *** _sigmavirus24 is now known as sigmavirus24 | 18:20 | |
| *** sigmavirus24 has joined #openstack-relmgr-office | 18:20 | |
| devananda | dhellmann: how did you plan to generate the README / release notes post commit? | 18:41 |
| devananda | I would expect them to be included in the release, and therefor landed before i give you a SHA | 18:41 |
| dhellmann | there's a script in the release-tools repo that we use for libraries that generates them from the git messages. That's probably not what you want for servers, though. | 18:41 |
| devananda | yea | 18:42 |
| dhellmann | there's an email thread going right now about how to deal with release notes for servers. lifeless proposed something, and I proposed using rst files under doc/source, but I don't think we settled on a solution | 18:42 |
| devananda | k | 18:42 |
| devananda | I'm going to propose a CHANGELOG for this, so at least there's something up and other cores can work with you to roll it together while I'm on leave | 18:43 |
| dhellmann | k | 18:43 |
| lifeless | devananda: please don't call it CHANGELOG | 18:57 |
| lifeless | devananda: there's already a ChangeLog autocreated by pbr | 18:57 |
| lifeless | devananda: Release notes are != to that, and the name clash is likely to cause confusion | 18:58 |
| devananda | lifeless: great. well, that's what swift uses. give me a better name and I'll use it | 18:59 |
| devananda | I'm about to hit gr, so ... | 18:59 |
| lifeless | RELEASENOTES.rst | 19:00 |
| devananda | k | 19:00 |
| devananda | dhellmann: https://review.openstack.org/216843 -- I'm going to W-1 it, please take it over or work with the ironic team to do what you need to | 19:10 |
| dhellmann | devananda: ok | 19:10 |
| *** dims__ has quit IRC | 19:25 | |
| *** dims has joined #openstack-relmgr-office | 19:26 | |
| openstackgerrit | Merged openstack/releases: add deliverables directive and source files https://review.openstack.org/215295 | 20:04 |
| *** armax has quit IRC | 20:39 | |
| stevebaker | dhellmann: do you know is there a script which checks kilo-backport-potential and updates to in-stable-kilo | 20:48 |
| *** bnemec has quit IRC | 21:05 | |
| *** bnemec has joined #openstack-relmgr-office | 21:06 | |
| *** TravT has joined #openstack-relmgr-office | 21:11 | |
| dhellmann | ttx: I threw together this test repo to experiment with lifeless' ideas: https://github.com/dhellmann/os-relnotes-test | 21:16 |
| dhellmann | stevebaker: I'm not sure, I haven't had to do that before. Did you look through the tools described in the README in the openstack-infra/release-tools repo? | 21:17 |
| stevebaker | dhellmann: I just did it manually. It looks like in-stable-kilo gets applied automatically for *some* merges to stable/kilo | 21:18 |
| lifeless | dhellmann: cool | 21:20 |
| lifeless | dhellmann: it can use the pbr API to query the version (perhaps you do that already) | 21:20 |
| dhellmann | lifeless: I'm using git describe, since it's just hacky, but yeah we could use pbr | 21:21 |
| lifeless | dhellmann: ah - you use git. It would be better not to duplicate the pbr logic here IMO. OTOH | 21:21 |
| dhellmann | I mostly wanted to prove to myself that we could ask git which release notes files had changed in which versions | 21:21 |
| lifeless | OTOH multiple languages :(. Perhaps start with pbr and we'll find some way to factor the pbr logic out for use independently eventually. | 21:22 |
| dhellmann | start with pbr for what? | 21:22 |
| dhellmann | the current version? | 21:22 |
| lifeless | yeah | 21:22 |
| dhellmann | oh, yeah, we can definitely replace that bit | 21:22 |
| dhellmann | I just did this so I didn't have to set up a full blown python project | 21:22 |
| lifeless | sure sure | 21:22 |
| lifeless | I'm not sure what you mean by checking for changed release notes files | 21:23 |
| dhellmann | like I said, the interesting part for me to solve was which note files go with which version numbers | 21:23 |
| lifeless | I don't recally my propsal needing that: its just a query of th git commit logs to look for the Iabc strings | 21:23 |
| dhellmann | "I have a pile of separate release notes, what order do they go in and how do I group them by version number?" | 21:23 |
| dhellmann | that's a requirement ttx pointed out | 21:24 |
| dhellmann | I thought it was in your proposal, too | 21:24 |
| lifeless | so, if someone edits the file Iabcdef then the version it goes in *isn't altered* | 21:24 |
| lifeless | the name of the file is the key into the history | 21:24 |
| lifeless | not the history of the file | 21:24 |
| dhellmann | hrm, true | 21:24 |
| lifeless | otherwise you can't add security notes | 21:25 |
| dhellmann | the problem with that is getting the change id in order to name the new file | 21:25 |
| lifeless | so the algorithm is, for the versions you want to generate notes, you do one big git log | 21:25 |
| lifeless | the change id on backports is the change id of the backported commit | 21:25 |
| lifeless | its preserved by git cherry-pick | 21:26 |
| lifeless | for changes to master, do a git commit, then git show, then add your file and do a git commit --amend | 21:26 |
| dhellmann | if I'm a developer creating a brand new commit that is going to have a release note, and I do that work in master, where do I get the change id? | 21:27 |
| dhellmann | I have to commit something, then get the id, then amend the commit with the release note | 21:27 |
| lifeless | yes | 21:27 |
| lifeless | or | 21:27 |
| lifeless | generate a random sha | 21:27 |
| lifeless | and put that in your commit message straight away | 21:27 |
| dhellmann | yeah | 21:27 |
| lifeless | we could easily have a tool that does this | 21:27 |
| lifeless | either path | 21:28 |
| dhellmann | lifeless: updated to track the earliest version that has a note, not the latest -- that avoids us having to use special filenames | 21:39 |
| dhellmann | lifeless: ideally we could use descriptive names, but even uuids that can be generated before a commit seems better, imo | 21:39 |
| lifeless | dhellmann: so that will force one git history query per file, it will be a lot slower | 21:40 |
| lifeless | dhellmann: what problem are you trying to solve by these changes to the algorithm ? | 21:41 |
| dhellmann | lifeless: no, it doesn't. One big git log. | 21:41 |
| dhellmann | lifeless: I do not want people to have to use special hash values as filenames. I want the option of a unique prefix with a slug of some sort describing it | 21:41 |
| lifeless | git log with names is slower than git log without; if you limit it to the directory of release notes it should be tolerable I guess. | 21:42 |
| lifeless | I'd want to test that on a big busy tree though | 21:42 |
| lifeless | dhellmann: ok, well - I'm happy for you to run with this | 21:43 |
| lifeless | dhellmann: I think we have different concerns in our heads; I'm happy to review what you come up with to see if I can predict problems with branches / releases etc etc | 21:43 |
| dhellmann | lifeless: do you mean asking for git to report the filenames in a commit is slower than not? | 21:44 |
| lifeless | yes | 21:44 |
| dhellmann | ok | 21:44 |
| lifeless | it has to read the tree objects | 21:44 |
| lifeless | and diff them | 21:44 |
| lifeless | and do that recursively on any diffs that are for tree objects | 21:44 |
| lifeless | until its got the names its reporting on (either all, or a sub-path) | 21:45 |
| lifeless | robertc@lifeless-z140:~/work/pbr$ time git log --name-only > /dev/null | 21:45 |
| lifeless | real 0m0.087s | 21:46 |
| lifeless | robertc@lifeless-z140:~/work/pbr$ time git log > /dev/null | 21:46 |
| lifeless | real 0m0.044s | 21:46 |
| lifeless | rougly twice as long. I didn't call this out but it was a hidden fact in my head when I sketched out the design | 21:46 |
| lifeless | and human-assigned-names wasn't a requirement, so I didn't put that in | 21:46 |
| dhellmann | nova is 0m1.292s vs 0m3.729s | 21:46 |
| lifeless | you could add a human descriptib slug to the Iabcbb style names easily | 21:46 |
| dhellmann | I guess with glob, sure | 21:47 |
| lifeless | just say its $CHANGEID(-humandataa){0,1}.rst | 21:47 |
| dhellmann | given that one of our oldest, largest, repos takes an extra second or 2 to process, I'm not sure how big of a concern it really is | 21:48 |
| dhellmann | well, say 2.5 seconds | 21:49 |
| dhellmann | I think the ease of use of allowing any filename makes up for that, since we'd save that much developer time on every new release ntoe | 21:51 |
| lifeless | what if someone renames their release note file | 21:52 |
| lifeless | like | 21:52 |
| lifeless | there is a bug in their human blurb | 21:52 |
| dhellmann | sigh | 21:54 |
| lifeless | sorry, just thinking through the ramifications | 21:54 |
| lifeless | if there is a pk of some sort there we can match on that | 21:55 |
| lifeless | and keep goingthroug the history further | 21:55 |
| lifeless | just a random slug as you say would suffice, though we'll need to test carefuly | 21:56 |
| lifeless | also sorry if I'm being grumpy | 21:57 |
| lifeless | I had a rude awakening this morning | 21:57 |
| lifeless | so I think we can make this work | 21:58 |
| lifeless | at least so far, I'll go through merge and branch scenarios in detail later today | 21:58 |
| lifeless | see if I can find things that will bite us | 21:58 |
| lifeless | (and answers to them if I do) | 21:58 |
| dhellmann | lifeless: ok, updated to handle renames | 22:06 |
| lifeless | dhellmann: cool | 22:07 |
| dhellmann | lifeless: no, you're right about needing to address these cases | 22:07 |
| dhellmann | I took your idea of the prefix, and just made it a uuid instead of the sha | 22:07 |
| *** bnemec has quit IRC | 22:07 | |
| dhellmann | we can make it something shorter, too | 22:07 |
| dhellmann | it needs to be fixed width, or have a special separate character, or something so we can find it | 22:08 |
| dhellmann | a shorter random number might be good enough | 22:08 |
| lifeless | $hex- ? | 22:08 |
| dhellmann | yeah, like 6-8 digits should be plenty | 22:08 |
| *** bnemec has joined #openstack-relmgr-office | 22:09 | |
| dhellmann | the next question is, where does this logic live and how is it invoked | 22:09 |
| dhellmann | pbr? standalone? | 22:09 |
| lifeless | standalone | 22:09 |
| lifeless | reasons | 22:09 |
| lifeless | a) we have non-python projects | 22:09 |
| lifeless | so even if we don't support them on day one, we'll need to find a way | 22:09 |
| lifeless | eventually | 22:09 |
| dhellmann | ok, cool, that lets me add a sphinx extension so we can actually put the notes in doc/source/releasenotes/notes and have a directive in doc/source/releasenotes/index.rst to generate the list | 22:10 |
| lifeless | putting it inside pbr would make that harder. Pulling /some/ stuff out of pbr is a lot easier and sensible than trying to make pbr talk puppet packaging or node package | 22:10 |
| dhellmann | and of course that path can be different for other projects, and the sphinx stuff is optional | 22:10 |
| dhellmann | right | 22:10 |
| lifeless | yeah, rst vs md syntax is trivial | 22:10 |
| lifeless | I just stuck a finger in the air in my doc | 22:10 |
| dhellmann | yeah, I'm just thinking of all the publishing machinery we already have in place | 22:11 |
| lifeless | b) pbr can't sanely have deps, and e.g. sphinx | 22:11 |
| dhellmann | right, that makes a lot of sense | 22:11 |
| lifeless | we don't put release notes in sdists today. | 22:11 |
| dhellmann | so I'll work on making this a standalone thing that pulls release notes together into files with some sensible formatting | 22:11 |
| lifeless | So I think 'when' would have multiple answers like 'at release creation for servers' | 22:11 |
| lifeless | and 'by redistributors when pulling from git' | 22:12 |
| dhellmann | I'll throw it onto github for now, and we can import it into gerrit when we have time | 22:12 |
| lifeless | and 'by a developer if they want to check their release note renders correctly' | 22:12 |
| dhellmann | once it's on pypi, we can look at adding it to our packaging jobs, I guess, if we want the output files to go into the tarballs we release | 22:13 |
| * dhellmann needs to give it a name | 22:14 | |
| *** armax has joined #openstack-relmgr-office | 22:14 | |
| lifeless | dhellmann: If we want the output files in the tarballs, then we probably want a pbr extension that looks for the command and calls it if its installed | 22:16 |
| lifeless | dhellmann: and/or a cfg setting to turn it on | 22:16 |
| lifeless | dhellmann: TBH though I wouldn't put them in the tarballs | 22:16 |
| lifeless | dhellmann: because we update them post release as CVE's and so on come in - AIUI. if we've put them in the tarball we have to ship a new tarball if that happens | 22:17 |
| lifeless | ttx: ^ am I confused? | 22:17 |
| dhellmann | lifeless: I thought the whole point of this was to get them into tarballs, but if I'm wrong maybe we just build the tool as a sphinx extension and publish the notes that way? I'll wait for ttx to chime in tomorrow. | 22:49 |
| lifeless | yah, my understanding is just to get ttx out of the loop | 22:49 |
| lifeless | so that when we *don't* do tarballs or releases on stable branches there are still relevant release notes folk can obtain | 22:50 |
| dhellmann | it's not going to be possible to build the notes without the git history, so if we don't put the finished docs in the tarballs someone is still going to have to clone the repo to build the docs themselves | 22:53 |
| dhellmann | maybe that's ok | 22:54 |
| * dhellmann has to run an errand | 22:54 | |
| lifeless | yeah, I think its ok | 22:56 |
| lifeless | right now they have to hit a web page | 22:56 |
| lifeless | if we put them in a web page when we build a tarball | 22:56 |
| lifeless | shrug, lots of answers | 22:56 |
| lifeless | none of them super hard | 22:56 |
| *** gordc has quit IRC | 23:17 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!