Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
Op zo 20 okt. 2019 03:51 schreef Nathan Hartman : > On Sat, Oct 19, 2019 at 2:11 PM Branko Čibej wrote: > > By the principle of least surprise, I think it > > would be better to merge to trunk, create a > > new 1.13.0 release candidate > > +1 > > > and (maybe?) restart the soak. > > I support this idea even if the soak must restart or be extended. > +1. Since 1.13 contains so very little, I think it's good to be a bit flexible with our planned timing here, to get this on board. I.e. let's merge it in, cut a new rc, and restart the soak. -- Johan
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
On 20.10.2019 04:05, Daniel Shahaf wrote: > Nathan Hartman wrote on Sun, 20 Oct 2019 01:49 +00:00: >> I support this idea even if the soak must restart or be extended. > Brainstorming: How about letting the soak continue but documenting in > the release notes, release announcements, etc., that we'll be adding swig- > py3 support in a patch release? This way, swig-py2 users will know not > to upgrade from 1.12.x until after the destabilizing changes are made. The thing is that the swig-py3 branch introduces a new dependency (py3c) for Py2 bindings, not just for Py3. That's a big deal even for packagers, IMO. (Which reminds me: get-deps.sh still needs to be updated to download py3c.) > I assume the parts of the swig-py3 branch outside subversion/bindings/ > aren't destabilizing and would not be a concern to backport in a patch > release. Those are mainly test fixes, so sure. -- Brane
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
Nathan Hartman wrote on Sun, 20 Oct 2019 01:49 +00:00: > I support this idea even if the soak must restart or be extended. Brainstorming: How about letting the soak continue but documenting in the release notes, release announcements, etc., that we'll be adding swig- py3 support in a patch release? This way, swig-py2 users will know not to upgrade from 1.12.x until after the destabilizing changes are made. I assume the parts of the swig-py3 branch outside subversion/bindings/ aren't destabilizing and would not be a concern to backport in a patch release. Cheers, Daniel
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
On Sat, Oct 19, 2019 at 2:11 PM Branko Čibej wrote: > By the principle of least surprise, I think it > would be better to merge to trunk, create a > new 1.13.0 release candidate +1 > and (maybe?) restart the soak. I support this idea even if the soak must restart or be extended. Rationale: * we still get 1.13 out in time for the holidays * we get one STS release with Py3 before the next LTS release * we support Py3 before Py2 goes "out of support" -- there's no "lapse in coverage" for customers who have IT policies about that (One corporate or government customer wrote to users@ some months ago and specifically mentioned concern because of such a policy; I'd love to reply and say that Py3 is supported on time.) Bottom line: we'll be a little late in the release but in exchange we'll have one really whiz-bang compelling new feature -- that people have been asking for -- to write about in the release notes. Nathan
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
On 19.10.2019 12:06, Johan Corveleyn wrote: > On Sat, Oct 19, 2019 at 1:23 AM Daniel Shahaf wrote: >> Yasuhito FUTATSUKI wrote on Fri, Oct 18, 2019 at 23:09:19 +0900: >>> On 2019/10/16 21:12, Johan Corveleyn wrote: This makes me wonder: should that be fixed specifically on trunk, and nominated for backport to 1.13, so we can possibly claim basic support for Python 3 in our build and test processes (in at least one released version) before the end of this year? Or should we reintegrate the swig-py3 branch ASAP, and nominate *that* for backport to 1.13, so we can have Python 3 support, including swig bindings? >>> I prefer the latter, as one of users :) I want to use >>> tools/hook-scripts/mailer/mailer.py with Python 3. >> If we want this to happen, we should first of all complete the swig-py3 >> branch >> and merge it to trunk. > Yes, and I think the branch is now ready for merge to trunk. > >> What's not clear to me is what would happen afterwards. Is anyone proposing >> to >> delay 1.13.0 until swig-py3 is merged (remember that we are already more than >> halfway through the soak)? If not, how would merging swig-py3 to 1.13.x >> coexist with the premise of "no destabilizing changes in patch releases"? >> Would we have to delay merging swig-py3 to 1.13.x until January, when py2 has >> finally gone out of support? > I wouldn't postpone 1.13.0 for it. I suppose the best way is that we > propose it for backport for 1.13.1, shortly after 1.13.0 has been > released. > Also: the swig-py3 branch does not break our support for py2. With > that branch, both py2 and py3 swig-bindings can be built and run fine. But it does introduce major changes in the bindings, for Py2 as well. I'd really, really rather not drop them on unsuspecting users in a patch release. By the principle of least surprise, I think it would be better to merge to trunk, create a new 1.13.0 release candidate and (maybe?) restart the soak. >> What should we do about swig-py3 support in 1.12.x and 1.10.x, which are >> both LTS? > Only 1.10.x is LTS (and 1.9.x perhaps? But ISTR we eol'ed that). I > suppose a backport to 1.10.x would be a good idea, so we have at least > one LTS release this year that supports py3. -0, for the same reason as above. We'll have the LTS that supports Python 3 in a few months. Anyone who cares so much about Python 3 support will be able to use 1.13.0 (or .x). And of course ... EOL or not, Python 2 will be around for a while yet. >> Should we say anything about swig-py2 / swig-py3 in the release notes >> _today_, >> before 1.13.0 has been released, about our plans for 1.13.x patch releases? Given that I prefer releasing this with 1.13.0, the answer is, of course, "yes." -- Brane
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
On Sat, Oct 19, 2019 at 1:23 AM Daniel Shahaf wrote: > > Yasuhito FUTATSUKI wrote on Fri, Oct 18, 2019 at 23:09:19 +0900: > > On 2019/10/16 21:12, Johan Corveleyn wrote: > > > This makes me wonder: should that be fixed specifically on trunk, and > > > nominated for backport to 1.13, so we can possibly claim basic support > > > for Python 3 in our build and test processes (in at least one released > > > version) before the end of this year? > > > > > > Or should we reintegrate the swig-py3 branch ASAP, and nominate *that* > > > for backport to 1.13, so we can have Python 3 support, including swig > > > bindings? > > > > I prefer the latter, as one of users :) I want to use > > tools/hook-scripts/mailer/mailer.py with Python 3. > > If we want this to happen, we should first of all complete the swig-py3 branch > and merge it to trunk. Yes, and I think the branch is now ready for merge to trunk. > What's not clear to me is what would happen afterwards. Is anyone proposing > to > delay 1.13.0 until swig-py3 is merged (remember that we are already more than > halfway through the soak)? If not, how would merging swig-py3 to 1.13.x > coexist with the premise of "no destabilizing changes in patch releases"? > Would we have to delay merging swig-py3 to 1.13.x until January, when py2 has > finally gone out of support? I wouldn't postpone 1.13.0 for it. I suppose the best way is that we propose it for backport for 1.13.1, shortly after 1.13.0 has been released. Also: the swig-py3 branch does not break our support for py2. With that branch, both py2 and py3 swig-bindings can be built and run fine. > What should we do about swig-py3 support in 1.12.x and 1.10.x, which are both > LTS? Only 1.10.x is LTS (and 1.9.x perhaps? But ISTR we eol'ed that). I suppose a backport to 1.10.x would be a good idea, so we have at least one LTS release this year that supports py3. > Should we say anything about swig-py2 / swig-py3 in the release notes _today_, > before 1.13.0 has been released, about our plans for 1.13.x patch releases? I think we should mention it at least in the 1.13.0 release notes, in the known issues section, and announce our plan to address it in 1.13.1 or something like that? -- Johan
1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
Yasuhito FUTATSUKI wrote on Fri, Oct 18, 2019 at 23:09:19 +0900: > On 2019/10/16 21:12, Johan Corveleyn wrote: > > This makes me wonder: should that be fixed specifically on trunk, and > > nominated for backport to 1.13, so we can possibly claim basic support > > for Python 3 in our build and test processes (in at least one released > > version) before the end of this year? > > > > Or should we reintegrate the swig-py3 branch ASAP, and nominate *that* > > for backport to 1.13, so we can have Python 3 support, including swig > > bindings? > > I prefer the latter, as one of users :) I want to use > tools/hook-scripts/mailer/mailer.py with Python 3. If we want this to happen, we should first of all complete the swig-py3 branch and merge it to trunk. What's not clear to me is what would happen afterwards. Is anyone proposing to delay 1.13.0 until swig-py3 is merged (remember that we are already more than halfway through the soak)? If not, how would merging swig-py3 to 1.13.x coexist with the premise of "no destabilizing changes in patch releases"? Would we have to delay merging swig-py3 to 1.13.x until January, when py2 has finally gone out of support? What should we do about swig-py3 support in 1.12.x and 1.10.x, which are both LTS? Should we say anything about swig-py2 / swig-py3 in the release notes _today_, before 1.13.0 has been released, about our plans for 1.13.x patch releases?
