From ncoghlan at gmail.com  Sat Apr  1 13:02:11 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 2 Apr 2017 03:02:11 +1000
Subject: [core-workflow] Starting a bot to identify issues with PRs
In-Reply-To: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
References: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
Message-ID: <CADiSq7fwVCSaVTPn-Y9jy0qCS-W9+x37ObMc8E3mtoOtPUYZ0w@mail.gmail.com>

On 1 April 2017 at 09:23, Brett Cannon <brett at python.org> wrote:
> I have created a bot that I hope we can use to host all non-CLA checks for a
> PR that isn't covered by CI: https://github.com/brettcannon/bedevere. To
> start, the bot would check for a bugs.python.org issue number and set a
> failing status if one isn't found, else link the status to the issue itself.
>
> If the approach I took in the bot seems reasonable to people I will add
> support for a "trivial" label which would cause the bot to say the check is
> successful due to the fact that the PR is trivial enough to not warrant an
> issue to begin with. We can then continue to expand this bot to do other
> things like check that there is a NEWS file (unless marked as "trivial").

+1 from me.

> I don't want to role the CLA bot into bedevere since I created the bot in
> such a way as to be useful to other organizations on GitHub. So the Knights
> Who Say Ni will stay a separate repo.

Regardless of the practical details, I kind of like the idea of having
the Knights as a grumpy bot looking for a shrubbery(/CLA), and Sir
Bedevere as a happier, helpful bot that only complains when it gets
confused by a lack of information :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Sat Apr  1 17:07:20 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 01 Apr 2017 21:07:20 +0000
Subject: [core-workflow] Starting a bot to identify issues with PRs
In-Reply-To: <CADiSq7fwVCSaVTPn-Y9jy0qCS-W9+x37ObMc8E3mtoOtPUYZ0w@mail.gmail.com>
References: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
 <CADiSq7fwVCSaVTPn-Y9jy0qCS-W9+x37ObMc8E3mtoOtPUYZ0w@mail.gmail.com>
Message-ID: <CAP1=2W5etVikHRgqgWqWKhnnt-wsLhtQ7G+fkvwzkLvhPd__DA@mail.gmail.com>

On Sat, 1 Apr 2017 at 10:08 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 1 April 2017 at 09:23, Brett Cannon <brett at python.org> wrote:
> > I have created a bot that I hope we can use to host all non-CLA checks
> for a
> > PR that isn't covered by CI: https://github.com/brettcannon/bedevere. To
> > start, the bot would check for a bugs.python.org issue number and set a
> > failing status if one isn't found, else link the status to the issue
> itself.
> >
> > If the approach I took in the bot seems reasonable to people I will add
> > support for a "trivial" label which would cause the bot to say the check
> is
> > successful due to the fact that the PR is trivial enough to not warrant
> an
> > issue to begin with. We can then continue to expand this bot to do other
> > things like check that there is a NEWS file (unless marked as "trivial").
>
> +1 from me.
>

And as a break from some political dealings I went ahead and implemented
the "trivial" label support. So the bot is now coded to follow a pattern
that I assume we will continue to use if we use this bot and add more
status checks.


>
> > I don't want to role the CLA bot into bedevere since I created the bot in
> > such a way as to be useful to other organizations on GitHub. So the
> Knights
> > Who Say Ni will stay a separate repo.
>
> Regardless of the practical details, I kind of like the idea of having
> the Knights as a grumpy bot looking for a shrubbery(/CLA), and Sir
> Bedevere as a happier, helpful bot that only complains when it gets
> confused by a lack of information :)
>

:) Yeah, I was very happy when I got the inspiration for the name since it
seemed to fit rather well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170401/3186b4a6/attachment.html>

From brett at python.org  Mon Apr  3 22:27:51 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 04 Apr 2017 02:27:51 +0000
Subject: [core-workflow] Starting a bot to identify issues with PRs
In-Reply-To: <CAP1=2W5etVikHRgqgWqWKhnnt-wsLhtQ7G+fkvwzkLvhPd__DA@mail.gmail.com>
References: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
 <CADiSq7fwVCSaVTPn-Y9jy0qCS-W9+x37ObMc8E3mtoOtPUYZ0w@mail.gmail.com>
 <CAP1=2W5etVikHRgqgWqWKhnnt-wsLhtQ7G+fkvwzkLvhPd__DA@mail.gmail.com>
Message-ID: <CAP1=2W4DXfZCdHfqD7qS2Dj9MtePCGAq62ZVA82JbCnKQabLYQ@mail.gmail.com>

I have now done a test deployment of the bot to Heroku and it works! So
unless I hear otherwise I will ask the infrastructure team for another
Heroku app, move the code to be under the Python org, and then turn on the
bot for the cpython repo. Since it's so easy to override I will make it a
required check after we have lived with the bot for a few days to make sure
it works as expected.

On Sat, 1 Apr 2017 at 14:07 Brett Cannon <brett at python.org> wrote:

> On Sat, 1 Apr 2017 at 10:08 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 1 April 2017 at 09:23, Brett Cannon <brett at python.org> wrote:
> > I have created a bot that I hope we can use to host all non-CLA checks
> for a
> > PR that isn't covered by CI: https://github.com/brettcannon/bedevere. To
> > start, the bot would check for a bugs.python.org issue number and set a
> > failing status if one isn't found, else link the status to the issue
> itself.
> >
> > If the approach I took in the bot seems reasonable to people I will add
> > support for a "trivial" label which would cause the bot to say the check
> is
> > successful due to the fact that the PR is trivial enough to not warrant
> an
> > issue to begin with. We can then continue to expand this bot to do other
> > things like check that there is a NEWS file (unless marked as "trivial").
>
> +1 from me.
>
>
> And as a break from some political dealings I went ahead and implemented
> the "trivial" label support. So the bot is now coded to follow a pattern
> that I assume we will continue to use if we use this bot and add more
> status checks.
>
>
>
> > I don't want to role the CLA bot into bedevere since I created the bot in
> > such a way as to be useful to other organizations on GitHub. So the
> Knights
> > Who Say Ni will stay a separate repo.
>
> Regardless of the practical details, I kind of like the idea of having
> the Knights as a grumpy bot looking for a shrubbery(/CLA), and Sir
> Bedevere as a happier, helpful bot that only complains when it gets
> confused by a lack of information :)
>
>
> :) Yeah, I was very happy when I got the inspiration for the name since it
> seemed to fit rather well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170404/386d5cf1/attachment.html>

From senthil at uthcode.com  Mon Apr  3 22:33:38 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 3 Apr 2017 19:33:38 -0700
Subject: [core-workflow] Starting a bot to identify issues with PRs
In-Reply-To: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
References: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
Message-ID: <CAPOVWORROet+bcNObS6dQsuhQx=ym8zAQiPO86h-P9FkegBxdg@mail.gmail.com>

On Fri, Mar 31, 2017 at 4:23 PM, Brett Cannon <brett at python.org> wrote:
> To start, the bot would check for a bugs.python.org issue number and set a
> failing status if one isn't found, else link the status to the issue itself.
>
> If the approach I took in the bot seems reasonable to people I will add
> support for a "trivial" label which would cause the bot to say the check is
> successful due to the fact that the PR is trivial enough to not warrant an
> issue to begin with. We can then continue to expand this bot to do other
> things like check that there is a NEWS file (unless marked as "trivial").

This is a good idea. +1 to bedevere bot.

-- 
Senthil

From mariatta.wijaya at gmail.com  Tue Apr  4 03:53:49 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 4 Apr 2017 00:53:49 -0700
Subject: [core-workflow] Starting a bot to identify issues with PRs
In-Reply-To: <CAP1=2W4DXfZCdHfqD7qS2Dj9MtePCGAq62ZVA82JbCnKQabLYQ@mail.gmail.com>
References: <CAP1=2W7hQqrE-WXcJviLyCq_4PRam7SWosnf6UDrJJjRPUdqkg@mail.gmail.com>
 <CADiSq7fwVCSaVTPn-Y9jy0qCS-W9+x37ObMc8E3mtoOtPUYZ0w@mail.gmail.com>
 <CAP1=2W5etVikHRgqgWqWKhnnt-wsLhtQ7G+fkvwzkLvhPd__DA@mail.gmail.com>
 <CAP1=2W4DXfZCdHfqD7qS2Dj9MtePCGAq62ZVA82JbCnKQabLYQ@mail.gmail.com>
Message-ID: <CAGbohnabXdAv2i0c26NtUhvS1Vyz4medoCmZd0fQ9ssMpb3bTA@mail.gmail.com>

Sounds great!
Thanks, Brett.

Mariatta Wijaya

On Mon, Apr 3, 2017 at 7:27 PM, Brett Cannon <brett at python.org> wrote:

> I have now done a test deployment of the bot to Heroku and it works! So
> unless I hear otherwise I will ask the infrastructure team for another
> Heroku app, move the code to be under the Python org, and then turn on the
> bot for the cpython repo. Since it's so easy to override I will make it a
> required check after we have lived with the bot for a few days to make sure
> it works as expected.
>
> On Sat, 1 Apr 2017 at 14:07 Brett Cannon <brett at python.org> wrote:
>
>> On Sat, 1 Apr 2017 at 10:08 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 1 April 2017 at 09:23, Brett Cannon <brett at python.org> wrote:
>> > I have created a bot that I hope we can use to host all non-CLA checks
>> for a
>> > PR that isn't covered by CI: https://github.com/brettcannon/bedevere.
>> To
>> > start, the bot would check for a bugs.python.org issue number and set a
>> > failing status if one isn't found, else link the status to the issue
>> itself.
>> >
>> > If the approach I took in the bot seems reasonable to people I will add
>> > support for a "trivial" label which would cause the bot to say the
>> check is
>> > successful due to the fact that the PR is trivial enough to not warrant
>> an
>> > issue to begin with. We can then continue to expand this bot to do other
>> > things like check that there is a NEWS file (unless marked as
>> "trivial").
>>
>> +1 from me.
>>
>>
>> And as a break from some political dealings I went ahead and implemented
>> the "trivial" label support. So the bot is now coded to follow a pattern
>> that I assume we will continue to use if we use this bot and add more
>> status checks.
>>
>>
>>
>> > I don't want to role the CLA bot into bedevere since I created the bot
>> in
>> > such a way as to be useful to other organizations on GitHub. So the
>> Knights
>> > Who Say Ni will stay a separate repo.
>>
>> Regardless of the practical details, I kind of like the idea of having
>> the Knights as a grumpy bot looking for a shrubbery(/CLA), and Sir
>> Bedevere as a happier, helpful bot that only complains when it gets
>> confused by a lack of information :)
>>
>>
>> :) Yeah, I was very happy when I got the inspiration for the name since
>> it seemed to fit rather well.
>>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170404/b0ac71a5/attachment-0001.html>

