Multiple commits in a review request

[Barret Rennie]

Hi everyone,

I’m a student working on the Review Board project this year and will be starting work on allowing a single review request to contain a span of commits. I haven’t started working on it, but will soon.

I was wondering if anyone had any questions, comments, or suggestions on the project.

Regards,
Barret Rennie

[Stephen Gallagher]

This would be a very nice thing to see, especially for git-based
projects. I feel I should call out some of the hard problems, though:

1) Interdiffs between multiple revisions of the patch series can be
difficult, and it gets harder if patches are added or dropped from the
series.

2) For systems like git (which uses hashes instead of linear commit
IDs), it will become a lot more difficult to auto-detect which review to
use for 'rbt patch -u'

[Gregory Szorc]

As some may know, Mozilla has hacked multi-commit reviews into Review
Board. But we do it by creating a special parent review request and
allocating a new review request for each child/commit. We use extra_data
heavily along with many hooks to propagate changes to multiple review
requests where appropriate. Read more at
https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html

For core support for multi commit review requests, I'd like to see:

* UI and URL differentiation between "series" and "commits" review
requests. Throwing them all into 1 namespace is extremely confusing.
Mozilla hasn't made all the UI customizations to make it pretty yet.

* A mechanism to keep comments on each commit separate. I don't want
review comments for all commits to be combined into a single list of
comments. This would make it hard to tease apart which commit a review
comment applies to.

* A mechanism to differentiate between series-level and commit-level
reviews. Sometimes I want to leave high-level feedback for the series.
Other times I want to leave commit-level feedback.

I think you'll run into a conflict between two styles of commit
authoring: rewriting-history-as-you-go and append-at-the-end.

In rewrite-as-you-go, the commits submitted for review are the final
versions that you would like to land. Each commit is good in isolation.
When you iterate on a review, you amend your original commit and push
the new version for review.

In append-at-the-end, you treat all commits as read-only and immutable.
When you iterate on a review, you create a new commit to represent the
fix-ups and changes necessary to gain a "ship it."

Different people practice different workflows. And that's fine. But
Review Board needs an answer to it. Do you review each commit in
isolation or are you looking at the series of commits overall and ignore
the per-commit details? Do you expose different UI depending on the
commit style used? Do you squash commits before they are uploaded?

I have a theory that heavy GitHub users tend to fall in the
append-at-the-end camp. The reason is that if you rewrite history and
push (-f) to a pull request in GitHub, the comments associated with your
now-defunct commit go into this funky state where they exist, but not
really. The orphaned commits eventually get garbage collected because
Git dropped their ref and the review state associated with them is no
longer attached to source. To avoid data loss, you must
append-at-the-end rather than rewrite history. So that's what Git[Hub]
users do.

Review Board doesn't have this limitation because it stores a copy of
the diff. (Although, you may eventually lose the ability to expand
context if the underlying commit goes away.)

The key takeaway here is that I suspect the modern preference for
append-at-the-end might derive from limitations in Git[Hub]. Review
Board doesn't have this severe data loss limitation. Furthermore,
another DVCS, Mercurial, can track the "evolution" of commits during
history rewriting. Mozilla's RB-based code review tool leverages these
markers, allowing RB to intelligently map reordered commits via history
rewriting to the appropriate existing review request, preserving review
history. It "just works."

Anyway, I'm biased towards the "reviewers should review what you want to
land" and the "your repository should be per-commit bisectable." I don't
like seeing these fixup commits because that information can clearly be
captured in intradiffs. The commits often touch code that won't be in
the final landing state anyway, so why are you wasting my time making me
understand N versions of the code when I could be looking at a smaller
set? That being said, I understand a large portion of the population
codes like that. Furthermore, Mercurial might be the only system that
will intelligently "force push" with history rewriting. I wouldn't like
to see RB support just one of these workflows.

I think a clever way out might be to prefer the rewrite-as-you-go and
add an "upload --squashed" option for the append-at-the-end crowd.

Good luck!

[Ben Cooksley]

Don't know about the other DVCSes, but Git certainly doesn't.  Makes writing Git hooks a bit of a pain sometimes.

You'll need to rely on metadata in the commit message or have it supplied on the command line of rbt if you want to support a rebase based git workflow.

>
> I think a clever way out might be to prefer the rewrite-as-you-go and add an "upload --squashed" option for the append-at-the-end crowd.
>
> Good luck!
>
>

> --
>
> --- You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[James Graham]

On Wednesday, 19 November 2014 20:56:59 UTC, Gregory Szorc wrote:

 

