Testing out proposed new workflows
I have come to realize that asking for conversions of the devguide and peps repos to test with really won't give an accurate representation of how the workflows will apply to the cpython repository. Because of that I would like to see a test repo that starts from the cpython repo at some point in time that people can use to test things such as clean patch submissions, merge conflict submissions, etc. I'm not expecting Roundup integration for this nor that commits be integrated back into the repository of record. Basically I want to be able to grab a patch from Roundup and somehow apply it against a test repo to see how the workflow will work where I play both submitter and committer (e.g., a GitHub test repo where I can submit my own PRs against it that I know will fully succeed or have a merge conflict to test how things will look on both ends). Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)? If you honestly need more time I am willing to extend to November 15 (the cut-off in the retail industry to consider something in stores for Christmas, 113 days away), but I only want to do that if you honestly think the 15 extra days will make a difference. These dates will be enough for me and any other core developers who are interested to try out the test repos, give me feedback, and allow me to make a decision no later than January 1, 2016 so we can start the new year off towards getting our workflow back on track.
On 5 August 2015 at 08:26, Brett Cannon <bcannon@gmail.com> wrote:
Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)?
I'm planning to use Kallithea as my guinea-pig project for user level package management in Fedora, so this will be a good test case for carrying patches that haven't been merged back upstream yet. Since this won't need any of the integration-with-other-services aspects, October 31 should definitely be doable. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 5 August 2015 at 22:05, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 August 2015 at 08:26, Brett Cannon <bcannon@gmail.com> wrote:
Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)?
I'm planning to use Kallithea as my guinea-pig project for user level package management in Fedora, so this will be a good test case for carrying patches that haven't been merged back upstream yet.
Since this won't need any of the integration-with-other-services aspects, October 31 should definitely be doable.
After merging a docs patch forward from 3.4 to 3.5 and hence to default, I do have a related request for you or David, though: would one of you have time to review the currently proposed options and decide what we're going to do about autogenerating Misc/NEWS? The status quo is already broken for Larry's "separate repo" approach to release candidate preparation, and moving to a fully online review workflow is going to make it broken in general. I suspect a moderately unilateral "we are going to switch to generating Misc/NEWS <this way>" from one of you is about the only way we're going to get over the activation barrier. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Aug 5, 2015 at 6:22 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 August 2015 at 22:05, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 August 2015 at 08:26, Brett Cannon <bcannon@gmail.com> wrote:
Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)?
I'm planning to use Kallithea as my guinea-pig project for user level package management in Fedora, so this will be a good test case for carrying patches that haven't been merged back upstream yet.
Since this won't need any of the integration-with-other-services aspects, October 31 should definitely be doable.
Great! Just need to hear from Donald then on whether the dates work.
After merging a docs patch forward from 3.4 to 3.5 and hence to default, I do have a related request for you or David, though: would one of you have time to review the currently proposed options and decide what we're going to do about autogenerating Misc/NEWS?
The status quo is already broken for Larry's "separate repo" approach to release candidate preparation, and moving to a fully online review workflow is going to make it broken in general. I suspect a moderately unilateral "we are going to switch to generating Misc/NEWS <this way>" from one of you is about the only way we're going to get over the activation barrier.
I already assumed we were going to tweak how we did Misc/NEWS somehow, whether it was separate files for each release/branch, somehow automatically generating it from commits, etc. If David's up for hashing it out with me I'm sure we can figure some solution out.
On Wed, 05 Aug 2015 17:59:32 -0000, Brett Cannon <bcannon@gmail.com> wrote:
I already assumed we were going to tweak how we did Misc/NEWS somehow, whether it was separate files for each release/branch, somehow automatically generating it from commits, etc. If David's up for hashing it out with me I'm sure we can figure some solution out.
Yes, let's have at it and get that done. I should have at least some time for it this weekend, and emails before then if you want to start the process. --David
On 5 Aug 2015 00:35, "Brett Cannon" <bcannon@gmail.com> wrote:
Nick and Donald, do you think you can have such a test setup up and
running by October 31 (Halloween, 88 days away)? If you honestly need more time I am willing to extend to November 15 (the cut-off in the retail industry to consider something in stores for Christmas, 113 days away), but I only want to do that if you honestly think the 15 extra days will make a difference. I'm not sure where we're at with this timeline, but I wanted to raise a request from some recent distutils-sig process discussions: we have some participants that *strongly* prefer to only need accounts with PSF provided services in order to participate in PEP design discussions. (The context was using the PyPA's "interoperability PEPs" repo on GitHub as part of the detailed review process for packaging interoperability PEPs) Cheers, Nick.
participants (3)
-
Brett Cannon -
Nick Coghlan -
R. David Murray