From alex at strugee.net  Wed Apr  5 23:35:02 2017
From: alex at strugee.net (Alex Jordan)
Date: Wed, 5 Apr 2017 23:35:02 -0400
Subject: [core-workflow] Please disable CLA checking for trivial GitHub
 patches
Message-ID: <20170406033502.GI15897@Alexs-MacBook-Pro>

Heya!

Recently I sent https://github.com/python/cpython/pull/1012 - a typo
fix to the docs. I got prompted to sign the CLA, but as I described in
https://github.com/python/cpython/pull/1012#issuecomment-292038637, I
really think that was unnecessary since it was only a couple
characters.

The bot should probably be adjusted so it doesn't prompt for casual
drive-by contributions.

I'm not subscribed so I won't see replies, but feel free to CC me if
you need to (can't imagine why, though).

Cheers!

AJ
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170405/1e165108/attachment.sig>

From brett at python.org  Thu Apr  6 14:15:52 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 06 Apr 2017 18:15:52 +0000
Subject: [core-workflow] Please disable CLA checking for trivial GitHub
 patches
In-Reply-To: <20170406033502.GI15897@Alexs-MacBook-Pro>
References: <20170406033502.GI15897@Alexs-MacBook-Pro>
Message-ID: <CAP1=2W5uC6NAqz=3DP0M6o8rY45b6+pxBaQOtUXRtw3y8Zrz8g@mail.gmail.com>

As shown in the response to your PR, core devs are able to override the bot
by simply ignoring the check (that's why it's not required to pass for PR
acceptance).

But the bot will never be adjusted to make its own call on what is or is
not covered. It's too risky legally to get this wrong, e.g. there are
patents guarding against how you iterate through things in telecom
switches, so you could theoretically use a patent by changing a single line
in a code example by how you iterate through something. I know that's an
extreme example, but that's the sort of world we have to guard ourselves
against. We also have lots of companies that ship Python in their product
who would be totally screwed if we got this wrong as they would then
potentially be liable for patent licensing costs.

So the bot will always be there and will always be all or nothing. Having
said that, core devs will always be able to ignore it in cases where it's
obvious there's no chance a patent is being violated or protected IP is
being used (e.g. spelling mistakes). If this causes the occasional
contributor to not fix a spelling mistake, that's unfortunate but I can
live with that as being overly cautious about this legal stuff lets me
sleep at night instead of worrying about being the guy who wrote a CLA bot
that was just a tad too loose that one time and sent the PSF into
bankruptcy over court costs. (You might think I'm exaggerating but I was
really worried about not messing up the design and coding of the CLA bot
because getting it wrong really does mean the PSF could be open to
lawsuits.)

On Thu, 6 Apr 2017 at 11:00 Alex Jordan <alex at strugee.net> wrote:

> Heya!
>
> Recently I sent https://github.com/python/cpython/pull/1012 - a typo
> fix to the docs. I got prompted to sign the CLA, but as I described in
> https://github.com/python/cpython/pull/1012#issuecomment-292038637, I
> really think that was unnecessary since it was only a couple
> characters.
>
> The bot should probably be adjusted so it doesn't prompt for casual
> drive-by contributions.
>
> I'm not subscribed so I won't see replies, but feel free to CC me if
> you need to (can't imagine why, though).
>
> Cheers!
>
> AJ
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170406/afb3b64a/attachment.html>

From brett at python.org  Fri Apr  7 14:32:59 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 07 Apr 2017 18:32:59 +0000
Subject: [core-workflow] I have created https://github.com/python/bedevere
Message-ID: <CAP1=2W6-YN+UTazjX4YJmRothb-L-fqF8QKXREtHsHRn-QKnrQ@mail.gmail.com>

The Heroku instance is set up, but I have not turned it on for the CPython
repo yet as I'm sick and that just means I will mess up any debugging I may
need to do if something goes wrong. :) So once I'm well I will turn it on
(the way I'm feeling, probably not until the latter half of next week :(  ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170407/8ab94049/attachment.html>

From alex at strugee.net  Fri Apr  7 17:18:56 2017
From: alex at strugee.net (Alex Jordan)
Date: Fri, 7 Apr 2017 17:18:56 -0400
Subject: [core-workflow] Please disable CLA checking for trivial GitHub
 patches
In-Reply-To: <CAP1=2W5uC6NAqz=3DP0M6o8rY45b6+pxBaQOtUXRtw3y8Zrz8g@mail.gmail.com>
References: <20170406033502.GI15897@Alexs-MacBook-Pro>
 <CAP1=2W5uC6NAqz=3DP0M6o8rY45b6+pxBaQOtUXRtw3y8Zrz8g@mail.gmail.com>
Message-ID: <20170407211855.GK15897@Alexs-MacBook-Pro>

On Thu, Apr 06, 2017 at 06:15:52PM +0000, Brett Cannon wrote:

> But the bot will never be adjusted to make its own call on what is or is
> not covered. It's too risky legally to get this wrong, e.g. there are
> patents guarding against how you iterate through things in telecom
> switches, so you could theoretically use a patent by changing a single line
> in a code example by how you iterate through something. I know that's an
> extreme example, but that's the sort of world we have to guard ourselves
> against. We also have lots of companies that ship Python in their product
> who would be totally screwed if we got this wrong as they would then
> potentially be liable for patent licensing costs.

Right, I was imagining a scenario in which the bot could be "kicked"
to go fetch CLA information if it misjudged the triviality of a
patch. Perhaps too much trouble than it's worth, though, given how
critical this is to get right (which I certainly didn't have a good
sense of before your message).

Thanks for the (highly informative) reply!

AJ
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170407/afcb773d/attachment.sig>

From brett at python.org  Tue Apr 11 12:50:23 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 16:50:23 +0000
Subject: [core-workflow] Voting on possible subdomains for the devguide
Message-ID: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>

With part of the goal of moving to GitHub being to minimize how much
infrastructure we have to run, one of the long-term goals I have is to use
Read the Docs to host Python's documentation. But to get there we have to
move any "special" docs over first. That means relocating the devguide (it
also means relocating the PEPs, but that's another issue and is blocked
first and foremost by https://github.com/python/peps/issues/4).

Thanks to the work of various people we have
https://cpython-devguide.readthedocs.io/ so the toolchain for building the
devguide on RTFD is done. That means the next step is deciding on a
subdomain on the python.org domain to host the docs from. If you have an
opinion, go to https://github.com/python/core-workflow/issues/4 and leave a
reaction on the appropriate message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/737a3a16/attachment.html>

From donald at stufft.io  Tue Apr 11 13:01:35 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 11 Apr 2017 13:01:35 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
Message-ID: <FC8E1427-F49C-430A-8768-2AE38FA1DF3E@stufft.io>

With Fastly we could probably send www.python.org/peps/ <http://www.python.org/peps/> to RTD or docs.python.org/devguide/ <http://docs.python.org/devguide/> to the devuide. I think RTD supports setting a canonical URL that includes a path too. FWIW. Of course the look and feel might be different so different domains might be a good idea anyways.

> On Apr 11, 2017, at 12:50 PM, Brett Cannon <brett at python.org> wrote:
> 
> With part of the goal of moving to GitHub being to minimize how much infrastructure we have to run, one of the long-term goals I have is to use Read the Docs to host Python's documentation. But to get there we have to move any "special" docs over first. That means relocating the devguide (it also means relocating the PEPs, but that's another issue and is blocked first and foremost by https://github.com/python/peps/issues/4 <https://github.com/python/peps/issues/4>).
> 
> Thanks to the work of various people we have https://cpython-devguide.readthedocs.io/ <https://cpython-devguide.readthedocs.io/> so the toolchain for building the devguide on RTFD is done. That means the next step is deciding on a subdomain on the python.org <http://python.org/> domain to host the docs from. If you have an opinion, go to https://github.com/python/core-workflow/issues/4 <https://github.com/python/core-workflow/issues/4> and leave a reaction on the appropriate message.
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct


?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/94377504/attachment.html>

From brett at python.org  Tue Apr 11 13:14:25 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 17:14:25 +0000
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <FC8E1427-F49C-430A-8768-2AE38FA1DF3E@stufft.io>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <FC8E1427-F49C-430A-8768-2AE38FA1DF3E@stufft.io>
Message-ID: <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>

On Tue, 11 Apr 2017 at 10:01 Donald Stufft <donald at stufft.io> wrote:

> With Fastly we could probably send www.python.org/peps/ to RTD or
> docs.python.org/devguide/ to the devuide. I think RTD supports setting a
> canonical URL that includes a path too. FWIW. Of course the look and feel
> might be different so different domains might be a good idea anyways.
>

That was my thinking. The devguide and peps are distinct enough in how
their purposes that sticking them on their own domain that's easy to
remember I think makes sense.


>
> On Apr 11, 2017, at 12:50 PM, Brett Cannon <brett at python.org> wrote:
>
> With part of the goal of moving to GitHub being to minimize how much
> infrastructure we have to run, one of the long-term goals I have is to use
> Read the Docs to host Python's documentation. But to get there we have to
> move any "special" docs over first. That means relocating the devguide (it
> also means relocating the PEPs, but that's another issue and is blocked
> first and foremost by https://github.com/python/peps/issues/4).
>
> Thanks to the work of various people we have
> https://cpython-devguide.readthedocs.io/ so the toolchain for building
> the devguide on RTFD is done. That means the next step is deciding on a
> subdomain on the python.org domain to host the docs from. If you have an
> opinion, go to https://github.com/python/core-workflow/issues/4 and leave
> a reaction on the appropriate message.
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>
>
> ?
>
> Donald Stufft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/dc82c09e/attachment-0001.html>

From guido at python.org  Tue Apr 11 13:41:45 2017
From: guido at python.org (Guido van Rossum)
Date: Tue, 11 Apr 2017 10:41:45 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <FC8E1427-F49C-430A-8768-2AE38FA1DF3E@stufft.io>
 <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
Message-ID: <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>

Last I heard from then, RTD was struggling financially. Hosting isn't
really free, you know -- nor is administering a site like that :-). The PSF
should offer to cover their costs for hosting the Python docs, which I
presume are pretty dang popular compared to many other things currently
hosted at RTD -- the peps and devguide won't cause any load in comparison.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/d329b4f4/attachment.html>

From elprans at gmail.com  Tue Apr 11 13:52:31 2017
From: elprans at gmail.com (Elvis Pranskevichus)
Date: Tue, 11 Apr 2017 13:52:31 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
 <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
Message-ID: <1619688.NmOOU860f3@hammer.magicstack.net>

On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> Last I heard from then, RTD was struggling financially. Hosting isn't
> really free, you know -- nor is administering a site like that :-).
> The PSF should offer to cover their costs for hosting the Python
> docs, which I presume are pretty dang popular compared to many other
> things currently hosted at RTD -- the peps and devguide won't cause
> any load in comparison.


Is Gihub Pages considered an option?  We host the asyncpg docs [1] 
there.  Builds are done by Travis.  The advantage is that we don't have 
to add another service dependency.


[1] https://magicstack.github.io/asyncpg/current/


                              Elvis



From brett at python.org  Tue Apr 11 13:57:08 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 17:57:08 +0000
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <FC8E1427-F49C-430A-8768-2AE38FA1DF3E@stufft.io>
 <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
 <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
Message-ID: <CAP1=2W6eT2iT0z9cmZyqBSDEBz0BhvvZwoJPgThuaN5qNFE=yQ@mail.gmail.com>

On Tue, 11 Apr 2017 at 10:42 Guido van Rossum <guido at python.org> wrote:

> Last I heard from then, RTD was struggling financially. Hosting isn't
> really free, you know -- nor is administering a site like that :-). The PSF
> should offer to cover their costs for hosting the Python docs, which I
> presume are pretty dang popular compared to many other things currently
> hosted at RTD -- the peps and devguide won't cause any load in comparison.
>

I've brought it up with Eric Holscher before and he's said he doesn't want
any open source project to feel like they have to pay. That being said I
would ask the PSF to be a sponsor of some form if we did move all the docs
over (for the devguide I'm not worried about the increased traffic). I've
also suggested to Eric to apply for a PSF grant to move the docs over to
Read the Docs so he can get paid to help make sure any such migration would
be done well.

-Brett


>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/d3a0d981/attachment.html>

From brett at python.org  Tue Apr 11 13:58:38 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 17:58:38 +0000
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <1619688.NmOOU860f3@hammer.magicstack.net>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
 <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
 <1619688.NmOOU860f3@hammer.magicstack.net>
Message-ID: <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>

On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com> wrote:

> On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> > Last I heard from then, RTD was struggling financially. Hosting isn't
> > really free, you know -- nor is administering a site like that :-).
> > The PSF should offer to cover their costs for hosting the Python
> > docs, which I presume are pretty dang popular compared to many other
> > things currently hosted at RTD -- the peps and devguide won't cause
> > any load in comparison.
>
>
> Is Gihub Pages considered an option?  We host the asyncpg docs [1]
> there.  Builds are done by Travis.  The advantage is that we don't have
> to add another service dependency.
>

I guess so. No one has ever suggested it before or bothered to set it up to
show how it would work. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/ce335ab4/attachment.html>

From phd at phdru.name  Tue Apr 11 14:09:33 2017
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 11 Apr 2017 20:09:33 +0200
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W6bu2KFPprack_eDx=4W5RmuZSbVNKggcae8EMO47QBvw@mail.gmail.com>
 <CAP7+vJJL7gcNegFLzNSTxpEgNp3wrh11pZLqGYdLdfGWmgz-5Q@mail.gmail.com>
 <1619688.NmOOU860f3@hammer.magicstack.net>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
Message-ID: <20170411180933.GA2927@phdru.name>

On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <brett at python.org> wrote:
> On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com> wrote:
> 
> > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> > > Last I heard from then, RTD was struggling financially. Hosting isn't
> > > really free, you know -- nor is administering a site like that :-).
> > > The PSF should offer to cover their costs for hosting the Python
> > > docs, which I presume are pretty dang popular compared to many other
> > > things currently hosted at RTD -- the peps and devguide won't cause
> > > any load in comparison.
> >
> > Is Gihub Pages considered an option?  We host the asyncpg docs [1]
> > there.  Builds are done by Travis.  The advantage is that we don't have
> > to add another service dependency.
> >
> 
> I guess so. No one has ever suggested it before or bothered to set it up to
> show how it would work. :)

   GH Pages don't need much to setup. You have to choose between Org
