21:01:52 <EmilienM> #startmeeting crossproject
21:01:53 <openstack> Meeting started Tue Aug 18 21:01:52 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:56 * bknudson lurks
21:01:56 <openstack> The meeting name has been set to 'crossproject'
21:01:57 <EmilienM> #link Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:01:58 <loquacities> o/
21:02:03 <EmilienM> This is my first time I'm leading this meeting, please be kind :-)
21:02:09 <mriedem> o/
21:02:09 * ttx will heckle
21:02:10 <Daviey> \o
21:02:13 <nikhil_k_> o/
21:02:16 <johnthetubaguy> o/
21:02:25 * edleafe is here but has to leave soon
21:02:26 <fungi> EmilienM: we're a gentle lot
21:02:37 <edleafe> but only for your first time
21:02:39 <jungleboyj> o/
21:02:39 <elmiko> o/
21:02:43 <EmilienM> #info Meeting Chairs still needed for September 1, September 29, and October 13
21:02:45 <gordc> o/
21:02:51 <tpatil> Hi
21:02:53 <EmilienM> like mestery said in the previous meeting "Signups appreciated!"
21:03:06 <mestery> EmilienM: +1000 :D
21:03:10 <EmilienM> #topic Team Announcements (horizontal, vertical, diagonal)
21:03:10 <EmilienM> please use #info <content>!
21:03:11 <ttx> And thanks to EmilienM who signed up for 2 slots
21:03:23 <ttx> Nothing specific from release management.
21:03:26 <ttx> Remember liberty-3 and feature freeze come in two weeks
21:03:34 <ttx> (for those stil following that)
21:03:36 <ttx> +l
21:04:06 <lifeless> EmilienM: no courtesy ping for the tc members ?
21:04:07 <EmilienM> I have a useful information: Puppet OpenStack CI is running Liberty packages in their CI - we are close to trunk now
21:04:12 <nikhil_k_> EmilienM: just fyi, I did not get a courtesy reminder. possibly some other folks didn't too
21:04:19 <EmilienM> lifeless: I copy pasted from other meetings, my bad if I missed you
21:04:19 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html
21:04:29 <fungi> mass rename of git repos from stackforge to openstack being scheduled
21:04:36 <fungi> weigh in on the thread if you have concerns/questions
21:04:37 <xarses> o/
21:04:38 <EmilienM> #info Puppet OpenStack CI bumbed to liberty
21:04:39 <mestery> ttx: 2 weeks!!!
21:04:48 <lifeless> EmilienM: you missed annegentle too
21:05:08 <ttx> mestery: I must be getting old, but time really flies
21:05:14 <EmilienM> lifeless: ok, sry for that
21:05:19 <lifeless> np
21:05:25 <mestery> ttx: Greybeards :)
21:06:19 <EmilienM> do we have any other useful and exciting team announcements?
21:06:53 <elmiko> sadly, no new api-wg guidelines this week
21:07:18 <EmilienM> I guess we can go ahead into the agenda then
21:07:33 <gordc> nods
21:07:56 <EmilienM> #topic How to generate .Z version increments on stable/liberty commits
21:07:56 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072216.html
21:08:01 <EmilienM> ttx: o/
21:08:02 <lifeless> wheeee
21:08:05 <lifeless> this'll be fun
21:08:11 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072216.html
21:08:14 <ttx> So this is about agreeing on the way forward for stable point releases
21:08:15 <fungi> go to your corners and come out swinging
21:08:20 <ttx> It feels like the recent discussion is converging toward the use of openstack/releases for stable branch releases
21:08:28 <ttx> and doing "frequent", separated point releases for every service component rather than one-per-commit
21:08:38 <lifeless> I kindof feel that we haven't actually define the constraints and success criteria
21:08:39 <ttx> The drawbacks with that option being that consumers of the stable branch are unnecessarily limited to specific tagged commits
21:08:58 <Daviey> err, not sure there was convergence on that..
21:09:04 <ttx> and we all depend on various project teams to remember to push them
21:09:24 <ttx> Daviey: ok, good!
21:09:55 <mriedem> we expect project teams to care about stable? :)
21:09:58 <fungi> it feels to me like the discussion on dropping stable point releases has circled back around to how to orchestrate stable point releases
21:10:17 <clarkb> mriedem: maybe not the entire team but surely there are a subset that care?
21:10:35 <jungleboyj> clarkb: ++
21:10:57 <Daviey> I think the question needs to be, how can we enable each commit to be a release without tainting ref tag namespace but have deterministic release versions.
21:11:11 <mriedem> don't call me shirly
21:11:21 <ttx> In Vancouver we established that frequent and/or automated releases with autogenerated release notes was the only way to sclae the stable branch point release process in bigtent world
21:11:40 <bknudson> we could keep squashing commits in stable branch until we feel like committing
21:11:52 <ttx> that leaves us with the question that Daviey eloquently put
21:11:53 <clarkb> bknudson: thats ugly particularly if something breaks and you need to bisect
21:11:58 <fungi> well, only way to scale it if the alternative of dropping them was off the table
21:12:14 <ttx> Original proposal was tagging every commit, to which clarkb objected
21:12:26 <johnthetubaguy> Daviey: what about if we just release the ones people need?
21:12:40 <mriedem> johnthetubaguy: that's totally subjective though right?
21:12:44 <Daviey> johnthetubaguy: then we are back to doing release management and cutting releases?
21:12:46 <fungi> part of this, i think, is examining the alternative implementations and determining if there's one that's not more absurd than just not making stable point releases
21:12:50 <johnthetubaguy> Daviey: true
21:13:19 <johnthetubaguy> mriedem: yeah, just trying to dream up a middle ground.... not sure that works
21:13:20 <Daviey> fungi: Sorry, can you rephrase?
21:13:32 <fungi> ttx: to be fair, the original original proposal was to stop making stable point releases
21:13:47 <mriedem> yeah
21:13:53 <ttx> fungi: but then people asked for reference points, which is a fair request
21:14:03 <mriedem> my team releases from stable when we need to, not based on community schedules
21:14:14 <johnthetubaguy> ttx: can we fix that with tooling?
21:14:16 * dims peeks in late
21:14:19 <lifeless> Daviey: why does that need to be the question ? :)
21:14:23 <fungi> Daviey: yes, i don't feel like we've yet arrived at a proposed implementation that is less crazy than a) continuing what we already do, or b) no longer doing it
21:14:36 <Daviey> lifeless: Why /doesn't/ it need to be the question? :)
21:14:36 <ttx> fungi: I guess a combination of none + some ref points could be "on-demand tagging"
21:14:50 <mriedem> ttx: that's basically what tempest does
21:14:58 <mriedem> tags for interesting points in time
21:14:58 <lifeless> Daviey: what problem does having each commit be a release solve ?
21:15:10 <ttx> At this point I'm fine with that (tagging once in a while), since it's definitely an improvement
21:15:21 <lifeless> Daviey: where release is defined as 'has a fixed well known version number suitable for uploading to a package repository like PyPI'
21:15:27 <ttx> and we need /something/ before liberty release
21:15:27 <fungi> mriedem: yep. keep in mind that a lot of what the stable branch release managers were doing was taking care of that process for the majority of projects which really only cared about their master branches
21:15:29 <johnthetubaguy> yeah, I guess on demand tagging is what I was meaning, but that means something needs doing, rather than it being automatic
21:15:38 <lifeless> Daviey: (because even though we don't upload the servers, we do upload the libs)
21:15:46 <mriedem> fungi: yeah, hence my earlier rhetorical question
21:15:53 <Daviey> lifeless: The issue is that upstream + Daviey's-secret-sauce == differnet pbr version to what upstream + lifeless's-secret-sauce is.. but 'people' compare releave version numbers
21:16:18 <clarkb> right so this is one of the major failings in pep440
21:16:21 <Daviey> (not to mention semver release requirements for dep handling)
21:16:23 <clarkb> but that ship has sailed and we did the best we can
21:16:23 <lifeless> Daviey: sure. And pbr doesn't try to solve the 'distributed version number allocation' problem.
21:16:34 <clarkb> you can ask pbr for a specific sha1 if/when necessary
21:16:49 <Daviey> lifeless: Yeah, so we need a x.x.x+y thing?
21:16:52 <ttx> Who is against "tagging once in a while", using the current openstack/releases framework ?
21:16:53 <lifeless> pbr based versions from untagged commits are simply not globally unique.
21:17:07 <lifeless> they are also not suitable for uploading to an index
21:17:10 <clarkb> lifeless: but they do have globally unique attributes that you can query
21:17:13 <lifeless> Daviey: no, that doesn't solve it
21:17:15 <lifeless> clarkb: they do
21:17:23 <clarkb> but yes doesn't solve the upload to index problem
21:17:25 <johnthetubaguy> ttx: honestly, it feels like a good starting point while we invent something better
21:17:25 <Daviey> ttx: Tagging once in a while is worst of all worlds, no?
21:17:36 <ttx> Daviey: explain why
21:17:56 <johnthetubaguy> Daviey: it reduces the release all the projects now problem
21:18:01 <ttx> Daviey: it's like not releasing + adding reference points that people ask for
21:18:01 <johnthetubaguy> (I think)
21:18:02 <lifeless> ttx: I think tagging is a key component in any route forward
21:18:10 <fungi> "tagging once in a while" implies there's someone doing that, so a prerequisite question is whether there's someone willing to do that
21:18:12 <ttx> lifeless: right
21:18:23 <johnthetubaguy> fungi: thats my biggest concern with it, +1
21:18:33 <lifeless> fungi: while True: if random()> 0.9 then git tag...
21:18:36 <Daviey> ttx: We still cut releases, but half assed?
21:18:46 <ttx> fungi: if that's the only question, we can open up to the PTLs in the crowd and ask them if their stable release liaisons would do that
21:18:50 <Daviey> So the same burden, but no gain?
21:19:03 <ttx> Daviey: no more stable release managers though
21:19:06 * lifeless is still fundamentally unsure of the problem we're trying to solve.
21:19:09 <bknudson> I watch stable for keystone and I'm willing to propose changes to releases when I think it's ready.
21:19:23 <johnthetubaguy> mriedem: do you fancy more work?
21:19:27 <ttx> Daviey: the request would come from the project teams themselves. Also automated release notes would make them cheap
21:19:31 <mriedem> there are several projects that already don't really seem to care all that much about stable, so i don't see why it matters if they don't care about tagging
21:19:33 <lifeless> what stops folk consuming stable branches consuming them if we don't 'make every commit a release' ?
21:19:36 <mriedem> johnthetubaguy: sure
21:19:46 <Daviey> ttx: And we are sure projects will drive stable cuts?
21:19:46 <lifeless> why are we doing this /at all/ ?
21:20:07 <mriedem> Daviey: they won't
21:20:08 <ttx> lifeless: because people want to be able to say "this vulnerability is fixed in X.Y.Z
21:20:10 <Daviey> lifeless: You've been in this debate before, no?
21:20:12 <mriedem> Daviey: not all
21:20:17 <ttx> and I run X.Y.Z+1
21:20:38 <johnthetubaguy> mriedem I do think you are hitting on something there about folks not caring too much about stable right now
21:20:39 <mriedem> i think of this like when we do novaclient releases,
21:20:41 <bknudson> maybe we only backport security fixes for all things
21:20:42 <ttx> so they need some reference points. At the very least around vuln fixes
21:20:43 <mriedem> we do them as needed/requested
21:20:52 <bknudson> then there would be fewer backports
21:20:56 <mriedem> bknudson: there are more than security fixes we need
21:20:59 <mriedem> like things that impact upgrades
21:21:02 <lifeless> ttx: ok, so its to distribute the ability to assess whether a security fix is included to a local version-check ?
21:21:17 <lifeless> s/security/important/
21:21:21 <ttx> lifeless: it's also about comparison between distros IIUC
21:21:36 <ttx> i.e. make X.Y.Z mean the same thing everywhere
21:21:41 <lifeless> ok. So I'd like to make an assertion.
21:21:49 <lifeless> there are two well known ways to solve this.
21:21:50 <Daviey> lifeless + ttx: So rather than say, 2015.1.5 i'd say $release + x upstream commits ~= a semver release.
21:22:04 <lifeless> A) Centrally assigned numbers.
21:22:21 <lifeless> B) the VCS DAG.
21:22:25 <nikhil_k_> umm, that is tricky
21:22:44 <johnthetubaguy> ttx: cross distro comparison is a deal breaker, +1
21:22:51 <nikhil_k_> how much would be ~ ?
21:23:18 <lifeless> Do we have agreement that we're looking at either A or B; further if we want to flatten things into 'version numbers' then B is infeasible.
21:23:28 <Daviey> cross distro comparison is overated IMO. :)
21:23:34 <ttx> lifeless: if you tell me what DAG is, maybe
21:23:38 <mriedem> Daviey: agreed
21:23:48 <lifeless> ttx: the directed acyclig graph
21:23:52 <Daviey> #link http://ericsink.com/vcbe/html/directed_acyclic_graphs.html
21:24:03 <clarkb> ttx: basically the git tree that represents the repos history
21:24:14 <lifeless> ttx: e.g. cross referencing git commits to determine if 'feature X is in my tree'
21:24:19 <johnthetubaguy> is the DAG different to your list of commits?
21:24:27 <ttx> ah, hmm
21:24:27 <lifeless> johnthetubaguy: same same
21:24:42 <Daviey> the FAG is an assured list of commits, right?
21:24:47 <Daviey> err DAG*
21:24:48 <lifeless> johnthetubaguy: DAG implies more structure, but for our needs we're looking at set membership
21:25:03 <johnthetubaguy> lifeless: for security fixes, yeah
21:25:17 <ttx> I think version numbers are the thing and downstream expects to have it
21:25:28 <ttx> err
21:25:35 <clarkb> B is something we can do today if you query package metadata
21:25:37 <ttx> I mean, are the thing upstream expects to get
21:25:40 <johnthetubaguy> lifeless: so if we give each commit a version off master, we can find that in other peoples trees, and find the number?
21:25:47 <ttx> dammit, "downstream"
21:25:59 <ttx> getting late
21:26:01 <Daviey> lifeless: Are you leading towards deterministic version numbers based on the upstream DAG?
21:26:23 <clarkb> Daviey: I don't think that is possible under pep440
21:26:36 <bknudson> don't distros all cherry-pick different patches on top of whatever we release?
21:26:39 <clarkb> because even upstream we can have >1 proposed next states
21:26:55 <Daviey> clarkb: SemVer based on upstream signed commits?
21:26:56 <lifeless> clarkb: sadly thats not preserved by e.g. dpkg or rpm
21:26:56 <ttx> bknudson: they still use our version numbers as base
21:27:25 <clarkb> Daviey: yes we can do it based on signed tags but not the raw DAG
21:27:42 <clarkb> doing it based onthe raw DAG is what PBR tried to do until the pep440 mess happened last december
21:27:45 <clarkb> then we all had a sad
21:27:49 <Daviey> ah
21:27:53 <lifeless> johnthetubaguy: thats how (B) might work. But I think its too big a mismatch vs x.y.z style numbering
21:28:11 <mriedem> ttx: i assume bknudson's point though is that regardless of version you're probably getting a different set of commits from different distros
21:28:36 <lifeless> Daviey: I'm trying to make sure I actually have a handle on everyones concerns
21:28:45 <lifeless> so here's my concern
21:28:45 <johnthetubaguy> lifeless: I was thinking it just defines the z, the rest is based off a tag, but it seems... messy
21:28:46 <ttx> mriedem: arguably with the same common base, though.
21:28:52 <lifeless> if I pull nova kilo
21:28:54 <lifeless> and do a commit
21:28:59 <mriedem> ttx: sure
21:29:14 <lifeless> that MUST NOT be confused with the next commit that lands in git.o.o/nova's kilo branch
21:29:32 <lifeless> or we've failed at the requirement that you can tell if you've got fixes from there
21:29:37 <ttx> lifeless: yes
21:30:02 <lifeless> this means that regular old commits are not sufficient, even if we changed pbr
21:30:15 <lifeless> so we're looking at centrally assigned version numbers.
21:30:17 <ttx> I see no way out of assigning version numbers through a tag. And if that results in pollution, then we should tag less often.
21:30:30 <Daviey> but equally, as a consumer from git.. i probably need to apply patches and have incrementing version numbers for my site (i don't)
21:30:30 <clarkb> lifeless: they could be if pep440 allowed a unique non sorted identifier
21:30:37 <clarkb> lifeless: but it doesn't so yes
21:30:49 <johnthetubaguy> but can't we just imply the tag from when the commit lands in master?
21:30:56 <johnthetubaguy> for every commit?
21:31:02 <johnthetubaguy> I guess I just missed a bit
21:31:02 <lifeless> clarkb: Even if pep-440 permitted that there'd be no way to distinguish the real thing from the local thing
21:31:10 <Daviey> lifeless: but yeah, central or otherwise deterministic version numbers seems to be the requirement
21:31:12 <lifeless> clarkb: so pep-440's limits don't alter this
21:31:19 <lifeless> Daviey: no, *central* specifically.
21:31:28 <clarkb> lifeless: you would be able to distinguish between the two, but not determine which is canonical
21:31:29 <ttx> Is anyone other than Daviey against the "push a tag now and then" approach ?
21:31:33 <lifeless> clarkb: right
21:31:33 <Daviey> lifeless: why do we care if Central or distributed ?
21:31:47 <lifeless> clarkb: and the canonical aspect is required to answer the 'and I have importance fix X'
21:31:53 <lifeless> clarkb: which is an input requirement
21:31:54 <clarkb> lifeless: it isn't
21:32:02 <johnthetubaguy> Daviey: comparing across distros, for security fixes?
21:32:06 <clarkb> at least it isn't required ot have that encoded in the version
21:32:18 <clarkb> lifeless: the human can compare the non sorted unique identifier against what they know to be canonical
21:32:19 <Daviey> johnthetubaguy: no, even if distributed it is still deterministic
21:32:22 <lifeless> clarkb: I'm not smart enough to see how it would, but since you agreed that we can't do whatever you're thinking of anyway, lets move on.
21:32:43 <johnthetubaguy> Daviey: OK, I am not seeing the distributed one properly right now it seems
21:32:54 <lifeless> Daviey: if its distributed anyone can allocate numbers right ?
21:33:32 <Daviey> lifeless: If pbr counts OpenStack signed tags, for example... it isn't centralised.. right?
21:33:33 <lifeless> Daviey: but there's only one source of truth for 'security fix X in nova/kilo'. So those numbers have to be unique and clearly identifiable
21:33:41 <Daviey> But whatever, this is imp' detail.
21:33:58 <EmilienM> time is running out, I suggest we close this topic shortly and maybe follow up on mailing list or during the next meeting
21:34:03 <lifeless> Daviey: signed tags in the git.o.o nova tree are centralised
21:34:11 <ttx> Daviey: so it seems you're the only one against the "tag now and then" approach. COuld you post something on ML explaining why ?
21:34:20 <ttx> And taht would be our next step forward ?
21:34:40 <ttx> (and we can move on to next topic) ?
21:34:53 <Daviey> ttx: Sure, but TL;DR is.. it is the same problem, with no additional improvement from what i can see.. Just moving the problem along to further tooling.
21:35:14 <ttx> I'll be happy to refute that on the ML. Next topic ?
21:35:35 <EmilienM> cool
21:35:58 <EmilienM> #action ttx to followup .Z version increments on stable/liberty commits on the ML
21:36:09 <EmilienM> #topic How to autogenerate release notes on stable/liberty commits
21:36:14 <ttx> #action Daviey to explain why "tag now and then" is the 4th knight of the apocalypse on the ML
21:36:15 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072315.html
21:36:21 <EmilienM> ttx: o/ again
21:36:21 <ttx> So this is the side discussion -- we need to generate release notes so that if you pick a random commit on the stable branch you still have relevant release notes there
21:36:28 <ttx> (and automate release notes creation for the point releases themselves)
21:36:34 <ttx> Daviey suggested using git notes, and I suggested driving them from commit messages and openstack/releases change content
21:36:39 <ttx> (which would allow proper code review of them)
21:36:48 <ttx> that requires developing a Gerrit plugin similar to the reviewnotes plugin, and add features to pbr to generate releasenotes from git notes.
21:37:01 <Daviey> Yeah, probably more work than is worth.
21:37:05 <ttx> But then fungi said something about git notes requiring special config
21:37:06 <lifeless> ttx: so I am concerned about git notes
21:37:33 <lifeless> ttx: if it requires special config to get git to replicate the data needed to get pbr to produce the same output in a fresh clone
21:37:42 <ttx> Daviey: I fail to have a better solution, and automated release notes are critical to make the "tag now and then" painless
21:37:43 <lifeless> then we'll be facing regular 'waah its different' requests
21:37:46 <bknudson> this could help generate release notes on master, too.
21:37:55 <lifeless> ttx: like, I'm *really* concerned.
21:38:04 <ttx> lifeless: agreed, I didn't know git notes were that encumbered
21:38:14 <lifeless> ttx: so I think we need to drill into the analysis that led you there much more carefully
21:38:20 <Daviey> fungi: can .gitnotes not support core.logAllRefUpdates or whatever it is?
21:38:23 <ttx> lifeless: isn't there some default ref space that is always exported or something ?
21:38:33 <lifeless> ttx: with an eye to acceptable compromises that will meet our needs
21:38:42 <lifeless> ttx: such as roll-forward via commits
21:39:00 <fungi> Daviey: i'm not sure what you're asking
21:39:04 <Daviey> fungi: err, .gitconfig
21:39:11 <ttx> lifeless: ok, so let me redefine problem space quickly
21:39:19 <fungi> Daviey: .gitconfig can. users would have to set it
21:39:37 <Daviey> fungi: I'm saying, can per-tree not export a git config that would pull in notes without users having to make changes
21:39:42 <ttx> * we want consumers of the stable branch (from random commit and from tagged versions) to get a valid release notes document
21:39:46 <fungi> Daviey: my comment about configuration was that by default git doesn't fetch refs/notes/* and you need to configure it locally to do so
21:39:47 <bknudson> I wouldn't be able to push the notes anyways, would I?
21:40:13 <ttx> * Some things in that document (like OSSA numbers) we only know after the commit is pushed so we need a way to retroactively fix those
21:40:25 <fungi> Daviey: it's a per remote config, not a per repo config
21:40:26 <Daviey> (i'm not that bought into notes, but it did seem an approach worth considering for this space)
21:40:32 <Daviey> fungi: ah
21:40:38 <ttx> bknudson: my proposal was to have Gerrit push them from other things that we code review
21:40:42 <ttx> see ml post
21:40:49 <ttx> referenced above
21:41:00 <bknudson> oh, cool.
21:41:06 <fungi> the git authors assume you'll pull git notes potentially from multiple remotes into differet local refspaces, and have no idea what you want them called, so punts on doing that without explicit configuration
21:41:07 <mriedem> git log --oneline --no-merges <latest release>..
21:41:11 <mriedem> couldn't we just dump that in a thing?>
21:41:17 <mriedem> when we do a new release
21:41:22 <ttx> mriedem: that's a changelog, not release notes
21:41:33 <lifeless> mriedem: a) we do
21:41:35 <mriedem> ttx: yar
21:41:37 <lifeless> mriedem: b) as ttx says
21:41:46 <Daviey> mriedem: The issue is enumerating through announcements and issues that need to be shared.
21:41:50 <mriedem> yeah
21:41:53 <lifeless> mriedem: this is what pbr creates today - https://mock.readthedocs.org/en/latest/changelog.html
21:41:56 <mriedem> processing tags etc
21:41:56 <fungi> mriedem: point being that if we need the release notes to mention something that we didn't know at the time a commit message was written, there's no way to go back and revise the commit message after merge
21:41:57 <ttx> I mean, we can also say that we don't do release notes for stable branches point releases
21:42:10 <ttx> but when we discussed that in YVR people kinda wanted them
21:42:17 <lifeless> ttx: so, what I've seen work well in the past is an in-tree data structure that can be updated via commits
21:42:20 <ttx> EVEN if we stopped doing releases at all
21:42:30 <lifeless> ttx: I don't understand why that wouldn't work.
21:42:32 <bknudson> do we have release notes for stable releases now? (I don't remember updating any)
21:42:38 <mriedem> bknudson: yeah
21:42:53 <fungi> when we discussed not doing stable point releases in yvr, some people basically said "that's okay as long as you can provide something else which is exactly like a stable point release"
21:42:54 <ttx> lifeless: so you mlean amending backports to edit an additional document ?
21:43:20 <lifeless> ttx: the simplest possible implementation is a .rst file called 'RELEASENOTES.rst' in the tree.
21:43:33 <Daviey> lifeless: merge conflicts?
21:43:36 <ttx> That was suggested on the ML and shot down, let me see why again
21:43:38 <mriedem> bknudson: e.g. https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.1
21:43:45 <ttx> Daviey++
21:43:46 <lifeless> ttx: we can obviously do something much more sophisticated to address the issues that arise from using a DVCS etc etc.
21:43:50 <lifeless> Daviey: ^
21:43:58 <lifeless> I'm not proposing the simplest possible thing
21:43:58 <Daviey> lifeless: The other issue is looking back and thining, OH DAMN - we need to document $THIS
21:44:08 <lifeless> Daviey: so you do that by editing the data structure.
21:44:19 <lifeless> Which is a commit.
21:44:31 <bknudson> we could make it so that when the commit with the release notes is merged then that gets tagged
21:44:35 <Daviey> SO rewrite history?(!)
21:44:39 <lifeless> Daviey: no
21:44:43 <lifeless> Daviey: release notes are not a changelog
21:44:47 <lifeless> Daviey: there is no conflict here.
21:45:07 <ttx> lifeless: oh, YOU were the one shooting it down. Funny heh
21:45:09 <mriedem> would be like updating the release notes wiki after kilo is released
21:45:17 <mriedem> we do that frequently
21:45:19 <bknudson> is https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.1 genereated automatically?
21:45:19 <lifeless> ttx: possibly :)
21:45:20 <Daviey> The reason i suggested notes is that it is independent of the commit itself, but tied to a commit.
21:45:22 <ttx> <lifeless> Something with the same process as ChangeLog generation today - read
21:45:22 <ttx> from git, process, output document - will be much less fragile for merges.
21:45:34 <mriedem> bknudson: don't think so, apevec created that
21:45:53 <EmilienM> 15 minutes left and we need to talk about 'Return request ID to caller" + Open Discussion
21:45:56 <johnthetubaguy> ttx: oh, merge conflicts, thats a good point...
21:46:21 <ttx> johnthetubaguy: that said lifless is right that you can build a directory structure and avoid those merge conflicts
21:46:21 <lifeless> ttx: so no
21:46:26 <lifeless> ttx: that wasn't shooting it down
21:46:30 <johnthetubaguy> ttx: I quite liked how yours has both autogenerated stuff and overrides, maybe we but the overrides in truee
21:46:34 <johnthetubaguy> ttx: oh, true
21:46:40 <Daviey> ttx: Maybe the fix is simple as, whomever +A's has responsibility for adding an entry to the wiki... Not clean IMO, but perhaps suitable?
21:46:42 <lifeless> ttx: it was pointing at needing one of the more sophisticated implementations
21:46:57 <ttx> hmm, ok, we need to clear the floor
21:46:59 <lifeless> ttx: sorry that that was unclear
21:47:07 <ttx> lifeless: how about you propose a solution there ?
21:47:11 <lifeless> sure
21:47:18 <lifeless> I think I have a handle on whats needed
21:47:21 <ttx> OK, we have a next step. Great
21:47:22 <fungi> yeah, if updates to the release notes file drive releases, then that conflicts with one tag per commit anyway
21:47:22 <jokke_> ttx: go on, we will be discussing this again in Tokyo :)
21:47:25 <johnthetubaguy> Daviey: people forget that stuff really easily
21:47:29 <lifeless> I will do so by replying to the thread
21:47:31 <Daviey> Indeed.
21:47:39 <ttx> We need that completed for Liberty release, so there is a time constraint
21:47:47 <lifeless> I don't think that a single release notes change should trigger a tag
21:47:53 <ttx> EmilienM: I think you can switch to next topic
21:47:55 <EmilienM> cool
21:48:00 <Daviey> wait..
21:48:00 <ttx> sorry we kinda overran
21:48:01 <Daviey> Action?
21:48:06 <EmilienM> #topic Return request ID to caller
21:48:13 <EmilienM> #link https://review.openstack.org/156508
21:48:16 <EmilienM> tpatil: hello
21:48:20 <tpatil> We have updated the specs to include work item to mark openstack python package as private in python-*clients as decided in the last meeting
21:48:21 <ttx> #action lifeless to document an in-tree solution without merge conflicts
21:48:34 <tpatil> Request everyone to please review the specs and give your valuable feedback
21:49:31 <tpatil> That's all I wanted to update here
21:50:10 <EmilienM> tpatil: thank you
21:50:24 <EmilienM> we have time for open discussion then
21:50:42 <EmilienM> except if there is more to talk about the current topic
21:50:47 <ttx> I guess we can spam it with extra questions on the stable point release stuff
21:51:02 <EmilienM> #topic Open Discussion
21:51:16 <EmilienM> ttx: spam enabled
21:51:58 <johnthetubaguy> the two actions we spoke about looked promising, with my optimistic hat on
21:52:01 <ttx> lifeless: one drawback of the in-tree solution is that it prevents straight backports, but I guess that's a lesser evil than writing hundreds of line of Java and relying on git notes
21:52:12 <EmilienM> I have a question - do we usually take care of actions in the following meetings? like "review past actions items"
21:52:24 <EmilienM> if not, I would like to bring it in the next meeting
21:52:30 <ttx> EmilienM: we don't, but we probably should
21:52:40 <ttx> We used to :)
21:52:45 <EmilienM> we will then :)
21:53:00 <bknudson> everything is less evil than hundreds of lines of java.
21:53:11 <elmiko> lol
21:53:28 <EmilienM> if there is nothing else to talk about, I'll let ttx go to bed and close the meeting, otherwise rise your hand
21:53:37 <ttx> EmilienM: the trick is people attend this meeting based on the agenda... and so most of the time the ACTIONed people are not around the next time
21:53:55 <ttx> when it was the allhands meeting it was easier
21:54:11 <EmilienM> :)
21:54:15 <EmilienM> I think I can close it
21:54:20 <EmilienM> thanks everyone and see you next week
21:54:20 <ttx> I think you can
21:54:25 <EmilienM> ttx: good night
21:54:27 <EmilienM> #endmeeting