The key takeaway here is that I suspect the modern preference for
append-at-the-end might derive from limitations in Git[Hub]. Review
Board doesn't have this severe data loss limitation. Furthermore,
another DVCS, Mercurial, can track the "evolution" of commits during
history rewriting. Mozilla's RB-based code review tool leverages these
markers, allowing RB to intelligently map reordered commits via history
rewriting to the appropriate existing review request, preserving review
history. It "just works."

I think that — hg with the evolve extension enabled notwithstanding — there are legitimate reasons to want to retain the history on a review branch up to the point at which it is landed. One reason for this is that a single review need not be the work of a single user. Consider something like [1]; this was a patch to implement a cross-tree change that eventually got commits from four different authors. If each author was continually squashing their commit then (with git) this kind of collaboration would be very difficult because you would lose the ability to merge. It is my experience that wanting to collaborate on review branches is a very common scenario when it is possible and systems where this is difficult (e.g. GitHub setups where everyone is working in a private fork) can be very frustrating.
 
I also believe that the ergonomics of having to manually squash a patch N times after each round of review are poor compared to squashing once at the end of the review.

Therefore I think it's important that the reviewboard solution doesn't prioritize the workflow where each commit is a seperate thing that will land at the expense of the workflow where later commits are amendments to the earlier work in the review.

Anyway, I'm biased towards the "reviewers should review what you want to
land" and the "your repository should be per-commit bisectable." I don't
like seeing these fixup commits because that information can clearly be
captured in intradiffs. The commits often touch code that won't be in
the final landing state anyway, so why are you wasting my time making me
understand N versions of the code when I could be looking at a smaller
set?

As long as you can view arbitary sequences of commits squashed together, I don't think you need to understand each individual commit, if you don't want to. But, at the same time, there are considerable advantages to having access to each commit. For example if one gets a patch with some formatting problems and some functionality problems, one might ask the author to followup with two commits; one to fix the formatting errors and one to fix the functional problems. Being able to review these two changes independently is useful even though they will be squashed together in the final commit that lands. [2] has a somewhat extended example of this including a "Fix Formatting" commit and a general style where each commit to the review fixes a single raised issue. AIUI ReviewBoard — at least in the Mozilla setup — is currently lossy in this regard because commits get squashed together into "patches" unless you are careful to always push one at a time.

I think a clever way out might be to prefer the rewrite-as-you-go and
add an "upload --squashed" option for the append-at-the-end crowd.

I really don't want the commits in the review repository, or the intradiffs exposed in the UI, to be different to the commits in my local branch. That would negate the advantages of the append model for multi-user workflows and splitting the response to review comments into internally meaningful chunks.

[1]  https://critic.hoppipolla.co.uk/r/3133
[2] https://critic.hoppipolla.co.uk/r/3002

[John Lee]

On Wed, 19 Nov 2014, Gregory Szorc wrote:

> The key takeaway here is that I suspect the modern preference for
> append-at-the-end might derive from limitations in Git[Hub]. Review Board
> doesn't have this severe data loss limitation. Furthermore, another DVCS,
> Mercurial, can track the "evolution" of commits during history rewriting.
> Mozilla's RB-based code review tool leverages these markers, allowing RB to
> intelligently map reordered commits via history rewriting to the appropriate
> existing review request, preserving review history. It "just works."

As a fellow rewrite-as-you-go-er, but a git user who is not familiar with
mercurial, do you have a reference that explains this for somebody like
me?


John

[John Lee]

On Thu, 20 Nov 2014, Ben Cooksley wrote:

> Don't know about the other DVCSes, but Git certainly doesn't. Makes
> writing Git hooks a bit of a pain sometimes.
>
> You'll need to rely on metadata in the commit message or have it supplied
> on the command line of rbt if you want to support a rebase based git
> workflow.

I hope that any support would leave the way open to multiple ways of
specifying this (maybe including some that don't exist yet in git, but
might do later).

I had always envisaged experimenting with different ways to do it, with as
much flexibility as possible -- e.g. using one topgit branch per final
commit sometimes, other times having some sort of formatted commit
messages as you say, or something external. No doubt there are other ways
too. It'd be great if reviewboard command line tools made it easy to code
that sort of thing up.

I do find the way I use git varies depending on the particular thing I'm
working on, and the best thing about reviewboard is its flexibility.


John

[Gregory Szorc]

http://evolution.experimentalworks.net/doc/

tl;dr is that instead of merely rewriting commit SHA-1s and throwing the
old history away, Mercurial will record a marker saying "commit X
morphed into commit Y via Z." When something like the review tool sees
Y, it can ask Mercurial for all logical predecessors of Y, find X, see
there is a review request for X, and upload Y on top of X. Mozilla's RB
deployment does this.

While the evolve extension is marked as unstable, that really means the
API (including commands) will change. The tracking of changeset
"evolution" is in the core of Mercurial and is pretty stable. I've been
using evolve for over a year without any significant problems.