Pages (at the root of the subdomain) and Repo Pages (in subdirectories).
I even believe GH Pages can do both on the same subdomain but I've never
tried.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From elprans at gmail.com  Tue Apr 11 14:28:20 2017
From: elprans at gmail.com (Elvis Pranskevichus)
Date: Tue, 11 Apr 2017 14:28:20 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <20170411180933.GA2927@phdru.name>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
 <20170411180933.GA2927@phdru.name>
Message-ID: <4015620.e0R3kIOpp5@hammer.magicstack.net>

On Tuesday, April 11, 2017 2:09:33 PM EDT Oleg Broytman wrote:
> On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <brett at python.org> wrote:
> > On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com> wrote:
> > > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> > > > Last I heard from then, RTD was struggling financially. Hosting
> > > > isn't
> > > > really free, you know -- nor is administering a site like that
> > > > :-).
> > > > The PSF should offer to cover their costs for hosting the Python
> > > > docs, which I presume are pretty dang popular compared to many
> > > > other
> > > > things currently hosted at RTD -- the peps and devguide won't
> > > > cause
> > > > any load in comparison.
> > > 
> > > Is Gihub Pages considered an option?  We host the asyncpg docs [1]
> > > there.  Builds are done by Travis.  The advantage is that we don't
> > > have to add another service dependency.
> > 
> > I guess so. No one has ever suggested it before or bothered to set
> > it up to show how it would work. :)
> 
>    GH Pages don't need much to setup. You have to choose between Org
> Pages (at the root of the subdomain) and Repo Pages (in
> subdirectories). I even believe GH Pages can do both on the same
> subdomain but I've never tried.

GH Pages support custom domain redirects [1].  "setup" in this case 
is putting together scripts to automate sphinx runs and the git push 
of the compiled output to the appropriate repo/branch.  If there's
interest in pursuing this option, I can help with setting things up.


[1] https://help.github.com/articles/custom-domain-redirects-for-github-pages-sites/


                           Elvis

From phd at phdru.name  Tue Apr 11 14:37:03 2017
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 11 Apr 2017 20:37:03 +0200
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <4015620.e0R3kIOpp5@hammer.magicstack.net>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
 <20170411180933.GA2927@phdru.name>
 <4015620.e0R3kIOpp5@hammer.magicstack.net>
Message-ID: <20170411183703.GA4389@phdru.name>

On Tue, Apr 11, 2017 at 02:28:20PM -0400, Elvis Pranskevichus <elprans at gmail.com> wrote:
> On Tuesday, April 11, 2017 2:09:33 PM EDT Oleg Broytman wrote:
> > On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <brett at python.org> wrote:
> > > On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com> wrote:
> > > > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> > > > > Last I heard from then, RTD was struggling financially. Hosting
> > > > > isn't
> > > > > really free, you know -- nor is administering a site like that
> > > > > :-).
> > > > > The PSF should offer to cover their costs for hosting the Python
> > > > > docs, which I presume are pretty dang popular compared to many
> > > > > other
> > > > > things currently hosted at RTD -- the peps and devguide won't
> > > > > cause
> > > > > any load in comparison.
> > > > 
> > > > Is Gihub Pages considered an option?  We host the asyncpg docs [1]
> > > > there.  Builds are done by Travis.  The advantage is that we don't
> > > > have to add another service dependency.
> > > 
> > > I guess so. No one has ever suggested it before or bothered to set
> > > it up to show how it would work. :)
> > 
> >    GH Pages don't need much to setup. You have to choose between Org
> > Pages (at the root of the subdomain) and Repo Pages (in
> > subdirectories). I even believe GH Pages can do both on the same
> > subdomain but I've never tried.
> 
> GH Pages support custom domain redirects [1].  "setup" in this case 
> is putting together scripts to automate sphinx runs and the git push 
> of the compiled output to the appropriate repo/branch.  If there's
> interest in pursuing this option, I can help with setting things up.
> 
> [1] https://help.github.com/articles/custom-domain-redirects-for-github-pages-sites/

   For Org Pages with a custom domain you also need a CNAME file at the
root of the repo.

   To publish Sphinx-generated sites you need an empty .nojekyll file at
the root. Without it GitHub blocks special Sphinx directories (those
ones that starts with an underscore).

>                            Elvis

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From brett at python.org  Tue Apr 11 15:11:10 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 19:11:10 +0000
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <4015620.e0R3kIOpp5@hammer.magicstack.net>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
 <20170411180933.GA2927@phdru.name> <4015620.e0R3kIOpp5@hammer.magicstack.net>
