Add provider compliance events to Events appendix.

[cben]

These events have appeared in euwe release:
https://bugzilla.redhat.com/show_bug.cgi?id=1411337 (master)
https://bugzilla.redhat.com/show_bug.cgi?id=1411364 (euwe)

They originally were called "ExtManagementSystem Compliance" in the UI but that's a mistake, corrected to "Provider" in ManageIQ/manageiq#13388 (on master & euwe/backported).

[simon3z]

@cben who should look at this?

[cben]

Dunno, someone on the Docs team? ;-)
@suyogsainkar you've worked on extending policy docs (for container entities) a while back. Can you take a look, this is a tiny addition?

[suyogsainkar]

@cben Hi Beni, the additions are looking good to me. However, changing the base branch to Euwe picked up other commits resulting in conflicts. I've created and merged a separate PR with these changes: #231 Please close the original PR.

[cben]

Thanks.
Note when I said "These events have appeared in euwe release" I meant they're present since euwe but also on master.
So I think you'll also want this addition on docs master?

[simon3z]

Thanks.
Note when I said "These events have appeared in euwe release" I meant they're present since euwe but also on master.
So I think you'll also want this addition on docs master?

@cben yes of course, so please keep this open and get it merged. cc @suyogsainkar

[suyogsainkar]

@cben @simon3z I know it might seem confusing, but euwe is our docs master upstream in GitHub; changes there get synced with the downstream master in GitLab. Likewise, if you have a change for 4.1, submit pull requests against the upstream darga branch, which will be sycned with the downstream 4.1 branch.

[simon3z]

@cben @simon3z I know it might seem confusing, but euwe is our docs master upstream in GitHub; changes there get synced with the downstream master in GitLab. Likewise, if you have a change for 4.1, submit pull requests against the upstream darga branch, which will be sycned with the downstream 4.1 branch.

@suyogsainkar and where the F-release will be branched from?

[simon3z]

Ping @suyogsainkar
@miq-bot assign suyogsainkar

[suyogsainkar]

@simon3z My apologies for the delay in getting back. @adahms, who manages branches in the docs repo, has agreed to respond to your query.

[adahms]

@suyogsainkar Thank you for adding me to this thread!

@simon3z Thank you for your question - the 'euwe' branch has the most up-to-date content from that release, and would make a good candidate for branching for the F-release. Would that be acceptable?

@Fryguy See the above question, Jason - we will be looking to create a branch in the next week to start work on this content if possible, but I am open to branching in a different way if you have any preferences.

[Fryguy]

@adahms I didn't see your message here, but I answered you via email. For everyone else's benefit, I'll copy it here...

Master branch is the F release so I would expect PRs to master to be good enough, unless I'm missing something (This is how all of the other repos work). I'd prefer we didn't branch until all of the other repos have branched otherwise it makes our downstream mirror and tagging scripts not work.

Note that the information for planned branching for the Fine release can be found here: http://talk.manageiq.org/t/coming-soon-fine-branch/2189

[simon3z]

@Fryguy based on your comment it seems to me that this should be merged here.
Can anyone do that? (cc @adahms)

[adahms]

@simon3z - I'd be happy to take a look and merge this PR for you. I will only have time in the next few days, but will set aside some time to take a look.

[Fryguy]

@simon3z @cben Even so, the PR itself looks busted because there are a bunch of unrelated commits in the PR.

[miq-bot]

Checked commit cben@7a11322 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
0 files checked, 0 offenses detected
Everything looks good. 🍪

[cben]

Oh, b891935 from #231 is already both on euwe and master, so nothing more to do.

Apparently master was branched from euwe at 076c811.