Not to belabor the point but:
On Nov 4, 2018, at 19:39, Sorin Sbarnea wrote:
> TBH, I don't really know how a human can check the docs if they cannot access
> them on a webserver.
It's actually trivially easy with the Python doc set because the docs were
designed to also be downloadable and
I can confirm that this is what OpenStack does. Sometimes the build artifacts
(logs, docs ...) are rotated in two weeks but this is more than enough to
perform a review. If I remember well retention is based on disk space and not
hardcoded to a number of days, which is great.
TBH, I don't
OpenStack does that on review.openstack.org PRs. If I recall correctly, the
CI produces files which are online on a static web server. Nothing crazy.
And it works. Old files are removed, I don't know when exactly.
I don't think that it matters where the static files are hosted.
Victor
Le
On 11/4/18 5:38 PM, Steven D'Aprano wrote:
> On Sun, Nov 04, 2018 at 12:16:14PM -0500, Ned Deily wrote:
>
>> On Nov 4, 2018, at 12:04, Paul Ganssle wrote:
>>
>>> Some of the concerns about increasing the surface area I think are a
>>> bit overblown. I haven't seen any problems yet in the
On Sun, Nov 04, 2018 at 05:05:07PM +0100, Stephane Wirtel wrote:
> >If I am making doc patches, shouldn't I be doing that *before* I
> >submit the PR? How else will I know that my changes haven't broken the
> >docs?
>
> You can use the web interface of Github and just add/remove/modify a
>
On Sun, Nov 04, 2018 at 12:16:14PM -0500, Ned Deily wrote:
> On Nov 4, 2018, at 12:04, Paul Ganssle wrote:
>
> > Some of the concerns about increasing the surface area I think are a
> > bit overblown. I haven't seen any problems yet in the projects that
> > do this,
You may or may not be
On 04. 11. 18 16:49, Stephane Wirtel wrote:
On 11/04, Serhiy Storchaka wrote:
04.11.18 17:00, Julien Palard via Python-Dev пише:
Considering feedback from Ned, what about building this as an
independent service? We don't really need to interface with
python.org at all, we just need some
On 11/04, Ned Deily wrote:
On Nov 4, 2018, at 10:12, Stephane Wirtel wrote:
3. On this after-noon, I have reviewed a PR, and I was in the same case,
download the PR, build python, compile the doc and run the local server.
My workflow is the following steps:
git wpr XYZ
cd ../cpython-XYZ
On 11/04, Paul Ganssle wrote:
Oh, sorry if I misunderstood the concern. Yes, I agree that putting this
under python.org would not be a good idea.
Either hosting it on a hosting provider like netlify (or azure if that's
possible) or a dedicated domain that could be created for the purpose
(e.g.
Oh, sorry if I misunderstood the concern. Yes, I agree that putting this
under python.org would not be a good idea.
Either hosting it on a hosting provider like netlify (or azure if that's
possible) or a dedicated domain that could be created for the purpose
(e.g. python-doc-ci.org) would be
On Nov 4, 2018, at 12:04, Paul Ganssle wrote:
> Some of the concerns about increasing the surface area I think are a bit
> overblown. I haven't seen any problems yet in the projects that do this, and
> I don't think it lends itself to abuse particularly well. Considering that
> the rest of the
There is an open request for this on GH, but it's not currently done:
https://github.com/rtfd/readthedocs.org/issues/1340
At the PyCon US sprints this year, we added documentation previews via
netlify, and they have been super useful:
https://github.com/pypa/setuptools/pull/1367 My understanding
On Nov 4, 2018, at 10:12, Stephane Wirtel wrote:
> 3. On this after-noon, I have reviewed a PR, and I was in the same case,
> download the PR, build python, compile the doc and run the local server.
>
> My workflow is the following steps:
>
> git wpr XYZ
> cd ../cpython-XYZ
> ./configure
On 11/04, Mariatta Wijaya wrote:
This will make review turnout quicker, since I can potentially review and
view the output from anywhere (phone while on a beach) instead of waiting
until I'm back home, open a computer, and then verify the output myself.
Yep, last week I was at a dinner at
Doesn't read the docs already do this for pull requests? Even if it doesn't,
don't the core maintainers of read the docs go to pycon? I wouldn't suggest
read the docs for primary docs hosting for python, but they are perfectly fine
for live testing pull request documentation without having to
On 11/04, Mariatta Wijaya wrote:
I think the intent is just uploading the output HTML and static assets.
Yep, it's my idea, just upload the output html and static assets,
nothing else.
I agree having the temporary output of PR docs build is useful, but I don't
think a python.org domain is
On 04Nov2018 0812, Julien Palard wrote:
I can trivially attach the built docs as a ZIP file to the Azure
Pipelines build, though that doesn't help the "preview on my phone"
So one can build an HTTP server that gathers doc builds from Azure and expose
them?
Either that, or Azure can push it
I think the intent is just uploading the output HTML and static assets.
I agree having the temporary output of PR docs build is useful, but I don't
think a python.org domain is necessary. If it can be uploaded to any cloud
storage service then that's good enough, just provide the link in the
This will make review turnout quicker, since I can potentially review and
view the output from anywhere (phone while on a beach) instead of waiting
until I'm back home, open a computer, and then verify the output myself.
On Sun, Nov 4, 2018, 7:56 AM Steven D'Aprano On Sun, Nov 04, 2018 at
> I can trivially attach the built docs as a ZIP file to the Azure
> Pipelines build, though that doesn't help the "preview on my phone"
So one can build an HTTP server that gathers doc builds from Azure and expose
them?
--
Julien Palard
https://mdk.fr
On 11/05, Steven D'Aprano wrote:
On Sun, Nov 04, 2018 at 04:12:39PM +0100, Stephane Wirtel wrote:
My workflow is the following steps:
git wpr XYZ
cd ../cpython-XYZ
./configure --prefix=$PWD-build --with-pydebug --silent
make -j 4 -s
make PYTHON=../python -C Doc/ venv
make -C Doc/ check
On 11/05, Chris Angelico wrote:
On Mon, Nov 5, 2018 at 2:33 AM Stephane Wirtel wrote:
On 11/05, Chris Angelico wrote:
>On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
> wrote:
>>
>> Considering feedback from Ned, what about building this as an independent
service? We don't really
On Sun, Nov 04, 2018 at 04:12:39PM +0100, Stephane Wirtel wrote:
> My workflow is the following steps:
>
> git wpr XYZ
> cd ../cpython-XYZ
> ./configure --prefix=$PWD-build --with-pydebug --silent
> make -j 4 -s
> make PYTHON=../python -C Doc/ venv
> make -C Doc/ check suspicious html serve
>
>
On Mon, Nov 5, 2018 at 2:33 AM Stephane Wirtel wrote:
>
> On 11/05, Chris Angelico wrote:
> >On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
> > wrote:
> >>
> >> Considering feedback from Ned, what about building this as an independent
> >> service? We don't really need to interface
On 11/04, Serhiy Storchaka wrote:
04.11.18 17:00, Julien Palard via Python-Dev пише:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some code to interface with
On 11/04, Steve Dower wrote:
On 04Nov2018 0718, Chris Angelico wrote:
On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
wrote:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
04.11.18 17:00, Julien Palard via Python-Dev пише:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some code to interface with github API and... to start
it's
On 04Nov2018 0718, Chris Angelico wrote:
On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
wrote:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some
On 11/05, Chris Angelico wrote:
On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
wrote:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some code to
On 11/04, Julien Palard wrote:
Considering feedback from Ned, what about building this as an
independent service? We don't really need to interface with python.org
at all, we just need some hardware, a domain, some code to interface
with github API and... to start it's probably enough? It would
On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
wrote:
>
> Considering feedback from Ned, what about building this as an independent
> service? We don't really need to interface with python.org at all, we just
> need some hardware, a domain, some code to interface with github API
On 11/04, Ned Deily wrote:
On Nov 4, 2018, at 08:38, Stephane Wirtel wrote:
When we receive a PR about the documentation, I think that could be
interesting if we could have a running instance of the doc on a sub
domain of python.org.
For example, pr-1-doc.python.org or whatever, but by
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some code to interface with github API and... to start
it's probably enough? It would be a usefull POC.
--
Julien
On Nov 4, 2018, at 08:38, Stephane Wirtel wrote:
> When we receive a PR about the documentation, I think that could be
> interesting if we could have a running instance of the doc on a sub
> domain of python.org.
>
> For example, pr-1-doc.python.org or whatever, but by this way the
>
Hi all,
When we receive a PR about the documentation, I think that could be
interesting if we could have a running instance of the doc on a sub
domain of python.org.
For example, pr-1-doc.python.org or whatever, but by this way the
reviewers could see the result online.
The workflow would
On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote:
> In this PR [https://github.com/python/cpython/pull/3382] "Remove reference
> to
> address from the docs, as it only causes confusion", opened by Chris
> Angelico, there is a discussion about the right term to use for the
> address
In this PR [https://github.com/python/cpython/pull/3382] "Remove reference to
address from the docs, as it only causes confusion", opened by Chris
Angelico, there is a discussion about the right term to use for the
address of an object in memory.
If you are interested by the topic, you could
37 matches
Mail list logo
