Re: ReviewBoard 2.0beta2 for Fedora is now (semi-)available!
On 03/03/2014 10:43 AM, Stephen Gallagher wrote: On 01/23/2014 05:33 PM, Christian Hammond wrote: Thanks, Stephen! That's above and beyond. Hope this makes it easier for some of you to try out the betas. We're making good progress on a third beta/RC, so keep the feedback coming! Christian On Thursday, January 23, 2014, Stephen Gallagher step...@gallagherhome.com mailto:step...@gallagherhome.com wrote: I have put together a testing repository of ReviewBoard 2.0 for interested parties to experiment with. This has not yet been committed to the standard Fedora repositories (due to it's beta nature). I am instead offering a COPR (Collection Of Package Repositories; Fedora's equivalent to Ubuntu's PPAs) for the 2.0 beta series. You can find this repository at http://copr.fedoraproject.org/coprs/sgallagh/ReviewBoard2/ and install either the Fedora 20 or Rawhide repository files by downloading them to /etc/yum.repos.d/ and then running 'yum install ReviewBoard' (or 'yum update ReviewBoard'). As this is pre-release software, PLEASE do not use this on a production system. Also, please do not file bugs against the Fedora package. Any issues encountered with ReviewBoard should be filed in the upstream tracker (except packaging issues which should be directed to me). If you're interested in trying it out, please give it a go! I spent the weekend getting this COPR repository up and running with the latest ReviewBoard beta 3. Please give it a try and see how things work. It should hopefully make it easier for you to try out Beta 3. Instructions are the same as before. Also, I added a new (Fedora-specific) feature in here. I've added a systemd snippet for ReviewBoard that will have it automatically perform 'rb-site upgrade --all-sites' when starting up the apache webserver. Never again worry about forgetting to run the upgrade by hand! Just make sure that /etc/reviewboard/sites is populated with the site path (which is done automatically by 'rb-site install' since 1.7.13). Previous versions of the Fedora package did this during package install, but that's not necessarily safe, particularly if the package upgrade happened on a decommissioned system. So now it only runs at apache startup. I plan to get this into Fedora Rawhide (which will become Fedora 21) soon. I'm just waiting for the Django maintainer to land 1.6.2 in the repository. Hot on the heels of Beta3, I now have RC1 up in this COPR. If you are already using it, a 'yum update' will move you to RC1. The instructions above still apply for new users. -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Looking to talk to a few happy Review Board users
On Thu, Mar 6, 2014 at 4:45 PM, Christian Hammond christ...@beanbaginc.comwrote: We have a lot we want to do in this coming year, both on the open source and commercial fronts. Chris, Do those plans include anything re Gerrit? Much as I love RB's UI I have given up (at least for now) having my company adopt RB because Gerrit's gatekeeper functionality is more important to us. I wonder whether you have given any thought to how one might substitute RB for Gerrit's code review component. /john -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Looking to talk to a few happy Review Board users
Hi Chris, I was impressed by RB and still looks great for our needs but the integration with TortoiseHg is bad. I would say it's not working at all. What I was hoping to acomplish and hoping to push to the client as the new way of ensuring the code quality (by not allowing merges until the review is approved) is not possible as long as RB cannot be integrated with TortoiseHg (the client is using mercurial). I believe you have to take control of these integration points to ensure commercial success of RB. I'm looking forward for the 2.0 version and hope that some day I'll be able to show our client a tight integration between code review, mercurial and CI server. Thanks, Simo -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Looking to talk to a few happy Review Board users
It does include DVCS support and new hooks for enforcing review request approval before commit. Which features specifically are you wondering about? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Fri, Mar 7, 2014 at 6:47 AM, John Yates j...@yates-sheets.org wrote: On Thu, Mar 6, 2014 at 4:45 PM, Christian Hammond christ...@beanbaginc.com wrote: We have a lot we want to do in this coming year, both on the open source and commercial fronts. Chris, Do those plans include anything re Gerrit? Much as I love RB's UI I have given up (at least for now) having my company adopt RB because Gerrit's gatekeeper functionality is more important to us. I wonder whether you have given any thought to how one might substitute RB for Gerrit's code review component. /john -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Performance Issues (Was Re: RB server upgrade from 1.6.1 to 1.7.4)
Sorry for the late response. I missed this reply. For Apache settings the worker and prefork configurations are the exact same between the two vms: # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 100 /IfModule # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves IfModule worker.c StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 /IfModule *Symptoms from our old production vm:* Previously, only about 2-3 times a day at random times, we would get a build of Apache processes that would hit the server at the same time, which results in the load average on top going up to 100-200 in the worse case scenario. During this time, any operations done in the website are extremely slow and often times users will report not receiving an email after a publish. Since then, we've increased the sendmail Queue and Refuse limits from their default values of (12 and 15) to (20 and 150) respectively. The stats on this vm were: - 10 GB RAM - 23 GB Swap - 4 Cores - RHEL 5.3 - Red Hat Enterprise Linux Server release 5.3 (Tikanga) - Server version: Apache/2.2.3 *Symptoms on our new production vm:* We moved the production to RHEL6.4 as recommended by our IT team and have since been noticing that we we get these stalled processes more often and users tend to notice the performance hits much more. Another odd thing that we noticed from our performance monitoring tool Zenoss is that the IO spikes on writes every 5 minutes, which was on the case previously (screenshots attached). The stats on this vm were: - 16 GB RAM - 4 GB Swap - 4 Cores - Red Hat Enterprise Linux Server release 6.4 (Santiago) - Server version: Apache/2.2.15 (Unix) We're trying a lot of different things on our end, but if you have any ideas or if anyone has seen this issue, it would help. https://lh4.googleusercontent.com/-L5GVIinnSbo/UxpXxkdzJDI/Ckg/Aq9DYWW6AXs/s1600/Screen+Shot+2014-03-07+at+3.35.13+PM.png https://lh6.googleusercontent.com/-7FD3HifikjY/UxpXjy3QUwI/CkY/BFO-tGDUwoE/s1600/Screen+Shot+2014-03-07+at+3.33.09+PM.png Ze On Thursday, March 6, 2014 8:21:00 PM UTC-8, Christian Hammond wrote: Okay, well, I was hoping it'd be simple :) Can you give me some examples of operations that are very slow, and operations that remain fast? Or does everything basically slow to a grind? How do the Apache settings (worker vs prefork, and their config) compare between installs? Christian On Thursday, March 6, 2014, Ze Xiao ilackno...@gmail.com javascript: wrote: Thanks for the quick reply. Yes, memcached is running. Here is what I see from the Admin Server Cache page I've got it running on two different vms, which I've obfuscated as VM1 and VM2 SERVER CACHE Cache backend: django.core.cache.backends.memcached.CacheClass vm1 Memory usage: 1.8 GB Keys in cache: 61079 of 257077 Cache hits: 5289571 of 5458860: 96% Cache misses: 169289 of 5458860: 3% Cache evictions: 139881 Cache traffic: 10.2 GB in, 27.9 GB out Uptime: 3683047 seconds vm2 Memory usage: 1.8 GB Keys in cache: 54978 of 401980 Cache hits: 5999634 of 6277198: 95% Cache misses: 277564 of 6277198: 4% Cache evictions: 307751 Cache traffic: 16.8 GB in, 26.2 GB out Uptime: 938019 seconds On Thu, Mar 6, 2014 at 5:20 PM, Christian Hammond chip...@chipx86.comwrote: Hi Ze, Those warnings are probably unrelated. I want to get a better sense of the performance problems. First thing I want to check is that your server is properly accessing and using memcached. If you log into the admin UI, do you see any stats on memcached, and any keys stored in the cache? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Thu, Mar 6, 2014 at 4:52 PM, Ze Lin Xiao ilacknormal...@gmail.comwrote: Hi Christian, We're facing some pretty bad performance issues on our production system after we moved our application to a different
Re: Performance Issues (Was Re: RB server upgrade from 1.6.1 to 1.7.4)
Hi Ze, The spikes every 5 minutes are interesting. Sounds like a cronjob or something, perhaps? Are you using search indexing? What are you using for the database? Remind me what version of RB you guys are using? - Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Fri, Mar 7, 2014 at 3:36 PM, Ze Lin Xiao ilacknormal...@gmail.comwrote: Sorry for the late response. I missed this reply. For Apache settings the worker and prefork configurations are the exact same between the two vms: # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 100 /IfModule # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves IfModule worker.c StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 /IfModule *Symptoms from our old production vm:* Previously, only about 2-3 times a day at random times, we would get a build of Apache processes that would hit the server at the same time, which results in the load average on top going up to 100-200 in the worse case scenario. During this time, any operations done in the website are extremely slow and often times users will report not receiving an email after a publish. Since then, we've increased the sendmail Queue and Refuse limits from their default values of (12 and 15) to (20 and 150) respectively. The stats on this vm were: - 10 GB RAM - 23 GB Swap - 4 Cores - RHEL 5.3 - Red Hat Enterprise Linux Server release 5.3 (Tikanga) - Server version: Apache/2.2.3 *Symptoms on our new production vm:* We moved the production to RHEL6.4 as recommended by our IT team and have since been noticing that we we get these stalled processes more often and users tend to notice the performance hits much more. Another odd thing that we noticed from our performance monitoring tool Zenoss is that the IO spikes on writes every 5 minutes, which was on the case previously (screenshots attached). The stats on this vm were: - 16 GB RAM - 4 GB Swap - 4 Cores - Red Hat Enterprise Linux Server release 6.4 (Santiago) - Server version: Apache/2.2.15 (Unix) We're trying a lot of different things on our end, but if you have any ideas or if anyone has seen this issue, it would help. https://lh4.googleusercontent.com/-L5GVIinnSbo/UxpXxkdzJDI/Ckg/Aq9DYWW6AXs/s1600/Screen+Shot+2014-03-07+at+3.35.13+PM.png https://lh6.googleusercontent.com/-7FD3HifikjY/UxpXjy3QUwI/CkY/BFO-tGDUwoE/s1600/Screen+Shot+2014-03-07+at+3.33.09+PM.png Ze On Thursday, March 6, 2014 8:21:00 PM UTC-8, Christian Hammond wrote: Okay, well, I was hoping it'd be simple :) Can you give me some examples of operations that are very slow, and operations that remain fast? Or does everything basically slow to a grind? How do the Apache settings (worker vs prefork, and their config) compare between installs? Christian On Thursday, March 6, 2014, Ze Xiao ilackno...@gmail.com wrote: Thanks for the quick reply. Yes, memcached is running. Here is what I see from the Admin Server Cache page I've got it running on two different vms, which I've obfuscated as VM1 and VM2 SERVER CACHE Cache backend: django.core.cache.backends.memcached.CacheClass vm1 Memory usage: 1.8 GB Keys in cache: 61079 of 257077 Cache hits: 5289571 of 5458860: 96% Cache misses: 169289 of 5458860: 3% Cache evictions: 139881 Cache traffic: 10.2 GB in, 27.9 GB out Uptime: 3683047 seconds vm2 Memory usage: 1.8 GB Keys in cache: 54978 of 401980 Cache hits: 5999634 of 6277198: 95% Cache misses: 277564 of 6277198: 4% Cache evictions: 307751 Cache traffic: 16.8 GB in, 26.2 GB out Uptime: 938019 seconds On Thu, Mar 6, 2014 at 5:20 PM, Christian Hammond chip...@chipx86.comwrote: Hi Ze, Those warnings are probably unrelated. I want to get a better sense of the performance problems. First thing I want to check is that your server is properly accessing and using
Issue 3285 in reviewboard: Case sensitive comparison between cwd and workspace root causes issues on Windows
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 3285 by marcin.m...@gmail.com: Case sensitive comparison between cwd and workspace root causes issues on Windows http://code.google.com/p/reviewboard/issues/detail?id=3285 I'm running RBTools 0.5.7 with Perforce and Windows 7 Professional. If a path to the workspace root contains capital drive letter (e.g. C:\p4\), post-review and rbt won't let me post a review. Instead I get the following error: ERROR:root:The current directory does not contain a checkout from a supported source code repository. I've identified that the problem is that a comparison between the current path (from where the rbt is called) and Perforce workspace root is case sensitive. As os.getcwd() returns lower-case drive letter, the following comparison will fail perforce.py, PerforceClient(): if not norm_cwd.startswith(norm_client_root): return None Perhaps this should be made case insensitive for Windows. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups reviewboard-issues group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-issues+unsubscr...@googlegroups.com. To post to this group, send email to reviewboard-issues@googlegroups.com. Visit this group at http://groups.google.com/group/reviewboard-issues. For more options, visit https://groups.google.com/d/optout.
Re: Issue 3221 in reviewboard: get_repository_info in perforce.py fails if norm_cwd and norm_client_root have different cases.
Comment #3 on issue 3221 by trowb...@gmail.com: get_repository_info in perforce.py fails if norm_cwd and norm_client_root have different cases. http://code.google.com/p/reviewboard/issues/detail?id=3221 Issue 3285 has been merged into this issue. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups reviewboard-issues group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-issues+unsubscr...@googlegroups.com. To post to this group, send email to reviewboard-issues@googlegroups.com. Visit this group at http://groups.google.com/group/reviewboard-issues. For more options, visit https://groups.google.com/d/optout.
Re: Issue 3285 in reviewboard: Case sensitive comparison between cwd and workspace root causes issues on Windows
Updates: Status: Duplicate Mergedinto: 3221 Comment #1 on issue 3285 by trowb...@gmail.com: Case sensitive comparison between cwd and workspace root causes issues on Windows http://code.google.com/p/reviewboard/issues/detail?id=3285 This has been fixed in git and will ship with 0.5.8 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups reviewboard-issues group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-issues+unsubscr...@googlegroups.com. To post to this group, send email to reviewboard-issues@googlegroups.com. Visit this group at http://groups.google.com/group/reviewboard-issues. For more options, visit https://groups.google.com/d/optout.
Re: Issue 3281 in reviewboard: update repository failed
Updates: Status: NeedInfo Comment #1 on issue 3281 by trowb...@gmail.com: update repository failed http://code.google.com/p/reviewboard/issues/detail?id=3281 I'm almost positive that this is related to the JSON in the extra_data field. Can you upgrade to 1.7.22 and try again? -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups reviewboard-issues group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-issues+unsubscr...@googlegroups.com. To post to this group, send email to reviewboard-issues@googlegroups.com. Visit this group at http://groups.google.com/group/reviewboard-issues. For more options, visit https://groups.google.com/d/optout.