Message-ID: <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>

On Tue, 11 Apr 2017 at 11:28 Elvis Pranskevichus <elprans at gmail.com> wrote:

> On Tuesday, April 11, 2017 2:09:33 PM EDT Oleg Broytman wrote:
> > On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <brett at python.org>
> wrote:
> > > On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com>
> wrote:
> > > > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
> > > > > Last I heard from then, RTD was struggling financially. Hosting
> > > > > isn't
> > > > > really free, you know -- nor is administering a site like that
> > > > > :-).
> > > > > The PSF should offer to cover their costs for hosting the Python
> > > > > docs, which I presume are pretty dang popular compared to many
> > > > > other
> > > > > things currently hosted at RTD -- the peps and devguide won't
> > > > > cause
> > > > > any load in comparison.
> > > >
> > > > Is Gihub Pages considered an option?  We host the asyncpg docs [1]
> > > > there.  Builds are done by Travis.  The advantage is that we don't
> > > > have to add another service dependency.
> > >
> > > I guess so. No one has ever suggested it before or bothered to set
> > > it up to show how it would work. :)
> >
> >    GH Pages don't need much to setup. You have to choose between Org
> > Pages (at the root of the subdomain) and Repo Pages (in
> > subdirectories). I even believe GH Pages can do both on the same
> > subdomain but I've never tried.
>
> GH Pages support custom domain redirects [1].  "setup" in this case
> is putting together scripts to automate sphinx runs and the git push
> of the compiled output to the appropriate repo/branch.


So we would have to either set up another repo or commit the rendered files
to the repo?


>   If there's
> interest in pursuing this option, I can help with setting things up.
>

I assume we would lose the widget Read the Docs provides which is handy for
getting to the GitHub page for editing the content? I guess we lose
anything else that https://docs.readthedocs.io/en/latest/features.html
 lists.

I'm just trying to think of what we gain/lose if we switch to GH Pages over
RTFD as I don't want to end up with three different documentation hosting
solutions sort of like we have now where we build the devguide, PEPs, and
the docs themselves in special ways that all happen to be hosted on PSF
infrastructure (e.g. getting Pygments installed for the PEPs has stalled
out and it would be good that any solution we choose be flexible enough to
handle this kind of situation:
https://github.com/python/peps/pull/229/files/70c6c1d010c1d50a375430c4ba6ae3e4f439306c#r107471836
).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/797a7f43/attachment.html>

From elprans at gmail.com  Tue Apr 11 15:29:45 2017
From: elprans at gmail.com (Elvis Pranskevichus)
Date: Tue, 11 Apr 2017 15:29:45 -0400
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <4015620.e0R3kIOpp5@hammer.magicstack.net>
 <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
Message-ID: <1831160.nZKQcDNxVD@hammer.magicstack.net>

On Tuesday, April 11, 2017 3:11:10 PM EDT Brett Cannon wrote:
> > GH Pages support custom domain redirects [1].  "setup" in this case
> > is putting together scripts to automate sphinx runs and the git push
> > of the compiled output to the appropriate repo/branch.
> 
> So we would have to either set up another repo or commit the rendered
> files to the repo?

Either a separate repo, or commit to the gh-pages branch.

> >   If there's
> > 
> > interest in pursuing this option, I can help with setting things up.
> 
> I assume we would lose the widget Read the Docs provides which is
> handy for getting to the GitHub page for editing the content? I guess
> we lose anything else that
> https://docs.readthedocs.io/en/latest/features.html lists.

https://gist.github.com/mgedmin/6052926

