Re: Review Board 1.0 alpha 1 released
Awesome, thanks for all your hard work! -- Arthur Kalmenson On Mon, Jan 19, 2009 at 5:50 AM, Christian Hammond chip...@chipx86.com wrote: Hey everyone. We've released Review Board 1.0 alpha 1 tonight. This is basically a snapshot of tonight's nightly build, which we've considered to be stable enough for an alpha release. See http://www.review-board.org/news/2009/01/19/review-board-10-alpha-1-released/. If you're using nightlies, you're going to be automatically switched over to official releases from nightlies the next time you upgrade. The Getting Started guide (http://www.review-board.org/docs/GettingStarted) has some instructions on switching back to nightlies if you prefer to use those. While we do recommend using a stable release, those of you who have been contributing in the past and feel comfortable staying on the nightlies should do so. It'll help us to stabilize for 1.0. We're going to be entering a feature freeze before too long, so if you have any feature contributions up for review that still need changes made, they probably won't make it for 1.0 unless there's an update soon. We'll get these remaining features into the release following 1.0. If it's something critical, we might take it on a case-by-case basis. And, of course, we'll definitely continue to take bug fixes. On an important note, those running a site directly out of SVN (as opposed to running python setup.py install out of SVN) are going to find your installs broken soon. We've been holding off for a long time on fixing the directory structure in the source tree, and we really need to do this before 1.0. If you're still doing this, please try to switch over to an installed setup using our rb-site tool. We'll be glad to work with you on any migration problems if they arise. Thanks to everyone who's helped out with Review Board so far. We hit both our 100th and 101st contributor tonight (counting those who have code in the tree). We really couldn't have done this without the help of the people on here reporting bugs, contributing to the code and documentation, and providing support on this mailing list. So again, thank you all. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
It would be interesting to hear from other people on this list about their workflows. I use svn here and for the most part I just work away on multiple changes in a single workspace. When I finish a particular part, I'll post a review for only those files. Once the review is done, I commit only those files and continue my changes. Another approach I was considering is to check out a new project when working on something that does not require changes in my current workspace. This will make creating patches easier and let me focus on the task at hand (instead of having other changes get in the way). We do most of our reviews by applying the patch to a fresh project to catch any missing files or other compile errors. It also lets us use our IDE to better understand and go over changes. I like the idea of using Git, it's a good suggestion. -- Arthur Kalmenson On Tue, Dec 30, 2008 at 6:35 PM, Christian Hammond chip...@chipx86.com wrote: Hi Tino, I'm working on user manuals for Review Board, which I'm hoping to finish up for 1.0. Right now, I'm about half way through a detailed Administration Guide. I'll try to keep in mind the workflows suggestion for the Users Guide. It would be interesting to hear from other people on this list about their workflows. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Tue, Dec 30, 2008 at 3:12 PM, Tino Breddin tino.bred...@googlemail.com wrote: Hi Christian, Thanks for the detailed explanation of your workflow. I was just looking into using git on the client side too, since I'm familiar with it and patch management is much easier just as you describe. Nevertheless I'd also like to see how other approaches which use subversion instead of git would work. I think having different workflows explained in the documentation on the wiki would greatly help Review Board newcomers to get into it more quickly. Having such a overview certainly helped me to more easily grasp the power and freedom of git. Tino On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond chip...@chipx86.com wrote: Hey Tino, What a lot of us are starting to do both at VMware and within Review Board is to use git as a form of patch management. Git can wrap around both SVN and Perforce, allowing us to do all our work within Git and then push to the proper VCS. My workflow is generally as follows: 1) Create a new topic branch for whatever I'm working on. In git, these are really cheap and easy to create, and you can switch the active topic branch easily, all in one single checkout. 2) Make as many commits as I need until I'm ready to post for review. 3) Make sure my topic branch is branched off of master (which should represent HEAD in your VCS, requiring a rebase to it if not). 4) Run post-review 5) After approval, squash the branch down to one commit and run git svn dcommit to push to Subversion. It seems like there's extra work in there, and there is, but it also makes for a much more flexible environment. I have right now in my one checkout of Review Board some 6 or 7 development branches I'm doing work on. Git definitely has a learning curve, but in my opinion, it's very much worth it. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin tino.bred...@googlemail.com wrote: I agree, my question isn't exactly related to reviewboard and I should have been more specific. The vcs in this use-case is Subversion. Having multiple subversion checkouts might be a solution but suffers from a lot of overhead too. Thanks for the hint about the patch- management system Quilt, I'll definitely look into that. I am wondering what good development practices evolved out of using Subversion and Review Board. Cheers, Tino On Dec 29, 11:11 pm, Christian Hammond chip...@chipx86.com wrote: Hi Tino, This greatly depends on the revision control system, and isn't really specific to Review Board. If you have separate independent changes you want to post to review, you need to do multiple checkouts or use some sort of a patch-management system (like Quilt). This is a more general issue of how you do development on multiple things at once when dealing with the same files. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin tino.bred...@googlemail.comwrote: Hi, I am wondering how you handle changes in the same file which don't really fit into the same review request. So you would have a change for which you create a review request. Then you change other things in the same file and would like to create a review request for these changes only. Is it necessary to create branches for each of the changes, wait until the review is complete, commit changes and then merge branches into trunk? Thank, Tino
Re: fix broken review
Hi Christian,
Well this would come back to my previous question about having one
repository for many projects. We have one svn repository for all of
our projects (all of them different). Each project has it's own Trac
instance, so I couldn't put a specific project's bug tracker into the
repository configuration since many projects use the same repository.
--
Arthur Kalmenson
On Mon, Dec 8, 2008 at 6:16 PM, Christian Hammond [EMAIL PROTECTED] wrote:
We usually recommend using the full URL in the repository except for the bug
number. The bug number alone then goes in the bug list for the review
request. Usually there's no more than one bug tracker ever needed for a
repository, so this works well.
Christian
--
Christian Hammond - [EMAIL PROTECTED]
VMware, Inc.
On Mon, Dec 8, 2008 at 8:54 AM, Arthur Kalmenson [EMAIL PROTECTED]
wrote:
OK, so it seems that having a full link to the ticket is bad. I added
the following URL for the bug tracker in the admin side:
http://mshlindev/web-trac/%s
Where web-trac is the root to all our Trac projects. To link to a
specific ticket I just have to put
project-name/ticket/ticket-number as the bug URL.
--
Arthur Kalmenson
On Mon, Dec 8, 2008 at 11:21 AM, Arthur Kalmenson [EMAIL PROTECTED]
wrote:
Hello everyone,
I tried to publish a review that had the full link to the Trac ticket
that the patch was for. Now I get the error below. Is there any way to
fix the review request? Is there a way to just delete it and start
again? Thank you.
P.S. I think it might have something to do with the internal server
naming (not using fully qualified domain name).
Environment:
Request Method: GET
Request URL: http://mshlindev/reviews/r/15/
Django Version: 1.0.2 final
Python Version: 2.5.2
Installed Applications:
['django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.markup',
'django.contrib.sites',
'django.contrib.sessions',
'djblets.datagrid',
'djblets.feedview',
'djblets.siteconfig',
'djblets.util',
'djblets.webapi',
'reviewboard.accounts',
'reviewboard.admin',
'reviewboard.changedescs',
'reviewboard.diffviewer',
'reviewboard.iphone',
'reviewboard.reports',
'reviewboard.reviews',
'reviewboard.scmtools',
'reviewboard.webapi',
'django_evolution']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'djblets.siteconfig.middleware.SettingsMiddleware',
'reviewboard.admin.middleware.LoadSettingsMiddleware',
'djblets.log.middleware.LoggingMiddleware',
'reviewboard.admin.middleware.CheckUpdatesRequiredMiddleware')
Template error:
In template
/usr/lib/python2.5/site-packages/ReviewBoard-0.9.dev_20081127-py2.5.egg/reviewboard/templates/reviews/review_request_box.html,
error at line 40
Caught an exception while rendering: not all arguments converted
during string formatting
30 :td class=valuespan id=target_groups
31 : {% for group in review_request_details.target_groups.all %}
32 : a href={% url group group %}{{group}}/a{%if not
forloop.last %}, {%endif %}
33 : {% endfor %}
34 : /span/td
35 : /tr
36 : tr
37 :td class=labellabel for=bugs_closed{% trans Bugs
%}:/label/td
38 :td class=valuespan id=bugs_closed
39 : {% for bug in review_request_details.get_bug_list %}
40 : {% if review_request.repository.bug_tracker %}a href=
{{bug|bug_url:review_request}} {{bug}}/a{% else %}{{bug}}{% endif
%}{% if not forloop.last %}, {% endif %}
41 : {% endfor %}
42 : /span/td
43 :td class=indented labellabel for=target_people{%
trans People %}:/label/td
44 :td class=valuespan id=target_people
45 : {% for person in review_request_details.target_people.all %}
46 : a href={% url user person %}{% if not person.is_active %}
class=inactive{% endif %}{{person}}/a{% if not forloop.last %},
{% endif %}
47 : {% endfor %}
48 : /span/td
49 : /tr
50 : tr
Traceback:
File
/usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/core/handlers/base.py
in get_response
86. response = callback(request, *callback_args,
**callback_kwargs)
File
/usr/lib/python2.5/site-packages/ReviewBoard-0.9.dev_20081127-py2.5.egg/reviewboard/accounts/decorators.py
in _check
27. return view_func(*args, **kwargs)
File
/usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/views/decorators/cache.py
in _cache_controlled
30. response = viewfunc(request, *args, **kw)
File
/usr/lib/python2.5/site-packages/ReviewBoard-0.9
fix broken review
/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py in render_node 71. result = node.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/loader_tags.py in render 24. result = self.nodelist.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py in render 768. bits.append(self.render_node(node, context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py in render_node 71. result = node.render(context) File /usr/lib/python2.5/site-packages/Djblets-0.4.dev_20081127-py2.5.egg/djblets/util/decorators.py in render 150. return self.tag_func(context, self.nodelist, *args) File /usr/lib/python2.5/site-packages/Djblets-0.4.dev_20081127-py2.5.egg/djblets/util/templatetags/djblets_deco.py in box 44. 'content': nodelist.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py in render 768. bits.append(self.render_node(node, context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py in render_node 71. result = node.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/loader_tags.py in render 111. return self.template.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py in render 176. return self.nodelist.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py in render 768. bits.append(self.render_node(node, context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py in render_node 71. result = node.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/defaulttags.py in render 148. nodelist.append(node.render(context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/defaulttags.py in render 245. return self.nodelist_true.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py in render 768. bits.append(self.render_node(node, context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py in render_node 81. raise wrapped Exception Type: TemplateSyntaxError at /reviews/r/15/ Exception Value: Caught an exception while rendering: not all arguments converted during string formatting Original Traceback (most recent call last): File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py, line 71, in render_node result = node.render(context) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/debug.py, line 87, in render output = force_unicode(self.filter_expression.resolve(context)) File /usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/django/template/__init__.py, line 559, in resolve new_obj = func(obj, *arg_vals) File /usr/lib/python2.5/site-packages/ReviewBoard-0.9.dev_20081127-py2.5.egg/reviewboard/reviews/templatetags/reviewtags.py, line 354, in bug_url return review_request.repository.bug_tracker % bug_id TypeError: not all arguments converted during string formatting -- Arthur Kalmenson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: State of Reviewboard?
I'd like to know this too :). We're using the latest version, but it'd be nice to know what the status is based on the roadmap that's up at the moment. -- Arthur Kalmenson On Thu, Dec 4, 2008 at 10:31 AM, Sebastien Douche [EMAIL PROTECTED] wrote: Hi There :), what is the dev state? Could you update roadmap wiki page and add date for each step (alpha, beta...)? I use a very old revision (btw it's works with few minor bugs) but I don't want upgrade on unstable :). Thx. -- Sebastien Douche [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
adding repositories implies one repo per project
Hello everyone, After setting up reviewboard and reading the following document: http://code.google.com/p/reviewboard/wiki/Adding_Repositories we are under the impression that reviewboard assumes there is one repository per project (with Subversion). Because our team has all of its projects in one repository, we can only have one repository and have to use a different base diff path for each review. Is there another way of doing this? -- Arthur Kalmenson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
