Re: [Python-Dev] My thinking about the development process
On Sat, Dec 6, 2014 at 7:23 PM, Wes Turner wes.tur...@gmail.com wrote:
On Sat, Dec 6, 2014 at 8:01 AM, Donald Stufft don...@stufft.io wrote:
One potential solution is Phabricator (http://phabricator.org) which is
a gerrit like tool except it also works with Mercurial. It is a fully open
source platform though it works on a “patch” bases rather than a pull
request basis.
I've been pleasantly unsurprised with the ReviewBoard CLI tools (RBtools):
* https://www.reviewboard.org/docs/rbtools/dev/
* https://www.reviewboard.org/docs/codebase/dev/contributing-patches/
* https://www.reviewboard.org/docs/manual/2.0/users/
ReviewBoard supports Markdown, {Git, Mercurial, Subversion, ... },
full-text search
https://www.reviewboard.org/docs/manual/dev/extending/
* Writing Review Board Extensions
https://www.reviewboard.org/docs/manual/dev/extending/extensions/
* Writing Authentication Backends
https://www.reviewboard.org/docs/manual/dev/extending/auth-backends/
Terry spoke about CLAs, which is an interesting thing too, because
phabricator itself has some workflow around this I believe, at least one of
the examples in their tour is setting up some sort of notification about
requiring a CLA. It even has a built in thing for signing legal documents
(although I’m not sure if that’s acceptable to the PSF, we’d need to ask
VanL I suspect). Another neat feature, although I’m not sure we’re actually
setup to take advantage of it, is that if you run test coverage numbers you
can report that directly inline with the review / diff to see what lines of
the patch are being exercised by a test or not.
AFAIU, these are not (yet) features of ReviewBoard (which is written in
Python).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker test instances (was: My thinking about the development process)
On Sat, Dec 6, 2014 at 10:11 AM, R. David Murray rdmur...@bitdance.com wrote: On Sat, 06 Dec 2014 15:21:46 +, Brett Cannon br...@python.org wrote: On Sat Dec 06 2014 at 10:07:50 AM Donald Stufft don...@stufft.io wrote: On Dec 6, 2014, at 9:11 AM, Brett Cannon br...@python.org wrote: On Fri Dec 05 2014 at 8:31:27 PM R. David Murray rdmur...@bitdance.com wrote: That's probably the biggest issue with *anyone* contributing to tracker maintenance, and if we could solve that, I think we could get more people interested in helping maintain it. We need the equivalent of dev-in-a-box for setting up for testing proposed changes to bugs.python.org, but including some standard way to get it deployed so others can look at a live system running the change in order to review the patch. Maybe it's just me and all the Docker/Rocket hoopla that's occurred over the past week, but this just screams container to me which would make getting a test instance set up dead simple. Heh, one of my thoughts on deploying the bug tracker into production was via a container, especially since we have multiple instances of it. I got side tracked on getting the rest of the infrastructure readier for a web application and some improvements there as well as getting a big postgresql database cluster set up (2x 15GB RAM servers running in Primary/Replica mode). The downside of course to this is that afaik Docker is a lot harder to use on Windows and to some degree OS X than linux. However if the tracker could be deployed as a docker image that would make the infrastructure side a ton easier. I also have control over the python/ organization on Docker Hub too for whatever uses we have for it. I think it's something worth thinking about, but like you I don't know if the containers work on OS X or Windows (I don't work with containers personally). (Had to fix the quoting there, somebody's email program got it wrong.) For the tracker, being unable to run a test instance on Windows would likely not be a severe limitation. Given how few Windows people we get making contributions to CPython, I'd really rather encourage them to work there, rather than on the tracker. OS/X is a bit more problematic, but it sounds like it is also a bit more doable. On the other hand, what's the overhead on setting up to use Docker? If that task is non-trivial, we're back to having a higher barrier to entry than running a dev-in-a-box script... Note also in thinking about setting up a test tracker instance we have an additional concern: it requires postgres, and needs either a copy of the full data set (which includes account data/passwords which would need to be creatively sanitized) or a fairly large test data set. I'd prefer a sanitized copy of the real data. FactoryBoy would make generating issue tracker test fixtures fairly simple: http://factoryboy.readthedocs.org/en/latest/introduction.html#lazyattribute There are probably lots of instances of free-form usernames in issue tickets; which some people may or may not be comfortable with, considering that the data is and has always been public. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
This lists the ReviewBoard workflow steps for a pre-commit workflow:
https://www.reviewboard.org/docs/manual/dev/users/getting-started/workflow/
On Sat, Dec 6, 2014 at 7:55 PM, Wes Turner wes.tur...@gmail.com wrote:
On Sat, Dec 6, 2014 at 7:23 PM, Wes Turner wes.tur...@gmail.com wrote:
On Sat, Dec 6, 2014 at 8:01 AM, Donald Stufft don...@stufft.io wrote:
One potential solution is Phabricator (http://phabricator.org) which is
a gerrit like tool except it also works with Mercurial. It is a fully open
source platform though it works on a “patch” bases rather than a pull
request basis.
I've been pleasantly unsurprised with the ReviewBoard CLI tools (RBtools):
* https://www.reviewboard.org/docs/rbtools/dev/
* https://www.reviewboard.org/docs/codebase/dev/contributing-patches/
* https://www.reviewboard.org/docs/manual/2.0/users/
ReviewBoard supports Markdown, {Git, Mercurial, Subversion, ... },
full-text search
https://www.reviewboard.org/docs/manual/dev/extending/
* Writing Review Board Extensions
https://www.reviewboard.org/docs/manual/dev/extending/extensions/
* Writing Authentication Backends
https://www.reviewboard.org/docs/manual/dev/extending/auth-backends/
Terry spoke about CLAs, which is an interesting thing too, because
phabricator itself has some workflow around this I believe, at least one of
the examples in their tour is setting up some sort of notification about
requiring a CLA. It even has a built in thing for signing legal documents
(although I’m not sure if that’s acceptable to the PSF, we’d need to ask
VanL I suspect). Another neat feature, although I’m not sure we’re actually
setup to take advantage of it, is that if you run test coverage numbers you
can report that directly inline with the review / diff to see what lines of
the patch are being exercised by a test or not.
AFAIU, these are not (yet) features of ReviewBoard (which is written in
Python).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
