Hi all, It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work. Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up). Cheers, Ralf
Hi Ralf, This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn. Is this a task for admins only? Is there a way I can contribute? Cheers, Abraham. 2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Abraham, Andreas, Thanks for your interest to both of you! The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to "this release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it) Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content And what's always a team effort: merge as many PRs as possible before the release split. I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:) Cheers, Ralf P.S. I shouldn't forget to mention that for a long time Matthew Brett has been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing pre-releases with MSVC on Windows and resolving issues that are invariable found on that platform. I definitely consider them part of the "release team" (not that we have ever used that name before). On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Ralf, thanks for the clarification!
However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further
I'm not working on Windows, so cannot help there.
- tackle some of the issues that need to be resolved before the alpha / beta / final release
How is the process to decide which issues are these? Currently, there's 11 "prio-high" issues, and 284 "defect" issues.
- PRs to complete the release notes and contributor name mapping - a PR to the scipy.org <http://scipy.org> repo to put the release in the News section
Sure, that's easy.
- improve documentation of the release process itself (the less you know to start with, the better you can document it)
I think this email and your other mail from today are already good starters. What's needed is a central location where volunteers can be pointed to. I can keep this in mind and come up with some ideas.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
I'd be happy being part of the team. -- Andreas.
On Mon, Apr 6, 2015 at 11:27 AM, Andreas Hilboll <lists@hilboll.de> wrote:
Hi Ralf,
thanks for the clarification!
However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further
I'm not working on Windows, so cannot help there.
- tackle some of the issues that need to be resolved before the alpha / beta / final release
How is the process to decide which issues are these? Currently, there's 11 "prio-high" issues, and 284 "defect" issues.
We use the Github Milestones mechanism: https://github.com/scipy/scipy/milestones/0.16.0 Everything that's a blocker or that someone wants to do something about before branching (for enhancements) or the first beta/rc (issues) should simply be added to the 0.16.0 milestone.
- PRs to complete the release notes and contributor name mapping - a PR to the scipy.org <http://scipy.org> repo to put the release in the News section
Sure, that's easy.
I sent a PR to update release notes just now. Checking and updating the author name mapping (``python tools/authors.py v0.15.0..master``) would be useful to do sometime in the next two weeks though, if you have time.
- improve documentation of the release process itself (the less you know
to start with, the better you can document it)
I think this email and your other mail from today are already good starters. What's needed is a central location where volunteers can be pointed to. I can keep this in mind and come up with some ideas.
Indeed. Our developer docs are a bit scattered, I plan to reorganize them a bit in the near future. I'll ping you and Abraham for feedback and suggestions once I have the initial structure.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
I'd be happy being part of the team.
Great! Ralf
I sent a PR to update release notes just now. Checking and updating the author name mapping (``python tools/authors.py v0.15.0..master``) would be useful to do sometime in the next two weeks though, if you have time.
If I understand you correctly, the name mappings in the file tools/authors.py must be updated. What's the policy on name inclusion? Possible solutions: - approach all new contributors individually with which name they want to be mentioned - take the full name as on Github - take the Github username - ...? -- Andreas.
On Sun, Apr 26, 2015 at 6:43 PM, Andreas Hilboll <lists@hilboll.de> wrote:
I sent a PR to update release notes just now. Checking and updating the author name mapping (``python tools/authors.py v0.15.0..master``) would be useful to do sometime in the next two weeks though, if you have time.
If I understand you correctly, the name mappings in the file tools/authors.py must be updated.
What's the policy on name inclusion? Possible solutions:
- approach all new contributors individually with which name they want to be mentioned
- take the full name as on Github
- take the Github username
- ...?
Good question. We want the full name in the release notes. Many people have their full name up on Github, but the name wasn't set correctly in the commit. In those cases I normally copy the name from Github and be done. Same if there's a full name in the email. If there's only a Github handle and/or an email address with a handle, then I ask the contributor explicitly if it's OK to add the name to the release notes. Ralf
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Abraham, Andreas,
Thanks for your interest to both of you!
The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to "this release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content
And what's always a team effort: merge as many PRs as possible before the release split.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
Okay, I'll volunteer to be the release manager for this release. Here's a proposal for the release schedule: - branching 0.16.x: 10 May - beta 1: 12 May - release candidate 1: 24 May - release candidate 2: 31 May (if needed) - final release: 7 June There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here. Cheers, Ralf
Cheers, Ralf
P.S. I shouldn't forget to mention that for a long time Matthew Brett has been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing pre-releases with MSVC on Windows and resolving issues that are invariable found on that platform. I definitely consider them part of the "release team" (not that we have ever used that name before).
On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Apr 26, 2015, at 10:22 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
One PR I'd really like to see go in is: - 4675: Fix lsim (in scipy.signal) Cheers, Clancy
On Sun, Apr 26, 2015 at 5:03 PM, Clancy Rowley <clancyr@gmail.com> wrote:
On Apr 26, 2015, at 10:22 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
There aren't many serious issues at the moment, the only nontrivial one
is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in:
- 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
One PR I'd really like to see go in is:
- 4675: Fix lsim (in scipy.signal)
Agreed. I added it to the milestone. It's pretty much done, so shouldn't be an issue to get that merged soon. Ralf
On Sun, Apr 26, 2015 at 3:22 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Abraham, Andreas,
Thanks for your interest to both of you!
The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to "this release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content
And what's always a team effort: merge as many PRs as possible before the release split.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
Okay, I'll volunteer to be the release manager for this release. Here's a proposal for the release schedule:
- branching 0.16.x: 10 May - beta 1: 12 May - release candidate 1: 24 May - release candidate 2: 31 May (if needed) - final release: 7 June
There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
permutation t-tests, https://github.com/scipy/scipy/pull/4440, look nearly ready (from a distance at least) A nice-to-have, not a release blocker for sure. Evgeni
Cheers, Ralf
Cheers, Ralf
P.S. I shouldn't forget to mention that for a long time Matthew Brett has been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing pre-releases with MSVC on Windows and resolving issues that are invariable found on that platform. I definitely consider them part of the "release team" (not that we have ever used that name before).
On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Apr 28, 2015 at 12:01 AM, Evgeni Burovski < evgeny.burovskiy@gmail.com> wrote:
On Sun, Apr 26, 2015 at 3:22 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com>
Hi Abraham, Andreas,
Thanks for your interest to both of you!
The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to
"this
release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content
And what's always a team effort: merge as many PRs as possible before
release split.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
Okay, I'll volunteer to be the release manager for this release. Here's a proposal for the release schedule:
- branching 0.16.x: 10 May - beta 1: 12 May - release candidate 1: 24 May - release candidate 2: 31 May (if needed) - final release: 7 June
There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see
wrote: the these
go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
permutation t-tests, https://github.com/scipy/scipy/pull/4440, look nearly ready (from a distance at least) A nice-to-have, not a release blocker for sure.
Indeed, would be nice to get that in. Added to the milestone for now. Ralf
Evgeni
Cheers, Ralf
Cheers, Ralf
P.S. I shouldn't forget to mention that for a long time Matthew Brett
been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing
with MSVC on Windows and resolving issues that are invariable found on
platform. I definitely consider them part of the "release team" (not
has pre-releases that that we
have ever used that name before).
On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I
fear I
may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role
for
every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Abraham, Andreas,
Thanks for your interest to both of you!
The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to "this release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content
And what's always a team effort: merge as many PRs as possible before the release split.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
Okay, I'll volunteer to be the release manager for this release. Here's a proposal for the release schedule:
- branching 0.16.x: 10 May - beta 1: 12 May
Looks like we're in good shape for branching and the first beta release. I plan to create 0.16.x around 9pm GMT (so in about 5 hours). Anything you want to merge should be in by then. There's still one issue to sort out with the existing Windows BLAS/LAPACK binaries in numpy-vendor missing some functions, but that shouldn't hold up beta1 (it's probably fixable within two days, but worst-case it'll be a source-only beta). Cheers, Ralf
- release candidate 1: 24 May - release candidate 2: 31 May (if needed) - final release: 7 June
There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
Cheers, Ralf
Cheers, Ralf
P.S. I shouldn't forget to mention that for a long time Matthew Brett has been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing pre-releases with MSVC on Windows and resolving issues that are invariable found on that platform. I definitely consider them part of the "release team" (not that we have ever used that name before).
On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, May 10, 2015 at 6:02 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi Abraham, Andreas,
Thanks for your interest to both of you!
The release manager is the person that is responsible for a number of actions to get from "now we start planning for the next release" to "this release is done". This description should give a reasonable overview (some details may be a bit outdated): https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release - PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
Things that the release manager should do himself: - propose the release schedule (dates for alpha/beta/rc/final) - create the maintenance/0.16.x branch - tag the (pre-)releases - send the release announcement emails - upload binaries to PyPi and SourceForge - propose/make decisions on blockers and content
And what's always a team effort: merge as many PRs as possible before the release split.
I hope this gives a clear picture. A "release team" that jointly tackles the above tasks would be great. Still would like to see a core dev volunteer though:)
Okay, I'll volunteer to be the release manager for this release. Here's a proposal for the release schedule:
- branching 0.16.x: 10 May - beta 1: 12 May
Looks like we're in good shape for branching and the first beta release. I plan to create 0.16.x around 9pm GMT (so in about 5 hours). Anything you want to merge should be in by then.
maintenance/0.16.x is created, and master is at 0.17.0-dev now. Ralf
There's still one issue to sort out with the existing Windows BLAS/LAPACK binaries in numpy-vendor missing some functions, but that shouldn't hold up beta1 (it's probably fixable within two days, but worst-case it'll be a source-only beta).
Cheers, Ralf
- release candidate 1: 24 May - release candidate 2: 31 May (if needed) - final release: 7 June
There aren't many serious issues at the moment, the only nontrivial one is the QR updating issue. Here's what's marked to go in still: https://github.com/scipy/scipy/milestones/0.16.0. The above schedule gives us two weeks to merge PRs. Of the larger ones, I'd still like to see these go in: - 4682: signal.csd/coherence/welch - 4374: cKDTree rewrite
If you see an issue that you consider a blocker or a PR that really should go in, please label it with the 0.16.0 milestone or mention it here.
Cheers, Ralf
Cheers, Ralf
P.S. I shouldn't forget to mention that for a long time Matthew Brett has been building the OS X wheels and done extensive Scipy Stack testing. And that for an even longer time Christoph Gohlke has been testing pre-releases with MSVC on Windows and resolving issues that are invariable found on that platform. I definitely consider them part of the "release team" (not that we have ever used that name before).
On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant@gmail.com> wrote:
Hi Ralf,
This sounds interesting to me and I would like to contribute but I fear I may be still too new to the community to be of much help but maybe I could provide some assistance to learn.
Is this a task for admins only? Is there a way I can contribute?
Cheers, Abraham.
2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers@gmail.com>:
Hi all,
It's about time to start preparing for the 0.16.0 release. Unusually, there are zero blocking issues it looks like. A lot of PRs to merge of course, but nothing very large that still needs a lot of work.
Most important question: does anyone want to take the release manager role for this release? It would be good to start rotating this role for every minor release. This will help spread the knowledge on how to do releases and also spread the workload (it's not that much for a single release, but it adds up).
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
- branching 0.16.x: 10 May - beta 1: 12 May - release candidate 1: 24 May
Because there are still a few issues open including one blocker (the qr updating routines) and the first beta was source-only, I'd like to do a second beta tomorrow instead. That should allow some more testing to make sure that there aren't any other issues with the Windows and OS X installers. Ralf
- release candidate 2: 31 May (if needed) - final release: 7 June
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release
One thing that I could use a hand with is cleaning up the noise in the test suite. Basically, just run latest master and investigate the warnings and other printed output. In most cases what's needed is just silencing the warning. On Python 3.x there are also some ResourceWarnings that need fixing, probably by opening test files like ``with open('this_test_file', 'rb') as f:`` so they get closed automatically. The only output that doesn't need investigating (because it's not fixable) looks like: 0-th dimension must be fixed to 3 but got 15 Any takers? Cheers, Ralf
- PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
I can do it Monday or Tuesday if that works. Eric On May 9, 2015 8:01 AM, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release
One thing that I could use a hand with is cleaning up the noise in the test suite. Basically, just run latest master and investigate the warnings and other printed output. In most cases what's needed is just silencing the warning. On Python 3.x there are also some ResourceWarnings that need fixing, probably by opening test files like ``with open('this_test_file', 'rb') as f:`` so they get closed automatically.
The only output that doesn't need investigating (because it's not fixable) looks like:
0-th dimension must be fixed to 3 but got 15
Any takers?
Cheers, Ralf
- PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sat, May 9, 2015 at 5:11 PM, Eric Larson <larson.eric.d@gmail.com> wrote:
I can do it Monday or Tuesday if that works.
That works, thanks Eric. Ralf
Eric On May 9, 2015 8:01 AM, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The release manager is the person that has the final responsibility for what does and does not go into a release, what are considered blocking issues, etc. This part really has to be done by a core developer. However, there's a lot of other things that the release manager also usually takes care of which could equally well be done by one or more contributors who are not core developers. Here's a list: - build/test Windows and OS X binaries (.exe, .dmg, .whl) - automate those binary builds/tests further - tackle some of the issues that need to be resolved before the alpha / beta / final release
One thing that I could use a hand with is cleaning up the noise in the test suite. Basically, just run latest master and investigate the warnings and other printed output. In most cases what's needed is just silencing the warning. On Python 3.x there are also some ResourceWarnings that need fixing, probably by opening test files like ``with open('this_test_file', 'rb') as f:`` so they get closed automatically.
The only output that doesn't need investigating (because it's not fixable) looks like:
0-th dimension must be fixed to 3 but got 15
Any takers?
Cheers, Ralf
- PRs to complete the release notes and contributor name mapping - a PR to the scipy.org repo to put the release in the News section - improve documentation of the release process itself (the less you know to start with, the better you can document it)
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Ralf, depending on the time frame and tasks I might be able to contribute. Is there a write-up of the work involved? If not, can you outline what needs to be done and what skills are required? Cheers, Andreas.
participants (6)
-
Abraham Escalante -
Andreas Hilboll -
Clancy Rowley -
Eric Larson -
Evgeni Burovski -
Ralf Gommers