[Stephen Gallagher]

I'd just like to revive this thread. John, is there any chance you've
put together a design or started work in this area that we could see?
This is exciting (and needed) work for a lot of us, and I at least would
like to see how far it's gotten.

[Christian Hammond]

Just an FYI, we've just hired Barret Rennie, a student from last semester's UCOSP, who has impressed us with a number of contributions that are soon being released in RBTools 0.7 and Review Board 2.5 beta.

His current task is to work on DVCS support for Review Board and RBTools. It's still young, but he's making good progress on it.

CC'ing him on this thread.

Christian

--
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com

[John Lee]

On Thu, 8 Jan 2015, Stephen Gallagher wrote:

> I'd just like to revive this thread. John, is there any chance you've
> put together a design or started work in this area that we could see?
> This is exciting (and needed) work for a lot of us, and I at least would
> like to see how far it's gotten.

Sorry, I haven't, and not likely to.

Would love to see somebody work on it of course! For me features like
integration with github etc. are just nice-to-have, but reviewing multiple
commits is fundamental.


John

[Swati]

Hi,

It would be really awesome. We usually do more than one check-in for a particular requirement. It's very difficult to create more than one Review Board Request for just a single and small requirement. Even, For Reviewer tough to consolidate.

How are we planning to implement. It will be a really good feature added to the Review Board.

Thanks and Regards,

Swati

[John Lee]

+1 on awesomeness

A change like this is obviously completely central to reviewboard. I
assume you'll be discussing plans here first?

This is stating the obvious and/or repeating what I've said here before
but:

* Everybody will compare your UX with github pull requests

* The hard part is to work towards an equally smooth process while
retaining reviewboard's flexibility towards the many different workflows
used by different projects.


John

[Barret Rennie]

Hi all,

Since there's been some activity on this thread lately, I thought I'd chime in. I'm Barret and Bean Bag brought me on board this January. Since then, I've been spending most of my working hours on developing the multiple commits per review request feature (or what I’m calling “commit histories” because the former is a mouthful).

Progress is currently being made to this feature on the dvcs branch of both Review Board and RBTools. It is still in the early stages, but it is currently possible to put multiple commits into Review Board (assuming that they all can be applied cleanly on the tracking branch). This issue is currently being addressed. Once all the basics of the features have been sorted out, there will be more activity on this list discussing plans for this feature.

Since I'm spending most of my time on this feature, you can alwas take a peak at my active review requests (https://reviews.reviewboard.org/users/brennie/) for an idea of how the feature is progressing -- and feel free to be critical. However, I'll try to be proactive about posting to this list.

One of the first things I've worked on is an initial UI for displaying the list of commits attached to a review request in the request itself, change descriptions, and in the diffviewer. The following review requests have some attached screenshots that show what it currently looks like:

- https://reviews.reviewboard.org/r/6931/
- https://reviews.reviewboard.org/r/6933/

I know that the UI is going to need a lot of love to make this feature usable, so if anyone has any suggestions on ways to improve it, drop a line here and we can discuss it.

Regards,
Barret

[Oleg Marchuk]

Hi, Barret

Can you update us with status?

We'd like to you reviewboard and just found it does not support multiple commits reviews...

Regards,
Oleg

[Christian Hammond]

Hi Oleg,

Let me give you a quick, high-level status report, and Barret can go into more detail on the specifics.

The multi-commit/DVCS support is scheduled for 3.0. A lot of work has gone into it, and we have more to do. This is a major, major project, as Review Board was designed in a time when Subversion/Perforce were the source code management systems of choice.

This work is on-going for 3.0, but 3.0 is *not* the next release. We are working on a 2.6 release, which features a number of things needed for a range of code review workflows and integrations, such as:

* A framework for building customizable integrations for services (like Slack, HipChat, automated code review services, etc.) in a way that would allow multiple groups in a company to have their own integrations with their own configurations

* API and UI for attaching things like build/automated code review statuses to review requests and updates, to make automated code review fit better into a workflow, and to make it easier to build that sort of solution

* Better/faster search support

* Native desktop notifications for updates on review requests

* Support for using in-house avatar services, rather than requiring gravatars

* Ability to re-assign ownership of review requests

* Support for generic comments not tied to any particular bit of code (with support for opening issues)

* Other capabilities for extension authors, such as the ability to modify/add actions (like Close, Upload Diff, etc.) on review requests, attaching private data to review requests/reviews/etc., and more.

Some of this may be split into a 2.7 release. We're aiming for a 2.6 beta by the end of Q1 2016. We're hoping to keep these release pretty small, and a lot of work has already gone into the above feature set.

