[2:14pm] torarne2: hey guys, i'm evaluating crucible and got stuck on an important
         step of a review: when a review is over, how do you get the resulting diff
         so that you can apply it somewhere? Imagine a workflow where reviews are
         done based on code that's not in the upstream repo yet, and when the review
         is done and everyone is r+, you want some CI system to land it upstream,
         how would something like that be handled with Crucible?
[2:16pm] drosen: i'm not sure, but i think that fisheye/crucible treats repositories
         as read-only for the most part
[2:16pm] drosen: in other words, i think you have to commit the changes yourself
[2:17pm] drosen: but i also bet you could write a crucible plugin to do it for you
[2:18pm] torarne2: yepp, that's fine, but if you're a person (or CI system), and you
         have a review that was based on revisions from a repository + a few patches
         + an attachment. that review will combined be a diff against the upstream
         repository, but it seems crucible is only able to produce diffs for revisions
         that can be tracked back to fisheye
[2:18pm] torarne2: i want to take the whole diff, the result of the review, after
         all comments have been applied etc, and then commit that to the upstream repo

< snip >

[2:20pm] torarne2: when the review is done, how can you produce the resulting diff? of
         the combined commits, files, etc
[2:21pm] torarne2: the resulting diff is the one that all the reviewers agreed on, the
         one that they think meets all the requirements of good code, and then you
         want to land that combined diff in the upstream (guarded) repo
[2:21pm] drosen: where would this "resulting diff" come from?
[2:21pm] drosen: how would crucible infer a resulting diff from reviewer consensus?
[2:22pm] drosen: review comments are typically things like "works for me" or "fix the
         whitespace" or whatever
[2:22pm] drosen: not something that can automatically be turned into code
[2:22pm] torarne2: yepp, and then you comment "fix the whitespace", and wait for the
         author to upload a new revision that fixes that
[2:22pm] torarne2: then you complete the review because all your concerns are fixed
[2:23pm] drosen: i see, so then you ask the author to check in their changes
[2:23pm] torarne2: at that point, the moderator want to take the latests (most final)
         version of all files and get a diff
[2:23pm] torarne2: nope, the author does not have access to the upstream repo
[2:23pm] drosen: oh, i see
[2:23pm] drosen: the author is an external contributor, and the moderator is a
         project owner, i guess?
[2:23pm] torarne2: the moderator (which would in this case be a bot/CI system) would
         apply the final diff to the upstream/mainline repo

< snip >

[2:28pm] torarne2: i guess you could backtrack from a review, and somehow try to
         deduce which revisions were included into a review and then commit those
         revisions from the staging repository to the final repository
[2:29pm] torarne2: but then when the review is over, if it's based on patches, local
         changes, the original author who has access to those patches would be the
         one to commit it?
[2:29pm] drosen: well, i think there is some assumption that the developer has the
         ability to produce a patch on their own
[2:29pm] drosen: if not directly commit
[2:29pm] torarne2: right
[2:29pm] torarne2: hmm, that's kind of a showstopper for us
[2:29pm] torarne2: damn
[2:29pm] torarne2: everything else looks so sweet 

< snip >

[2:32pm] drosen: i think there's two different concepts we're talking about
[2:32pm] drosen: the review and the actual changes
[2:33pm] drosen: and the problem, in a nutshell, is that you can create a review
         from a patch, but not a patch from a review
[2:33pm] torarne2: right, the sticking point is if the author has commit rights or
         not. if he has he has the "final diff", although it would be nice if the
         review system was the authority there on what the final proposal/diff was
[2:34pm] drosen: i don't think commit rights are the sticking point
[2:35pm] drosen: it sounds to me like you really want the tool to act as an enforcer
         or gatekeeper
[2:35pm] drosen: where really nobody has commit rights but the bot
[2:35pm] torarne2: not necessarily, i guess it's more who is the authority on what
         the final diff is
[2:35pm] torarne2: if the tool is not, then you're required to have someone who is
[2:36pm] torarne2: and if that person who is authority for that particular review
         is not a committer, he would then have to somehow pass the final patch to
         someone with commits rights after the review is over
[2:36pm] torarne2: and the committer would have to trust that the patch he gets
         is === to the one that the reviewers agreed on
[2:36pm] torarne2: so yes, i would like the tool to act as, not an enforcer/
         gatekeeper, but as an authoritative source for what the final patch (the
         result of x iterations of review) is, so that if a) the author does not
         have commit rights, or b) the author has, but would like the patch to be
         automatically integrated, it would be possible to get the final patch to
         integrate from a trusted authoritative source (the review tool)
[2:36pm] drosen: i'm going to peek around crucible's jira issues and see if i can
         find anything resembling this