Re: [Python-Dev] My thinking about the development process
On Sat, Dec 6, 2014 at 7:23 PM, Wes Turner wrote:
>
>
> On Sat, Dec 6, 2014 at 8:01 AM, Donald Stufft 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
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 wrote: > On Sat, 06 Dec 2014 15:21:46 +, Brett Cannon wrote: > > On Sat Dec 06 2014 at 10:07:50 AM Donald Stufft > wrote: > > > On Dec 6, 2014, at 9:11 AM, Brett Cannon wrote: > > > > > >> On Fri Dec 05 2014 at 8:31:27 PM R. David Murray < > [email protected]> > > >> 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 [email protected] 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 wrote:
>
>
> On Sat, Dec 6, 2014 at 7:23 PM, Wes Turner wrote:
>
>>
>>
>> On Sat, Dec 6, 2014 at 8:01 AM, Donald Stufft 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
>