While this is happening, though, work is continuing on 3.0. Again, this is a major release, and we want to ensure it's done right and is well-tested. What we have working now is pretty awesome, but it's not ready for the world yet. It will be worth the wait, though.

In the meantime, what some do is post a review request per commit, and link them together with the Depends On feature. That gives the ability to review the individual bits of a project, though it does result in many review requests.

Christian

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

[Oleg Marchuk]

Thanks, Christian!

Do you have any ETA for version 3.0?

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

[Christian Hammond]

Hi Oleg,

It's going to be a while. Certainly not in 2016. We have at least one major release before 3.0 is the focus. Still laying the groundwork for everything we'll need to make 3.0 happen. It'll be worth it, though.

Christian

[Dan Collier]

Hi!  Was this feature ever completed?  I'm using version 3.0.6 that I got from the Azure Marketplace and I'm not seeing anything like the UI samples posted in Barret's work item for this feature.  Thanks!

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Christian Hammond]

Hi Dan,

It's being actively developed right now. We're aiming for a September/October release, with initial betas appearing in a month.

Christian

--
Christian Hammond

President/CEO of Beanbag

Makers of Review Board

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

[Dan Collier]

Great!  If you need beta testers, I'd be happy to help.  Also, posting about it on here may get you some more testers.

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

[Christian Hammond]

Thanks! We’ll be sending out an announcement when the beta is ready. As a heads up, beta 1 won’t have all the UI and features we have planned, and an in-development branch of RBTools might be required. We’ll provide some instructions on what’s needed.

Christian

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Daniel]

Hi Christian and all,

some questions concerning this really nice feature!

a) would this feature make it possible to create a workflow like i asked for in https://groups.google.com/forum/#!topic/reviewboard-dev/rFjm7gI0XIs ?

b) would this feature even make the idea in a) obsolete as it is more easy to select the revisions to add to a review via the planned GUI?

and as a third question with sadly rather small hopes concerning a positive answer.

c) will you be able to help Stephen Gallagher in his endeavour to make available the 3.x versions as rpms via yum (he states here that it is not easy to get Reviewboard 3.x up and running in Redhat https://groups.google.com/forum/#!topic/reviewboard/mSQPKhkKmMw)

I am destined to install Reviewboard on Redhat and as such i am currently thumbing my nose at all these shiny nice additions since the version 2.5.17 i am allowed to install there via yum. And this here supposedly would really be a benefical addition worth upgrading to!

Thank you for all your efforts!

cheers 

Daniel

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Hammond]

Hi Daniel,

First off, I'm sorry I never got back to your original request. Some things on the mailing list sometimes slip by.

The workflow in that post is doable today via the API by following the same logic RBTools uses. Basically, if you want to post an existing commit that's pushed upstream for review, you POST to /api/review-requests/ to create a review request and provide the following bits of data:

    commit_id=<SHA>

    create_from_commit_id=true

    repository=<repository name>

If you want to upload a custom diff instead, then you would provide the repository= one and then POST to /api/review-requests/<id>/diffs/ with

    path=<diff content and filename>

    parent_diff_path=<diff content and filename>

That's a very simplistic view of that, but the API docs talk a bit more about it. Best way to interact with the API is using RBTools's Python API. For curl, you'll have to do a bit more work, but if you just want to post an existing commit, the former will be fairly easy.

None of that has anything to do with DVCS, though. Just wanted to answer that bit for you first :)

For b), we're not currently going to add multi-revision selection to the New Review Request page, but probably will revise that down the road. *Most* users who post to Review Board use RBTools, and the commit browsing in the New Review Request page is more for simpler use cases.

For c), I'm not sure of the current status there. This is not a Review Board issue exactly, but rather a packaging issue, which I think is being solved now? Basically, we need some older versions of some modules for very good reasons I don't want to go into at the moment (various compatibility... things...) and this makes packaging a bit harder. I think that's being addressed through a new modular packaging system in Fedora. Stephen can go into details more.

Christian

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---

You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 
Christian Hammond - chri...@beanbaginc.com
Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Christian Hammond
President/CEO of Beanbag
Makers of Review Board

--

---
You received this message because you are subscribed to the Google Groups "Review Board Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Daniel]

Thank you for your really quick reply! 

For a) let me thank you for your help, i will play around with that and see how far it gets me :) and for c) I will, if i may, reference this message in an answer i will post to the thread where Stephen posted his reply. Maybe this is already solved and i just did not search well enough. That would be grrreat!

cheers Daniel

Hi Oleg,

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "reviewboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard-dev/2MuigbF_-X8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to reviewboard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

King Oleg
----
   http://kingoleg.livejournal.com/

--

---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-dev+unsubscribe@googlegroups.com.