> I'm just trying to think of what we gain/lose if we switch to GH Pages
> over RTFD as I don't want to end up with three different
> documentation hosting solutions sort of like we have now where we
> build the devguide, PEPs, and the docs themselves in special ways
> that all happen to be hosted on PSF infrastructure (e.g. getting
> Pygments installed for the PEPs has stalled out and it would be good
> that any solution we choose be flexible enough to handle this kind of
> situation:
> https://github.com/python/peps/pull/229/files/70c6c1d010c1d50a375430c4
> ba6ae3e4f439306c#r107471836 ).

The idea is that the doc build is done as part of CI and the product is 
uploaded as static content (GH pages is an option, but it might be 
anything capable of serving static content).

One of the reasons why we went with GH Pages for asyncpg is that at the 
time RTFD did not support Python 3.5 syntax and we wanted to use 
autodoc.  Could this be an issue when building Python documentation?  
Can the master branch Docs/ be built by Sphinx running on Python 3.4? 

                              Elvis

From rosuav at gmail.com  Tue Apr 11 15:30:11 2017
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 12 Apr 2017 05:30:11 +1000
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
 <20170411180933.GA2927@phdru.name> <4015620.e0R3kIOpp5@hammer.magicstack.net>
 <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
Message-ID: <CAPTjJmr+bb3gVNbxRLAWx=Pe0RJc+pVdKPNV0vhvg+AjfitE-A@mail.gmail.com>

On Wed, Apr 12, 2017 at 5:11 AM, Brett Cannon <brett at python.org> wrote:
>> GH Pages support custom domain redirects [1].  "setup" in this case
>> is putting together scripts to automate sphinx runs and the git push
>> of the compiled output to the appropriate repo/branch.
>
>
> So we would have to either set up another repo or commit the rendered files
> to the repo?

One neat trick is to have a deployment script that commits the
rendered files only to the gh-pages branch. I've done that for other
purposes with some of my students, and it's easy enough to use
(although the script itself contains some black magic aka "git
plumbing commands").

ChrisA

From brett at python.org  Tue Apr 11 16:11:44 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 20:11:44 +0000
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <1831160.nZKQcDNxVD@hammer.magicstack.net>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <4015620.e0R3kIOpp5@hammer.magicstack.net>
 <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
 <1831160.nZKQcDNxVD@hammer.magicstack.net>
Message-ID: <CAP1=2W6LYY7VYzn0xzvKXOdDynxcuWF2qOh7vsXoCs8Lg_r8gw@mail.gmail.com>

On Tue, 11 Apr 2017 at 12:29 Elvis Pranskevichus <elprans at gmail.com> wrote:

> On Tuesday, April 11, 2017 3:11:10 PM EDT Brett Cannon wrote:
> > > GH Pages support custom domain redirects [1].  "setup" in this case
> > > is putting together scripts to automate sphinx runs and the git push
> > > of the compiled output to the appropriate repo/branch.
> >
> > So we would have to either set up another repo or commit the rendered
> > files to the repo?
>
> Either a separate repo, or commit to the gh-pages branch.
>
> > >   If there's
> > >
> > > interest in pursuing this option, I can help with setting things up.
> >
> > I assume we would lose the widget Read the Docs provides which is
> > handy for getting to the GitHub page for editing the content? I guess
> > we lose anything else that
> > https://docs.readthedocs.io/en/latest/features.html lists.
>
> https://gist.github.com/mgedmin/6052926
>
> > I'm just trying to think of what we gain/lose if we switch to GH Pages
> > over RTFD as I don't want to end up with three different
> > documentation hosting solutions sort of like we have now where we
> > build the devguide, PEPs, and the docs themselves in special ways
> > that all happen to be hosted on PSF infrastructure (e.g. getting
> > Pygments installed for the PEPs has stalled out and it would be good
> > that any solution we choose be flexible enough to handle this kind of
> > situation:
> > https://github.com/python/peps/pull/229/files/70c6c1d010c1d50a375430c4
> > ba6ae3e4f439306c#r107471836 ).
>
> The idea is that the doc build is done as part of CI and the product is
> uploaded as static content (GH pages is an option, but it might be
> anything capable of serving static content).
>

One place where this might actually show itself to be useful is with the
PEPs. That build toolchain generates HTML files directly and doesn't even
use Sphinx (at least not yet). I have opened
https://github.com/python/peps/issues/241 to discuss the idea.


>
> One of the reasons why we went with GH Pages for asyncpg is that at the
> time RTFD did not support Python 3.5 syntax and we wanted to use
> autodoc.  Could this be an issue when building Python documentation?
> Can the master branch Docs/ be built by Sphinx running on Python 3.4?
>

There's no version requirement for the docs as we don't use the autodoc
extension. And I think Read the Docs uses a newer image now as I was
buliding the docs for gidgethub using autodoc and that uses 3.5 syntax.

And how would versions be handles for GH Pages? E.g. how would
docs.python.org handle viewing the e.g. 2.7 data? I guess you're just
really careful to upload to subdirectories in the gh-pages branch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/42a1abda/attachment.html>

From elprans at gmail.com  Tue Apr 11 16:19:25 2017
From: elprans at gmail.com (Elvis Pranskevichus)
Date: Tue, 11 Apr 2017 16:19:25 -0400
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <CAP1=2W6LYY7VYzn0xzvKXOdDynxcuWF2qOh7vsXoCs8Lg_r8gw@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <1831160.nZKQcDNxVD@hammer.magicstack.net>
 <CAP1=2W6LYY7VYzn0xzvKXOdDynxcuWF2qOh7vsXoCs8Lg_r8gw@mail.gmail.com>
Message-ID: <3165935.7BGLocH1Sy@hammer.magicstack.net>

On Tuesday, April 11, 2017 4:11:44 PM EDT Brett Cannon wrote:
> One place where this might actually show itself to be useful is with
> the PEPs. That build toolchain generates HTML files directly and
> doesn't even use Sphinx (at least not yet). I have opened
> https://github.com/python/peps/issues/241 to discuss the idea.

Sounds like a good place to try the process.

> > One of the reasons why we went with GH Pages for asyncpg is that at
> > the time RTFD did not support Python 3.5 syntax and we wanted to
> > use autodoc.  Could this be an issue when building Python
> > documentation? Can the master branch Docs/ be built by Sphinx
> > running on Python 3.4?
> There's no version requirement for the docs as we don't use the
> autodoc extension. And I think Read the Docs uses a newer image now
> as I was buliding the docs for gidgethub using autodoc and that uses
> 3.5 syntax.
> 
> And how would versions be handles for GH Pages? E.g. how would
> docs.python.org handle viewing the e.g. 2.7 data? I guess you're just
> really careful to upload to subdirectories in the gh-pages branch?

Yes, we can continue using the current switcher and subfolders.


                            Elvis 

From mariatta.wijaya at gmail.com  Tue Apr 11 16:47:38 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 11 Apr 2017 13:47:38 -0700
Subject: [core-workflow] Where to host documentation? (was: Voting on
 possible subdomains for the devguide)
In-Reply-To: <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <CAP1=2W428S3quvnMs4MnxBL6ZyBiU6i6VVUmXZt=3QRr6XwyoQ@mail.gmail.com>
 <20170411180933.GA2927@phdru.name> <4015620.e0R3kIOpp5@hammer.magicstack.net>
 <CAP1=2W7mFAGw-iJH3_mx0eELmdcQLy+C2bYGZF=Kny7gbyRr3w@mail.gmail.com>
Message-ID: <CAGbohnZP4r7UETYEjfLCUtmKN_A-MX51T+zs2mYc9JJh1E71kg@mail.gmail.com>

My understanding is that by hosting the docs at RTD, we'll be getting
better search feature powered by Elasticsearch, instead of the built-in
sphinx search.
If so, I would prefer this route.



Mariatta Wijaya

On Tue, Apr 11, 2017 at 12:11 PM, Brett Cannon <brett at python.org> wrote:

>
>
> On Tue, 11 Apr 2017 at 11:28 Elvis Pranskevichus <elprans at gmail.com>
> wrote:
>
>> On Tuesday, April 11, 2017 2:09:33 PM EDT Oleg Broytman wrote:
>> > On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <
>> brett at python.org> wrote:
>> > > On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus <elprans at gmail.com>
>> wrote:
>> > > > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote:
>> > > > > Last I heard from then, RTD was struggling financially. Hosting
>> > > > > isn't
>> > > > > really free, you know -- nor is administering a site like that
>> > > > > :-).
>> > > > > The PSF should offer to cover their costs for hosting the Python
>> > > > > docs, which I presume are pretty dang popular compared to many
>> > > > > other
>> > > > > things currently hosted at RTD -- the peps and devguide won't
>> > > > > cause
>> > > > > any load in comparison.
>> > > >
>> > > > Is Gihub Pages considered an option?  We host the asyncpg docs [1]
>> > > > there.  Builds are done by Travis.  The advantage is that we don't
>> > > > have to add another service dependency.
>> > >
>> > > I guess so. No one has ever suggested it before or bothered to set
>> > > it up to show how it would work. :)
>> >
>> >    GH Pages don't need much to setup. You have to choose between Org
>> > Pages (at the root of the subdomain) and Repo Pages (in
>> > subdirectories). I even believe GH Pages can do both on the same
>> > subdomain but I've never tried.
>>
>> GH Pages support custom domain redirects [1].  "setup" in this case
>> is putting together scripts to automate sphinx runs and the git push
>> of the compiled output to the appropriate repo/branch.
>
>
> So we would have to either set up another repo or commit the rendered
> files to the repo?
>
>
>>   If there's
>> interest in pursuing this option, I can help with setting things up.
>>
>
> I assume we would lose the widget Read the Docs provides which is handy
> for getting to the GitHub page for editing the content? I guess we lose
> anything else that https://docs.readthedocs.io/en/latest/features.html
> lists.
>
> I'm just trying to think of what we gain/lose if we switch to GH Pages
> over RTFD as I don't want to end up with three different documentation
> hosting solutions sort of like we have now where we build the devguide,
> PEPs, and the docs themselves in special ways that all happen to be hosted
> on PSF infrastructure (e.g. getting Pygments installed for the PEPs has
> stalled out and it would be good that any solution we choose be flexible
> enough to handle this kind of situation: https://github.com/
> python/peps/pull/229/files/70c6c1d010c1d50a375430c4ba6ae3
> e4f439306c#r107471836).
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/30b2200a/attachment-0001.html>

From nad at python.org  Tue Apr 11 17:13:13 2017
From: nad at python.org (Ned Deily)
Date: Tue, 11 Apr 2017 17:13:13 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
Message-ID: <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>

On Apr 11, 2017, at 12:50, Brett Cannon <brett at python.org> wrote:
> With part of the goal of moving to GitHub being to minimize how much infrastructure we have to run, one of the long-term goals I have is to use Read the Docs to host Python's documentation. But to get there we have to move any "special" docs over first. That means relocating the devguide (it also means relocating the PEPs, but that's another issue and is blocked first and foremost by https://github.com/python/peps/issues/4).

From a current infrastructure POV, there are several different issues here.  IIUC, currently we have at least three server instances involved in python.org docs.

1. I believe, the PEP docs are built and served from the main python.org server where the main Django-based python.org website is based.  AFAIK, no one is proposing to replace that server.  I'm not sure why the PEP docs are served there and not on the "docs" server (server 3 below); probably just an artifact of the gradual migration from the old python.org website infrastructure (e.g. dinsdale) several years ago.

2, The second server is used to serve the download files for releases, like source tar balls, binary installers (Win/Mac), and the pre-built documentation formats (PDF, HTML, epub, etc) for each release (for example, https://docs.python.org/release/3.6.1/download.html has download links like https://docs.python.org/ftp/python/doc/3.6.1/python-3.6.1-docs-pdf-letter.zip).  These files are built and managed by the release managers for each release and do not get updated.

3. The third server is used to serve the most recent HTML version of docs for *all* Python releases going back to 1.4.  Docs prior to 2.6 (?) were not produced with Sphinx, so are effectively static HTML except possibly for JavaScript.  The HTML versions of docs for releases still receiving maintenance fixes are auto-updated each day using Sphinx (for example, https://docs.python.org/release/3.6.1/index.html).

So, to actually reduce the number of servers in the PSF infrastructure, solutions for all of these docs need to be found.  Since the main python.org server is not going away, I'm not sure what is gained by spending a lot of time on trying to eliminate the other two, which I suspect are very low-maintenance and could probably be combined.  In other words, I guess I don't see how we gain much, if anything, in trying to move things to RTD.


--
  Ned Deily
  nad at python.org -- []


From brett at python.org  Tue Apr 11 18:12:23 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 11 Apr 2017 22:12:23 +0000
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
Message-ID: <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>

On Tue, 11 Apr 2017 at 14:42 Ned Deily <nad at python.org> wrote:

> On Apr 11, 2017, at 12:50, Brett Cannon <brett at python.org> wrote:
> > With part of the goal of moving to GitHub being to minimize how much
> infrastructure we have to run, one of the long-term goals I have is to use
> Read the Docs to host Python's documentation. But to get there we have to
> move any "special" docs over first. That means relocating the devguide (it
> also means relocating the PEPs, but that's another issue and is blocked
> first and foremost by https://github.com/python/peps/issues/4).
>
> From a current infrastructure POV, there are several different issues
> here.  IIUC, currently we have at least three server instances involved in
> python.org docs.
>
> 1. I believe, the PEP docs are built and served from the main python.org
> server where the main Django-based python.org website is based.  AFAIK,
> no one is proposing to replace that server.  I'm not sure why the PEP docs
> are served there and not on the "docs" server (server 3 below); probably
> just an artifact of the gradual migration from the old python.org website
> infrastructure (e.g. dinsdale) several years ago.
>

python.org doesn't fall under python-dev's purview so I'm not proposing to
do anything here except get the PEPs taken out.


>
> 2, The second server is used to serve the download files for releases,
> like source tar balls, binary installers (Win/Mac), and the pre-built
> documentation formats (PDF, HTML, epub, etc) for each release (for example,
> https://docs.python.org/release/3.6.1/download.html has download links
> like
> https://docs.python.org/ftp/python/doc/3.6.1/python-3.6.1-docs-pdf-letter.zip).
> These files are built and managed by the release managers for each release
> and do not get updated.
>
> 3. The third server is used to serve the most recent HTML version of docs
> for *all* Python releases going back to 1.4.  Docs prior to 2.6 (?) were
> not produced with Sphinx, so are effectively static HTML except possibly
> for JavaScript.  The HTML versions of docs for releases still receiving
> maintenance fixes are auto-updated each day using Sphinx (for example,
> https://docs.python.org/release/3.6.1/index.html).
>
> So, to actually reduce the number of servers in the PSF infrastructure,
> solutions for all of these docs need to be found.  Since the main
> python.org server is not going away, I'm not sure what is gained by
> spending a lot of time on trying to eliminate the other two, which I
> suspect are very low-maintenance and could probably be combined.  In other
> words, I guess I don't see how we gain much, if anything, in trying to move
> things to RTD.
>

>From my perspective there are a few reasons for thinking about moving. One
is that low-maintenance isn't no-maintenance. Anything that helps take some
load off the infrastructure team is a good thing in my opinion (especially
when the PEPs and devguides are "unique snowflakes" in all of this as they
are not built like the rest of docs.python.org). Two, getting changes to
these machines isn't always easy or fast. As I pointed out to Elvis, we
don't have Pygments installed so we can get source highlighting in PEPs and
the PR to fix it has been sitting there for quite a while. And because the
infrastructure is custom not many people even know where to make changes to
change things like what dependencies are installed are on the machines (I
mean how many people even knew there are three machines before this
email?). Three,  updates to any of these docs only happens a couple of
times a day instead of instantly. Obviously not always a big deal, but for
the PEPs it can be annoying when you want to email out the link to the
rendered version and you can't simply because the cron job has not run yet.

So even if we can't get rid of docs.python.org and we don't move that over
to RTD, at least getting python.org/dev/peps and docs.python.org/devguide
to no longer be odd-ball infrastructure points is still a win in my book.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/8cf9e19a/attachment.html>

From willingc at willingconsulting.com  Tue Apr 11 18:29:32 2017
From: willingc at willingconsulting.com (Carol Willing)
Date: Tue, 11 Apr 2017 15:29:32 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
Message-ID: <58ED58CC.1060603@willingconsulting.com>



Brett Cannon wrote:
>
>
> On Tue, 11 Apr 2017 at 14:42 Ned Deily <nad at python.org 
> <mailto:nad at python.org>> wrote:
>
>     On Apr 11, 2017, at 12:50, Brett Cannon <brett at python.org
>     <mailto:brett at python.org>> wrote:
>     > With part of the goal of moving to GitHub being to minimize how
>     much infrastructure we have to run, one of the long-term goals I
>     have is to use Read the Docs to host Python's documentation. But
>     to get there we have to move any "special" docs over first. That
>     means relocating the devguide (it also means relocating the PEPs,
>     but that's another issue and is blocked first and foremost by
>     https://github.com/python/peps/issues/4).
>
>     From a current infrastructure POV, there are several different
>     issues here.  IIUC, currently we have at least three server
>     instances involved in python.org <http://python.org> docs.
>
>     1. I believe, the PEP docs are built and served from the main
>     python.org <http://python.org> server where the main Django-based
>     python.org <http://python.org> website is based.  AFAIK, no one is
>     proposing to replace that server.  I'm not sure why the PEP docs
>     are served there and not on the "docs" server (server 3 below);
>     probably just an artifact of the gradual migration from the old
>     python.org <http://python.org> website infrastructure (e.g.
>     dinsdale) several years ago.
>
>
> python.org <http://python.org> doesn't fall under python-dev's purview 
> so I'm not proposing to do anything here except get the PEPs taken out.

Big +1 on moving the PEPs.

>
>     2, The second server is used to serve the download files for
>     releases, like source tar balls, binary installers (Win/Mac), and
>     the pre-built documentation formats (PDF, HTML, epub, etc) for
>     each release (for example,
>     https://docs.python.org/release/3.6.1/download.html has download
>     links like
>     https://docs.python.org/ftp/python/doc/3.6.1/python-3.6.1-docs-pdf-letter.zip). 
>     These files are built and managed by the release managers for each
>     release and do not get updated.
>
>     3. The third server is used to serve the most recent HTML version
>     of docs for *all* Python releases going back to 1.4.  Docs prior
>     to 2.6 (?) were not produced with Sphinx, so are effectively
>     static HTML except possibly for JavaScript.  The HTML versions of
>     docs for releases still receiving maintenance fixes are
>     auto-updated each day using Sphinx (for example,
>     https://docs.python.org/release/3.6.1/index.html).
>
>     So, to actually reduce the number of servers in the PSF
>     infrastructure, solutions for all of these docs need to be found. 
>     Since the main python.org <http://python.org> server is not going
>     away, I'm not sure what is gained by spending a lot of time on
>     trying to eliminate the other two, which I suspect are very
>     low-maintenance and could probably be combined.  In other words, I
>     guess I don't see how we gain much, if anything, in trying to move
>     things to RTD.
>
>
> From my perspective there are a few reasons for thinking about moving. 
> One is that low-maintenance isn't no-maintenance. Anything that helps 
> take some load off the infrastructure team is a good thing in my 
> opinion (especially when the PEPs and devguides are "unique 
> snowflakes" in all of this as they are not built like the rest of 
> docs.python.org <http://docs.python.org>).

I agree. ReadTheDocs has some effective hooks and badges for 
operations/build status. It's straightforward to administer. It also has 
the added benefit that it is where many Python users go to search for 
documentation.

> Two, getting changes to these machines isn't always easy or fast. As I 
> pointed out to Elvis, we don't have Pygments installed so we can get 
> source highlighting in PEPs and the PR to fix it has been sitting 
> there for quite a while. And because the infrastructure is custom not 
> many people even know where to make changes to change things like what 
> dependencies are installed are on the machines (I mean how many people 
> even knew there are three machines before this email?).

I also think this is a win since it is much easier to create a 
consistent build environment using readthedoc.yml and environment.yml 
files. I'm also in favor of RTD over Jekyll or hosting on GitHub since 
Eric has been a key evangelist for Python for a long time and the code 
for RTD is a Python/Django base. (As an aside, I agree with Guido that 
we should provide some level of financial support towards RTD 
sustainability).

> Three,  updates to any of these docs only happens a couple of times a 
> day instead of instantly. Obviously not always a big deal, but for the 
> PEPs it can be annoying when you want to email out the link to the 
> rendered version and you can't simply because the cron job has not run 
> yet.
>
> So even if we can't get rid of docs.python.org 
> <http://docs.python.org> and we don't move that over to RTD, at least 
> getting python.org/dev/peps <http://python.org/dev/peps> and 
> docs.python.org/devguide <http://docs.python.org/devguide> to no 
> longer be odd-ball infrastructure points is still a win in my book.

While RTD may or may not be right for docs.python.org, I think it's 
worth looking at least mirroring the CPython docs on RTD. An added 
benefit for hosting on RTD is that there is lots of documentation around 
for using Sphinx/RTD which provides an opportunity for attracting more 
contributors to documentation and community management.

> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/c5d5711e/attachment-0001.html>

From nad at python.org  Tue Apr 11 20:18:06 2017
From: nad at python.org (Ned Deily)
Date: Tue, 11 Apr 2017 20:18:06 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
Message-ID: <57D13121-0CF6-4870-813B-DC69EC22E688@python.org>

On Apr 11, 2017, at 18:12, Brett Cannon <brett at python.org> wrote:
> From my perspective there are a few reasons for thinking about moving. One is that low-maintenance isn't no-maintenance. Anything that helps take some load off the infrastructure team is a good thing in my opinion (especially when the PEPs and devguides are "unique snowflakes" in all of this as they are not built like the rest of docs.python.org). Two, getting changes to these machines isn't always easy or fast. As I pointed out to Elvis, we don't have Pygments installed so we can get source highlighting in PEPs and the PR to fix it has been sitting there for quite a while.

There are a number of people who could do that.  Perhaps pinging the issue would help?

> And because the infrastructure is custom not many people even know where to make changes to change things like what dependencies are installed are on the machines (I mean how many people even knew there are three machines before this email?). Three,  updates to any of these docs only happens a couple of times a day instead of instantly. Obviously not always a big deal, but for the PEPs it can be annoying when you want to email out the link to the rendered version and you can't simply because the cron job has not run yet.

Most of the scripting is on github:

https://github.com/python/docsbuild-scripts
https://github.com/python/pythondotorg

And any of the infra team can change the cron jobs to run more frequently :)

> So even if we can't get rid of docs.python.org and we don't move that over to RTD, at least getting python.org/dev/peps and docs.python.org/devguide to no longer be odd-ball infrastructure points is still a win in my book.

OK, I don't have a big problem with moving the devguide and/or the PEPs, though I do think Guido has a point about being mindful of adding burden to the RTD folks (although, yes, that's probably not a big deal for the devguide and probably not for the PEPs either).  And I don't think moving them is going to make any significant difference in the workload of the Python infra team as long as we do not outsource the main python.org web site components.  My big concern would be with trying to move the rest of the docs.  That is much more complicated and has implications for the release process and backward compatibility wrt URLs etc etc.  (Release managers handle a lot of the complexities of this behind the scenes.)  I would urge that we not make that (e.g. moving the rest of the docs) a goal for now.
  
--
  Ned Deily
  nad at python.org -- []


From donald at stufft.io  Tue Apr 11 20:25:15 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 11 Apr 2017 20:25:15 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <57D13121-0CF6-4870-813B-DC69EC22E688@python.org>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
 <57D13121-0CF6-4870-813B-DC69EC22E688@python.org>
Message-ID: <A76CB83C-F782-45F1-ADAD-AF7B61F98C56@stufft.io>


> On Apr 11, 2017, at 8:18 PM, Ned Deily <nad at python.org> wrote:
> 
> OK, I don't have a big problem with moving the devguide and/or the PEPs, though I do think Guido has a point about being mindful of adding burden to the RTD folks (although, yes, that's probably not a big deal for the devguide and probably not for the PEPs either).  And I don't think moving them is going to make any significant difference in the workload of the Python infra team as long as we do not outsource the main python.org <http://python.org/> web site components.  My big concern would be with trying to move the rest of the docs.  That is much more complicated and has implications for the release process and backward compatibility wrt URLs etc etc.  (Release managers handle a lot of the complexities of this behind the scenes.)  I would urge that we not make that (e.g. moving the rest of the docs) a goal for now.


*Puts Infra Hat on*

Outsourcing is always good where possible. We?re technically over our donation amount for Rackspace so we?re paying for some servers and bandwidth now. That being said, these particular machines are not high maintenance but it would still be nice to get them off of our infra if possible/reasonable.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/b28698b9/attachment.html>

From nad at python.org  Tue Apr 11 20:25:55 2017
From: nad at python.org (Ned Deily)
Date: Tue, 11 Apr 2017 20:25:55 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <58ED58CC.1060603@willingconsulting.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
 <58ED58CC.1060603@willingconsulting.com>
Message-ID: <0CE8ACDB-26F8-4596-99C0-D007145BE1C2@python.org>

On Apr 11, 2017, at 18:29, Carol Willing <willingc at willingconsulting.com> wrote:
> While RTD may or may not be right for docs.python.org, I think it's worth looking at least mirroring the CPython docs on RTD. An added benefit for hosting on RTD is that there is lots of documentation around for using Sphinx/RTD which provides an opportunity for attracting more contributors to documentation and community management.

I guess I don't see the value of maintaining a RTD mirror for CPython docs as long as we are also serving the documents from docs.python.org, something which I think we need to continue to do.  There is a fair amount of work that goes on behind the scenes with each release for maintaining the docs, not all of which is included in the docs source itself, things like updating symlinks and redirects and what not.  Adding the mirror seems like adding extra work for no gain.  And how would Sphinx documentation not also apply to the current CPython docs as served on docs.python.org? 

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue Apr 11 20:32:48 2017
From: nad at python.org (Ned Deily)
Date: Tue, 11 Apr 2017 20:32:48 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <A76CB83C-F782-45F1-ADAD-AF7B61F98C56@stufft.io>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
 <57D13121-0CF6-4870-813B-DC69EC22E688@python.org>
 <A76CB83C-F782-45F1-ADAD-AF7B61F98C56@stufft.io>
Message-ID: <B2630B55-F153-45FD-9A87-553F8672BDDD@python.org>

On Apr 11, 2017, at 20:25, Donald Stufft <donald at stufft.io> wrote:
> *Puts Infra Hat on*
> 
> Outsourcing is always good where possible. We?re technically over our donation amount for Rackspace so we?re paying for some servers and bandwidth now. That being said, these particular machines are not high maintenance but it would still be nice to get them off of our infra if possible/reasonable.

Sure, I agree.  But without substantially revising how we provide documentation and release downloadables - things which I suggest we not contemplate now as being beyond the scope of this project - we wouldn't be able to get rid of any machines for now.  Moving the devguide and peps will not allow us to free any machines up - at least as best I understand it!  So that's really not a factor at this point.  Unless I'm missing something.

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue Apr 11 20:43:37 2017
From: nad at python.org (Ned Deily)
Date: Tue, 11 Apr 2017 20:43:37 -0400
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
Message-ID: <50F6F6E7-6F87-4EE5-A127-EE6C35DD4615@python.org>

On Apr 11, 2017, at 18:12, Brett Cannon <brett at python.org> wrote:
> python.org doesn't fall under python-dev's purview so I'm not proposing to do anything here except get the PEPs taken out.

Just for the record, the main python.org Django CMS is a critical component in making CPython releases.  Release managers do lots of things there and we have some say in maintaining and enhancing it.  So, to that extent, it's important to recognize that it is a core component of CPython releases and, as such, is of interest to python-dev.

--
  Ned Deily
  nad at python.org -- []


From willingc at willingconsulting.com  Tue Apr 11 22:32:48 2017
From: willingc at willingconsulting.com (Carol Willing)
Date: Tue, 11 Apr 2017 19:32:48 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <0CE8ACDB-26F8-4596-99C0-D007145BE1C2@python.org>
References: <CAP1=2W7KwDjc56FE3Mkff_4VXa3RuN2eGHQPnzaBz7t+1qJA=A@mail.gmail.com>
 <7E2A81B0-10D3-4544-97DD-7168D26B1058@python.org>
 <CAP1=2W5S9HiqCB=tM4X8NTzbHksLyBG7pYz52SYzpoxgWOpc8g@mail.gmail.com>
 <58ED58CC.1060603@willingconsulting.com>
 <0CE8ACDB-26F8-4596-99C0-D007145BE1C2@python.org>
Message-ID: <58ED91D0.4080802@willingconsulting.com>



Ned Deily wrote:
> On Apr 11, 2017, at 18:29, Carol Willing<willingc at willingconsulting.com>  wrote:
>> While RTD may or may not be right for docs.python.org, I think it's worth looking at least mirroring the CPython docs on RTD. An added benefit for hosting on RTD is that there is lots of documentation around for using Sphinx/RTD which provides an opportunity for attracting more contributors to documentation and community management.
>
> I guess I don't see the value of maintaining a RTD mirror for CPython docs as long as we are also serving the documents from docs.python.org, something which I think we need to continue to do.

I'm not advocating moving to the current docs right now, but I do 
believe there is value in having some form of the current master 3 docs 
on RTD. The value comes from these benefits:

- a place to begin simplifying the documentation workflow for both 
maintainability (bus factor) and attracting a wider group of 
contributors and reviewers
- making the documentation development and review process simpler would 
encourage people who are good writers and educators to contribute more 
to the "how to use" sections of the docs

While the reference sections of the docs are excellent, the tutorials 
and "how to" sections could be more community focused.

I'm throwing it out as a suggestion for improvement, not a distraction 
or extra work. I'm happy to keep the status quo too.

> There is a fair amount of work that goes on behind the scenes with each release for maintaining the docs, not all of which is included in the docs source itself, things like updating symlinks and redirects and what not.  Adding the mirror seems like adding extra work for no gain.  And how would Sphinx documentation not also apply to the current CPython docs as served on docs.python.org?
>
> --
>    Ned Deily
>    nad at python.org -- []
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170411/29e28576/attachment.html>

From eric at ericholscher.com  Tue Apr 11 19:43:35 2017
From: eric at ericholscher.com (Eric Holscher)
Date: Tue, 11 Apr 2017 16:43:35 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
Message-ID: <CA+=+m6TWUJ4e1e6+wJa+2r0rZVDdMC4FyGuQE7RQX44ccVRqpw@mail.gmail.com>

I'm not subbed to this list, so clicked the link from the web UI,
which contains no history/quotes. Sorry!

Just a few points:

* We provide search that is backed by Elastic Search, which provides a
lot more power. We also have more customizations that will allow us to
provide search across projects within the python docs search, if
wanted. So you could also return PEP's, devguide, and other search
results if that was useful.
* Any improvements that we made to RTD in order to better support
Python would also be shared with the Python ecosystem. So instead of
spending time writing build scripts and services, we could be
contributing to an existing project that is widely used in the
community. This would hopefully help us increase developer
contributions to Read the Docs, raising all boats in the community.
* We run on nginx servers, so we can do custom rules for Python if
necessary. This is really useful for things like redirects and custom
headers.
* We automatically generate PDF's, Epub's, and JSON HTML versions of
the docs, which I don't believe is currently happening.
* We have lots of other things that are nice features
(http://docs.readthedocs.io/en/latest/features.html), which static
file hosting won't have, and the site is still under active
development. We have servers running behind the code, and in the
future plan to extend things like intersphinx to be much more
powerful, using server based software. Sphinx itself is always limited
in it's design by being a static site, and we remove that requirement
(in a way that is generally additive, so it downgrades to Sphinx).

I would also say that we'd hope the PSF would help fund the site in an
ongoing manner under this arrangement. The PSF has given us grants in
the past for our support of the Python ecosystem, and this would just
cement that relationship even more. By hosting on RTD and supporting
us financially, you'd also be helping support the entire ecosystem.
That said, it isn't a prerequisite for migrating to RTD, but I think
it would make a strong case for sustained funding.

Cheers,
Eric

-- 
Eric Holscher
Maker of the internet residing in Portland, Oregon
http://ericholscher.com

From guido at python.org  Wed Apr 12 12:35:58 2017
From: guido at python.org (Guido van Rossum)
Date: Wed, 12 Apr 2017 09:35:58 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CA+=+m6TWUJ4e1e6+wJa+2r0rZVDdMC4FyGuQE7RQX44ccVRqpw@mail.gmail.com>
References: <CA+=+m6TWUJ4e1e6+wJa+2r0rZVDdMC4FyGuQE7RQX44ccVRqpw@mail.gmail.com>
Message-ID: <CAP7+vJ+XMJg-=rvUhXt2FjY7iz1Zsxyq=6x-tH3DiLVCSa+P4Q@mail.gmail.com>

+1

On Tue, Apr 11, 2017 at 4:43 PM, Eric Holscher <eric at ericholscher.com>
wrote:

> I'm not subbed to this list, so clicked the link from the web UI,
> which contains no history/quotes. Sorry!
>
> Just a few points:
>
> * We provide search that is backed by Elastic Search, which provides a
> lot more power. We also have more customizations that will allow us to
> provide search across projects within the python docs search, if
> wanted. So you could also return PEP's, devguide, and other search
> results if that was useful.
> * Any improvements that we made to RTD in order to better support
> Python would also be shared with the Python ecosystem. So instead of
> spending time writing build scripts and services, we could be
> contributing to an existing project that is widely used in the
> community. This would hopefully help us increase developer
> contributions to Read the Docs, raising all boats in the community.
> * We run on nginx servers, so we can do custom rules for Python if
> necessary. This is really useful for things like redirects and custom
> headers.
> * We automatically generate PDF's, Epub's, and JSON HTML versions of
> the docs, which I don't believe is currently happening.
> * We have lots of other things that are nice features
> (http://docs.readthedocs.io/en/latest/features.html), which static
> file hosting won't have, and the site is still under active
> development. We have servers running behind the code, and in the
> future plan to extend things like intersphinx to be much more
> powerful, using server based software. Sphinx itself is always limited
> in it's design by being a static site, and we remove that requirement
> (in a way that is generally additive, so it downgrades to Sphinx).
>
> I would also say that we'd hope the PSF would help fund the site in an
> ongoing manner under this arrangement. The PSF has given us grants in
> the past for our support of the Python ecosystem, and this would just
> cement that relationship even more. By hosting on RTD and supporting
> us financially, you'd also be helping support the entire ecosystem.
> That said, it isn't a prerequisite for migrating to RTD, but I think
> it would make a strong case for sustained funding.
>
> Cheers,
> Eric
>
> --
> Eric Holscher
> Maker of the internet residing in Portland, Oregon
> http://ericholscher.com
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170412/c03c042c/attachment.html>

From mariatta.wijaya at gmail.com  Wed Apr 12 12:48:53 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Wed, 12 Apr 2017 09:48:53 -0700
Subject: [core-workflow] Voting on possible subdomains for the devguide
In-Reply-To: <CA+=+m6TWUJ4e1e6+wJa+2r0rZVDdMC4FyGuQE7RQX44ccVRqpw@mail.gmail.com>
References: <CA+=+m6TWUJ4e1e6+wJa+2r0rZVDdMC4FyGuQE7RQX44ccVRqpw@mail.gmail.com>
Message-ID: <CAGbohnZ2AtRNNaQaFZD9SbTpFNLXCwdM94oNjDN7j9pf8cmfbQ@mail.gmail.com>

+1

On Apr 12, 2017 9:29 AM, "Eric Holscher" <eric at ericholscher.com> wrote:

> I'm not subbed to this list, so clicked the link from the web UI,
> which contains no history/quotes. Sorry!
>
> Just a few points:
>
> * We provide search that is backed by Elastic Search, which provides a
> lot more power. We also have more customizations that will allow us to
> provide search across projects within the python docs search, if
> wanted. So you could also return PEP's, devguide, and other search
> results if that was useful.
> * Any improvements that we made to RTD in order to better support
> Python would also be shared with the Python ecosystem. So instead of
> spending time writing build scripts and services, we could be
> contributing to an existing project that is widely used in the
> community. This would hopefully help us increase developer
> contributions to Read the Docs, raising all boats in the community.
> * We run on nginx servers, so we can do custom rules for Python if
> necessary. This is really useful for things like redirects and custom
> headers.
> * We automatically generate PDF's, Epub's, and JSON HTML versions of
> the docs, which I don't believe is currently happening.
> * We have lots of other things that are nice features
> (http://docs.readthedocs.io/en/latest/features.html), which static
> file hosting won't have, and the site is still under active
> development. We have servers running behind the code, and in the
> future plan to extend things like intersphinx to be much more
> powerful, using server based software. Sphinx itself is always limited
> in it's design by being a static site, and we remove that requirement
> (in a way that is generally additive, so it downgrades to Sphinx).
>
> I would also say that we'd hope the PSF would help fund the site in an
> ongoing manner under this arrangement. The PSF has given us grants in
> the past for our support of the Python ecosystem, and this would just
> cement that relationship even more. By hosting on RTD and supporting
> us financially, you'd also be helping support the entire ecosystem.
> That said, it isn't a prerequisite for migrating to RTD, but I think
> it would make a strong case for sustained funding.
>
> Cheers,
> Eric
>
> --
> Eric Holscher
> Maker of the internet residing in Portland, Oregon
> http://ericholscher.com
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170412/b3d84593/attachment-0001.html>

From brett at python.org  Sat Apr 15 18:21:26 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 15 Apr 2017 22:21:26 +0000
Subject: [core-workflow] What do people want Bedevere to do for issue
 numbers in PRs?
Message-ID: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>

When I implemented Bedevere's bpo issue number detection it was to do it as
a status check as I thought that's what people wanted (
https://github.com/python/core-workflow/issues/13). But now others are
saying they want a comment with a link to the issue number (
https://github.com/python/bedevere/issues/3).

So which one(s)? :) The status check has the perk of being very visible so
that people know it's missing (arguably if you don't check your PR you
won't notice the failure, but if you're not checking the status of the PR
then there are other problems to attend to). The drawback is that you have
to know that the Details link for a successful check links to
bugs.python.org and that once the PR is closed the link is gone. The perk
of a comment is it's in your face and easy to find. The drawback of a
comment is you always be notified about the comment which might get
tiresome.

So what I'm asking is what do people want? The status check? A comment?
Both? I know people want *something* since dealing with specifying the
issue number has been coming up consistently since we started the new
workflow, but at this point I want a clear understanding of what people
want so this can be settled appropriately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170415/993d16a0/attachment.html>

From donald at stufft.io  Sat Apr 15 21:24:46 2017
From: donald at stufft.io (Donald Stufft)
Date: Sat, 15 Apr 2017 21:24:46 -0400
Subject: [core-workflow] What do people want Bedevere to do for issue
 numbers in PRs?
In-Reply-To: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>
References: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>
Message-ID: <43F6B694-4CC9-4482-A828-D4F0A329818B@stufft.io>

What about editing the original message to include a link in addition to the status check?

Sent from my iPhone

> On Apr 15, 2017, at 6:21 PM, Brett Cannon <brett at python.org> wrote:
> 
> When I implemented Bedevere's bpo issue number detection it was to do it as a status check as I thought that's what people wanted (https://github.com/python/core-workflow/issues/13). But now others are saying they want a comment with a link to the issue number (https://github.com/python/bedevere/issues/3).
> 
> So which one(s)? :) The status check has the perk of being very visible so that people know it's missing (arguably if you don't check your PR you won't notice the failure, but if you're not checking the status of the PR then there are other problems to attend to). The drawback is that you have to know that the Details link for a successful check links to bugs.python.org and that once the PR is closed the link is gone. The perk of a comment is it's in your face and easy to find. The drawback of a comment is you always be notified about the comment which might get tiresome.
> 
> So what I'm asking is what do people want? The status check? A comment? Both? I know people want *something* since dealing with specifying the issue number has been coming up consistently since we started the new workflow, but at this point I want a clear understanding of what people want so this can be settled appropriately.
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170415/c3770e3b/attachment.html>

From brett at python.org  Sun Apr 16 14:49:59 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 16 Apr 2017 18:49:59 +0000
Subject: [core-workflow] What do people want Bedevere to do for issue
 numbers in PRs?
In-Reply-To: <43F6B694-4CC9-4482-A828-D4F0A329818B@stufft.io>
References: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>
 <43F6B694-4CC9-4482-A828-D4F0A329818B@stufft.io>
Message-ID: <CAP1=2W6dU4OEo0uQQok+3oiWnvdNxnrZT5jPcQiNqa6QPgPqyw@mail.gmail.com>

Appending to the body of the pull request is an interesting idea. I'm not
sure what permissions the bot would need to have to be able to do that,
though (write access with public_repo?).

On Sat, 15 Apr 2017 at 18:24 Donald Stufft <donald at stufft.io> wrote:

> What about editing the original message to include a link in addition to
> the status check?
>
> Sent from my iPhone
>
> On Apr 15, 2017, at 6:21 PM, Brett Cannon <brett at python.org> wrote:
>
> When I implemented Bedevere's bpo issue number detection it was to do it
> as a status check as I thought that's what people wanted (
> https://github.com/python/core-workflow/issues/13). But now others are
> saying they want a comment with a link to the issue number (
> https://github.com/python/bedevere/issues/3).
>
> So which one(s)? :) The status check has the perk of being very visible so
> that people know it's missing (arguably if you don't check your PR you
> won't notice the failure, but if you're not checking the status of the PR
> then there are other problems to attend to). The drawback is that you have
> to know that the Details link for a successful check links to
> bugs.python.org and that once the PR is closed the link is gone. The perk
> of a comment is it's in your face and easy to find. The drawback of a
> comment is you always be notified about the comment which might get
> tiresome.
>
> So what I'm asking is what do people want? The status check? A comment?
> Both? I know people want *something* since dealing with specifying the
> issue number has been coming up consistently since we started the new
> workflow, but at this point I want a clear understanding of what people
> want so this can be settled appropriately.
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170416/e06e677f/attachment.html>

From ncoghlan at gmail.com  Mon Apr 17 00:24:13 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 17 Apr 2017 14:24:13 +1000
Subject: [core-workflow] What do people want Bedevere to do for issue
 numbers in PRs?
In-Reply-To: <CAP1=2W6dU4OEo0uQQok+3oiWnvdNxnrZT5jPcQiNqa6QPgPqyw@mail.gmail.com>
References: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>
 <43F6B694-4CC9-4482-A828-D4F0A329818B@stufft.io>
 <CAP1=2W6dU4OEo0uQQok+3oiWnvdNxnrZT5jPcQiNqa6QPgPqyw@mail.gmail.com>
Message-ID: <CADiSq7eLzug3UoqXvtd63PF3rZyrronB1yJ6AX-MPZa2z5VVXQ@mail.gmail.com>

On 17 April 2017 at 04:49, Brett Cannon <brett at python.org> wrote:
> Appending to the body of the pull request is an interesting idea. I'm not
> sure what permissions the bot would need to have to be able to do that,
> though (write access with public_repo?).

If you can figure out how to make it work, I think that plus a status
check would be the best option.

Failing that, I think a comment would be a bit spammy, unless Bedevere
was smart enough not to comment on backport PRs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Mon Apr 17 14:30:00 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 17 Apr 2017 18:30:00 +0000
Subject: [core-workflow] What do people want Bedevere to do for issue
 numbers in PRs?
In-Reply-To: <CADiSq7eLzug3UoqXvtd63PF3rZyrronB1yJ6AX-MPZa2z5VVXQ@mail.gmail.com>
References: <CAP1=2W7tnAMQEXE_N60N6OiwBOSwxHO6yJXdbCzC3=QkSaLzHg@mail.gmail.com>
 <43F6B694-4CC9-4482-A828-D4F0A329818B@stufft.io>
 <CAP1=2W6dU4OEo0uQQok+3oiWnvdNxnrZT5jPcQiNqa6QPgPqyw@mail.gmail.com>
 <CADiSq7eLzug3UoqXvtd63PF3rZyrronB1yJ6AX-MPZa2z5VVXQ@mail.gmail.com>
Message-ID: <CAP1=2W5omFBQTPxZch2uqcYDLz-hyhCDPbiihYh9pSPXwGpwCQ@mail.gmail.com>

On Sun, 16 Apr 2017 at 21:24 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 17 April 2017 at 04:49, Brett Cannon <brett at python.org> wrote:
> > Appending to the body of the pull request is an interesting idea. I'm not
> > sure what permissions the bot would need to have to be able to do that,
> > though (write access with public_repo?).
>
> If you can figure out how to make it work, I think that plus a status
> check would be the best option.
>

I poked around on a repo where I have write access but not admin access and
it looks like at least through the web UI I can edit the PR body. So I
*think* there's a good chance it's possible to append to the PR body
something like:

<!-- bedevere/issue-number -->
[bpo-NNN](https://bugs.python.org/issueNNNN) is the associated issue with
this pull request (and where all non-code discussions should occur,
including discussing overall design approaches to solving the issue).
<!-- END bedevere/issue-number -->

Then the bot can look for the comments in the raw Markdown to know where
the link is already present.


>
> Failing that, I think a comment would be a bit spammy, unless Bedevere
> was smart enough not to comment on backport PRs.
>

It's possible if people add the appropriate cherry-pick label to the PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170417/8740d51e/attachment.html>