You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2019/10/18 23:22:55 UTC
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?
Re: 1.13.x and swig-py3
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
Though it is somewhat off topic....
On 2019-10-24 18:38, Stefan Sperling wrote:
> FreeBSD ships 1.10 as part of their base system (it would make sense for
> them to stick to LTS).
Subversion in FreeBSD base system are only command line programs, which
link libsvn_* statically, and not depend on Python to build. FreeBSD also
provides Subversion as ports/pkg both of newest release and LTS, however
langage bindings are provided only for newest release.
Cheers,
--
Yasuhito FUTATSUKI <fu...@poem.co.jp>
Re: 1.13.x and swig-py3
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Oct 24, 2019 at 02:46:39AM +0000, Daniel Shahaf wrote:
> Nathan Hartman wrote on Wed, Oct 23, 2019 at 01:11:19 -0400:
> > James McCoy wrote:
> > > FWIW, since we switched to the new release model, I (in my capacity as
> > > packager for Debian) basically ignore non-LTS releases. It's easier to
> > > ignore them, since I know I only want an LTS release in Debian's
> > > release, and would rather not risk getting "stuck" with a non-LTS
> > > release when Debian freezes.
> >
> > And this is completely okay!
> >
> > I use Debian myself. Most Debian packages "lag" behind the latest and
> > greatest. The same is true of other stability-oriented OSes. When you
> > have 50,000 packages in your repositories and a whole dependency hell
> > between them (circular / diamond dependencies, anyone?), you have to
> > move forward cautiously. This is where users must decide if they favor
> > stability or new features and choose their distro accordingly. It's a
> > trade-off.
> >
> > Thank you for maintaining the Debian package. It works great!
>
> Nathan, if I understood James correctly, he's saying that he doesn't package
> non-LTS releases even for Debian unstable and Debian testing, so users of those
> flavours of Debian will only be served LTS versions of Subversion by Debian.
> That _is_ noteworthy: those two flavours of Debian normally have little lag behind
> upstream. It's only the "stable" flavour that typically (by design) has lag.
>
> The upshot of this is that users of Debian testing/unstable, which are by and
> large "low lag" distros, don't get STS releases of Subversion.
>
> James, please correct me if I'm wrong.
I do not think that this is a problem. LTS releases are the equivalent
of releases we used to publish before the release schedule was changed.
Non-LTS releases are just additional releases which give us a chance to
get more feedback and give users regular access to new features and fixes.
What matters is that some of the systems out there run our regular releases.
And indeed, it is not as if everyone was using our LTS releases only.
OpenBSD releases usually ship a very recent release of SVN, which works
well because their release cycle is also 6 months long.
FreeBSD ships 1.10 as part of their base system (it would make sense for
them to stick to LTS).
NetBSD pkgsrc ships 1.12.
Fedora seems to ship 1.10 and 1.12.
ArchLinux ships 1.12.
OpenSUSE has 1.12, 1.9, and 1.8 available via their build service (I am not
sure what shipped in their latest release).
Slackware ships 1.9 in their release and carries 1.12 in -current.
I am not going to go on with this list. I think it already shows that there
is sufficient interest in our non-LTS releases, and that downstream consumers
are making choices for their users about LTS/non-LTS SVN releases, such that
the version of SVN shipped aligns with their respective project release cycles
and stability goals. This is good.
Re: 1.13.x and swig-py3
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Wed, Oct 23, 2019 at 01:11:19 -0400:
> James McCoy wrote:
> > FWIW, since we switched to the new release model, I (in my capacity as
> > packager for Debian) basically ignore non-LTS releases. It's easier to
> > ignore them, since I know I only want an LTS release in Debian's
> > release, and would rather not risk getting "stuck" with a non-LTS
> > release when Debian freezes.
>
> And this is completely okay!
>
> I use Debian myself. Most Debian packages "lag" behind the latest and
> greatest. The same is true of other stability-oriented OSes. When you
> have 50,000 packages in your repositories and a whole dependency hell
> between them (circular / diamond dependencies, anyone?), you have to
> move forward cautiously. This is where users must decide if they favor
> stability or new features and choose their distro accordingly. It's a
> trade-off.
>
> Thank you for maintaining the Debian package. It works great!
Nathan, if I understood James correctly, he's saying that he doesn't package
non-LTS releases even for Debian unstable and Debian testing, so users of those
flavours of Debian will only be served LTS versions of Subversion by Debian.
That _is_ noteworthy: those two flavours of Debian normally have little lag behind
upstream. It's only the "stable" flavour that typically (by design) has lag.
The upshot of this is that users of Debian testing/unstable, which are by and
large "low lag" distros, don't get STS releases of Subversion.
James, please correct me if I'm wrong.
Cheers,
Daniel
Re: 1.13.x and swig-py3
Posted by Nathan Hartman <ha...@gmail.com>.
I'll respond to Mark, Julian, Stefan, and James below...
Mark Phippard wrote:
> I thought the frequent release/LTS plan was a worth a try, I just do
> not see where it is working out and yielding benefits.
I'd like to point out that I have made several proposals but was
(politely) reminded that we are in a period of stabilization. So those
items and others are on my TODO list for later.
I think we need to clarify what being in a period of stabilization
means. It better not mean forever! I assume it means that we don't want
to rock the boat (too much) until after 1.14-LTS is released. After
that, I assume we have 2 STS releases for new developments followed by
1 "stabilization" STS to iron out and polish everything for the next
LTS. But this is all a subject for another thread.
Also, very much to the point:
Julian Foad wrote:
> I would like to point out we have gained two new enthusiastic
> contributors (Nathan, Yasuhito) this year.
Yes!
We wouldn't even be having this conversation, nor would we have swig-
py3, if it were not for the beautiful work Yasuhito has been doing. We
owe Yasuhito a very big Thank You!
I'm the other new developer and I have quite a lot in the pipeline,
much of it aimed at attracting new users and developers. I'm working on
a redesign and reorganization of the website, with more big items
planned afterwards. Regarding actual Subversion code, I'm focusing on
code quality at this time. I've uncovered an edge case in the tree
conflict resolver that I'm working to pinpoint. You'll see either a fix
or at least a reproduction script soon. Julian suggested and I have
promised to bring an old issue to the list every week. Last week we
closed our first weekly old issue. This week I posted the second (SVN-
1804) and I'm working on a fix that I'll propose soon. Like timed
releases, this process of "timed issue resolution" will continue for as
long as it takes to get our issue tracker cleaned up. I believe that
having 15 year old issues in there is a psychological drag on everyone.
It will be cleaned up!!
Also, we've recently reached out to a hackathon; not sure what (if any)
will materialize from that, but it's a good first step and much more
will follow. Stay tuned!
Stefan Sperling wrote:
> I also had concerns in the beginning when Julian brought up the
> proposal of time-based releases. I didn't expect it to work.
>
> But I think what Julian has shown us is that the calendar keeps us honest
> in our commitment to actually do releases.
<snip>
> It would be interesting to learn what our new developers think about this.
> I am sure that getting their changes released is important to them.
> Time-based releases provide a certain amount of anticipation and clarity
when
> a release is supposed to happen. In the past, we used to discuss what to
> release and when, every single time, and often delayed releases for
months.
> That could put new contributors off because they might not feel like they
> have a huge standing when arguing for their changes to be released soon.
> While the results of their work are sitting on trunk which nobody is
actually
> running in production. That certainly would not motivate me, if I try to
put
> myself in their shoes.
Stefan, that is exactly what I think. I couldn't have stated it better
myself.
We *should* do time-based releases. It's really important that we do.
IIRC one of the motivations for time-based releases was the new tree
conflict resolver. It has made Subversion so much better and so much
easier to use, yet it waited, largely untested, for two years. That
should never be allowed to happen!
There are myriad reasons why the managers of any organization must keep
things on schedule.
For us, the developers: As you and others have said, it "keeps us
honest." It imposes deadlines to get things done. It prevents
procrastinating on making a release. It makes expectations clear. It
avoids endless discussions on whether to make a release or not.
For our customers, the end users, server operators, IT departments,
decision makers, and packagers: It gives a tangible schedule to aid in
planning.
It also shows current and potential customers that Subversion is alive,
being maintained, and that future releases are scheduled. I can't
stress the importance of this point enough, especially given that we're
in the version control business, where the key is long-term safekeeping
of data and its history, and longevity of the version control software
itself.
I'd like to thank Julian for being diligent about driving the time-
based releases and for standing firm that they should happen on
schedule!
James McCoy wrote:
> FWIW, since we switched to the new release model, I (in my capacity as
> packager for Debian) basically ignore non-LTS releases. It's easier to
> ignore them, since I know I only want an LTS release in Debian's
> release, and would rather not risk getting "stuck" with a non-LTS
> release when Debian freezes.
And this is completely okay!
I use Debian myself. Most Debian packages "lag" behind the latest and
greatest. The same is true of other stability-oriented OSes. When you
have 50,000 packages in your repositories and a whole dependency hell
between them (circular / diamond dependencies, anyone?), you have to
move forward cautiously. This is where users must decide if they favor
stability or new features and choose their distro accordingly. It's a
trade-off.
Thank you for maintaining the Debian package. It works great!
And thanks to everyone here, for all that you do.
Nathan
Re: 1.13.x and swig-py3
Posted by James McCoy <ja...@jamessan.com>.
On Mon, Oct 21, 2019 at 01:35:45PM +0200, Branko Čibej wrote:
> On 21.10.2019 13:16, Julian Foad wrote:
> > Johan Corveleyn wrote:
> >> Nathan Hartman wrote:
> >> 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.
> >
> > Dear all, with respect,
> >
> > I would love to see the Py3 support released ASAP.
> >
> > But, have we not learned from our past mistakes? We have prepared a
> > regular release that is right now looking to be ready to deploy next
> > week, on time. If we postpone and destabilize it now [1], this would
> > make mockery of "regular" releases. I would love to trust that
> > merging the branch will go smoothly with no follow-up required and no
> > extra time taken, but history has taught us that it is foolish to
> > assume so.
> >
> > Surely the right approach is to release what we have got (the
> > currently soaking 1.13), then release the new one as soon as we can
> > get it ready. It sounds like it's not suitable for a patch release, so
> > we'll make it a new minor release, calling it 1.14.
>
>
> If you (or some other RM volunteer) is prepared to roll 1.14 with Python
> 3 support in, say, a month after 1.13 -- with all that implies for
> downstream packagers -- then sure.
FWIW, since we switched to the new release model, I (in my capacity as
packager for Debian) basically ignore non-LTS releases. It's easier to
ignore them, since I know I only want an LTS release in Debian's
release, and would rather not risk getting "stuck" with a non-LTS
release when Debian freezes.
The downside to this is that the non-LTS releases don't get any of the
feedback of going through the various builds/tests on Debian's
infrastructure.
I'll likely make an exception for the Python 3 support since there's a
significant push within Debian to switch over to Python 3 ASAP, and
definitely in time for the next release.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: 1.13.x and swig-py3
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Oct 22, 2019 at 10:13:04AM -0400, Mark Phippard wrote:
> I do not think the current 1.13 release is worth releasing. I think we
> should merge the Py 3 branch and release that as 1.13 once we think it is
> ready. That should essentially become the release we maintain until there
> is something new worth generating a new minor release, whenever that may be.
Since the process for 1.13 has already started, why don't we finish the
release as planned? And discuss release policy changes for 1.14, which
is happening in only 6 months from now?
That would give us plenty of time to conclude this discussion without
rushing through it. And 1.14 is supposed to be the next LTS anyway.
I could be wrong but it seems like we're having this discussion only because
new work on python 3 and the new release cycle happened to overlap, and
otherwise we would not be having it?
If getting the python 3 changes out quickly is important, could we merge
some or all python 3 fixes into 1.13.1, or are they all breaking API?
I haven't had time to actually look at the patches and this entire thread,
so please excuse me if this has already been discussed and ruled out.
I also agree with Julian that it will take time to see results from our
release policy changes. We are still at the stage where we are learning
a new process and can fine-tune it based on new experience and insights.
As long as Julian is willing to keep up his role as a time-based release
manager, I believe we should keep trying. If we reach a point where there
is nothing at all to release after 6 months, we can still reconsider.
It would be interesting to learn what our new developers think about this.
I am sure that getting their changes released is important to them.
Time-based releases provide a certain amount of anticipation and clarity when
a release is supposed to happen. In the past, we used to discuss what to
release and when, every single time, and often delayed releases for months.
That could put new contributors off because they might not feel like they
have a huge standing when arguing for their changes to be released soon.
While the results of their work are sitting on trunk which nobody is actually
running in production. That certainly would not motivate me, if I try to put
myself in their shoes.
Re: 1.13.x and swig-py3
Posted by Mark Phippard <ma...@gmail.com>.
Julian's email reminded me I planned to reply to this one.
On Mon, Oct 21, 2019 at 10:59 AM Stefan Sperling <st...@elego.de> wrote:
> On Mon, Oct 21, 2019 at 10:25:01AM -0400, Mark Phippard wrote:
> > Yes. Go back to having new releases when there is enough interesting
> > content to justify the release. We can lower the bar from the old days.
> > There does not need to always be a big ticket feature or two driving the
> > release, but if there is nothing worthy of a release we should not do one
> > just because the calendar says so.
>
> I also had concerns in the beginning when Julian brought up the
> proposal of time-based releases. I didn't expect it to work.
>
> But I think what Julian has shown us is that the calendar keeps us honest
> in our commitment to actually do releases. If Julian hadn't been driving
> this, I believe we would be in a situation where fixes would accumulate
> on trunk and not be released at all, because a general lack of activity
> makes doing releases look like a lot of work unless we're used to doing
> them regularly and the process is streamlined accordingly.
>
> I have experience with time-based releases in another community (OpenBSD).
> Releases happen every 6 months, like clock work. There's not much worry
> about fixes and features missing the boat, because the next boat will be
> prepared and ready soon enough. Avoiding the introduction of regressions
> in new releases is a much bigger concern there, everything else can wait
> when in doubt.
>
> I think this would also work well for Subversion, but we have to adopt a
> mind set that makes this work.
>
I do not agree with this last statement (for the most part). Time-based
releases are great. I wish we had pushed for this back when 1.4 landed.
The difference is that OpenBSD and all of the other projects that follow
this are active. We are not. I do not think this is about mindset, it is
just facing the reality that there are not many changes happening. If
OpenBSD only landed 2 bugfixes in a 6-month release cycle and the previous
two releases were also pretty sparse, they might be having the same
conversations.
You raise a fair point that the clock does force some stuff. I am not sure
the Python 3 work would have seen the same uptick if a release was not
happening to stir things up again. I do not have any real objections if we
want to continue to use time based releases and enough people are willing
to put in the work to make that happen. I just do not think it is working
and we ought to consider a new approach.
I do not think the current 1.13 release is worth releasing. I think we
should merge the Py 3 branch and release that as 1.13 once we think it is
ready. That should essentially become the release we maintain until there
is something new worth generating a new minor release, whenever that may be.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.13.x and swig-py3
Posted by Julian Foad <ju...@apache.org>.
Stefan Sperling wrote:
> [...] it sounds like we
> are very close to having full support for Python 3 on trunk already or
> will have it soon. Which means it will be ready in time for 1.14 LTS as
> originally scheduled. Is that really not enough?
Stefan, thank you for articulating so clearly, especially about Python2
EOL not being the end of the world and about the value of adhering to
regular releases.
Further thoughts...
Mark wrote,
> I thought the frequent release/LTS plan was a worth a try, I
> just do not see where it is working out and yielding benefits.
> Our activity and contributions continues to go down, not up.
> The releases are underwhelming.
It's true that 1.13 is "essentially empty" in terms of new features.
However, after making changes aimed at improving participation, it takes
time to see results. I would like to point out we have gained two new
enthusiastic contributors (Nathan, Yasuhito) this year.
Prompted by Nathan's "wacky idea": When the time comes for a regular
release, if there are no changes that require a new minor version, then
it makes sense we should just issue a patch release and not bump the
minor version number.
I compared {1.12.x,1.13.x}/subversion/include/ and saw one public API
change: the new svn_fs_ioctl() and its related declarations. That means
we do need a new minor release. On another occasion, if we were to
review sooner and find a situation like that, we might decide to remove
that public change (if that's an option), on the principle that we
should prefer a patch release. It is too late to consider changing it
for this release, but we should start looking out for that situation
arising in future, if we decide that's a good variant of the release
process.
While I object to postponing the current release, I am very open to
agreeing a wide range of changes to our release strategy for the next
releases. I agree with Mark's point that the current release strategy
is not right for the project and I think we should try to find a better
approach. That needs discussion in a separate thread.
- Julian
Re: 1.13.x and swig-py3
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 21, 2019 at 10:25:01AM -0400, Mark Phippard wrote:
> Yes. Go back to having new releases when there is enough interesting
> content to justify the release. We can lower the bar from the old days.
> There does not need to always be a big ticket feature or two driving the
> release, but if there is nothing worthy of a release we should not do one
> just because the calendar says so.
I also had concerns in the beginning when Julian brought up the
proposal of time-based releases. I didn't expect it to work.
But I think what Julian has shown us is that the calendar keeps us honest
in our commitment to actually do releases. If Julian hadn't been driving
this, I believe we would be in a situation where fixes would accumulate
on trunk and not be released at all, because a general lack of activity
makes doing releases look like a lot of work unless we're used to doing
them regularly and the process is streamlined accordingly.
I have experience with time-based releases in another community (OpenBSD).
Releases happen every 6 months, like clock work. There's not much worry
about fixes and features missing the boat, because the next boat will be
prepared and ready soon enough. Avoiding the introduction of regressions
in new releases is a much bigger concern there, everything else can wait
when in doubt.
I think this would also work well for Subversion, but we have to adopt a
mind set that makes this work.
In my opinion the world will not end for Subversion when Python 2 falls
out of support, even if no current release of SVN fully supports Python 3.
This is because our userbase has been slowing down with us. For the most
part, Subversion is not run on the latest version of Linux of the day.
It is run on server operating systems like Red Hat and Windows 20xx Server
which will still have Python 2 around. Our new LTS release scheme is a
good fit for this.
Most SVN clients are TortoiseSVN on corporate desktops. The Linux client
install base has moved on to Git/Hg. People being hired as software
developers on Linux today have usually never worked with SVN and won't
be expected to.
I have not followed these Python 3 patches closely but it sounds like we
are very close to having full support for Python 3 on trunk already or
will have it soon. Which means it will be ready in time for 1.14 LTS as
originally scheduled. Is that really not enough?
Re: 1.13.x and swig-py3
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Oct 21, 2019 at 8:29 AM Julian Foad <ju...@apache.org> wrote:
> Mark Phippard wrote:
> > I think it is just another example that "regular" releases are not
> appropriate for this project at this stage of its life with a lack of
> regular activity.
> [...]
> > Also, as brane already pointed out, this would also be making a mockery
> of regular releases.
>
> Mark, I do understand that for your case, each minor release is a
> problem. So far, we haven't been able to understand and resolve how we
> could alleviate that, other than by making fewer or no minor releases.
> In the mean time, making an extra one would be sore.
>
FWIW, I am trying to remove that hat for this discussion and am just
speaking with my PMC hat on. Obviously my opinions may be colored by the
release pain I feel, but I am trying not to factor that in.
I thought the frequent release/LTS plan was a worth a try, I just do not
see where it is working out and yielding benefits. Our activity and
contributions continues to go down, not up. The releases are underwhelming.
The release notes for 1.13 are essentially empty. You note there are 2
important fixes.
We actually have something highly relevant now with the Python 3 support
and due to unfortunate timing our release policy is getting in the way.
> Given that you're about the only downstream maintainer who discusses the
> issues here, I take that seriously.
>
> So, that takes us back to
>
> 1.) Proposing we stop or change the way we do minor releases, and do
> something different?
>
Yes. Go back to having new releases when there is enough interesting
content to justify the release. We can lower the bar from the old days.
There does not need to always be a big ticket feature or two driving the
release, but if there is nothing worthy of a release we should not do one
just because the calendar says so. Important fixes should be backported to
supported releases and we can go back to issuing bug fix releases when
needed. I would backport these important fixes to 1.10 and 1.12 and do new
fix releases and then release 1.13 with the Python 3 changes when we think
it is ready.
Moving forward we could continue to backport fixes and do new 1.13 releases
and do a 1.14 only when there was enough interest in doing so.
I do not recall what these two fixes are, but putting them in a 1.13
release is kind of hiding them from our maintainers. I will not pretend to
be highly fluent in Red Hat policies, as an example, but I know they are
good at backporting security fixes. They seem to be including our current
LTS release in 1.10. If we backported these fixes to our 1.10 then it
seems a lot more likely someone at Red Hat might see and consider including
these fixes in their version. By just having them in our 1.13 release it
seems a lot less likely they would see them. I would assume that is true
for other maintainers.
Anyway, rolling releases make more sense when there is more activity. Even
if we did not have a big ticket feature you could justify a release just
based on the cumulative amount of activity. I do not think this is the
case for our project where things have slowed to a crawl for the most part.
> Julian Foad wrote:
> >> Surely the right approach is to release what we have got [...], then
> >> [...] a new minor release, calling it 1.14.
> >
> > Would this be the LTS release it is supposed to be?
>
> Do you mean, "Would this new '1.14' be an LTS release?" The answer to
> that is no. It would be neither LTS nor regular. The next LTS will be
> released next April; we previously assumed it would be numbered 1.14-LTS
> but if we do things this way then it would probably be numbered 1.15-LTS
> instead.
>
Yeah, I was basically just referencing our past "declarations" that 1.14
would be an LTS release.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.13.x and swig-py3
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Oct 21, 2019 at 8:29 AM Julian Foad <ju...@apache.org> wrote:
> Mark Phippard wrote:
> > Also, as brane already pointed out, this would also be making a mockery
> of regular releases.
>
I'll throw this wacky idea out there...
(With endless respect for everyone here, always.)
Suppose we backport the contents of 1.13-rc1 to 1.12.3 such that 1.12.3
is identical to 1.13-rc1 except for version numbers. Afterwards, merge
swig-py3 to trunk, backport it to 1.13, issue 1.13-rc2, start a 4-week
soak.
This (wacky idea) is meant to accomplish several things:
1. We can get the important changes Julian mentioned released, as
1.12.3.
2. If I understand HACKING correctly, we can release 1.12.3 ON TIME --
meaning around the same time that we would have released 1.13, since it
would be a patch release that doesn't require a 4-week soak. Please
correct me if I'm mistaken on this point. And, for all practical
purposes, we did a soak.
3. Packagers who have worked on 1.13-rc1 won't lose the work they've
done -- PROVIDED that we communicate well that we decided to renumber
it as a patch release and that they'll find all contents identical
except for version numbers. I hope Mark will tell us if this would be
an acceptable compromise?
4. We wouldn't "make a mockery" of regular releases, since 1.12.3 would
occur at the regular time, only with a different version number than we
previously thought. Some might balk at that different version number
but I think that's a much better scenario than 1.14 suddenly not being
the next LTS release, since we've been communicating that it would be
LTS for quite some time and it suddenly not being LTS would confuse a
lot of people. No one will be confused by a 1.12.3 that fixes bugs.
5. We can test the heck out of 1.13 with swig-py3 before rolling 1.13-
rc2. Even if we find blocking breakage, we have time to restart the
soak and still get it out there before Python 2 goes EOL.
Justification for all this:
While we have a release schedule (and YES, I do think we should stick
to it!), Python 2 going EOL is an exceptional circumstance; and so, if
this event causes our release schedule to be a bit different, I don't
see that as a negative; rather, I see it as being responsive to a
pretty significant change that is coming and to users who have written
to us with questions and concerns about this change.
Now, like I said:
* I say all of this with endless respect for everyone.
* I'm throwing it out there as a wacky idea.
Nathan
Re: 1.13.x and swig-py3
Posted by Julian Foad <ju...@apache.org>.
Mark Phippard wrote:
> I think it is just another example that "regular" releases are not appropriate for this project at this stage of its life with a lack of regular activity.
[...]
> Also, as brane already pointed out, this would also be making a mockery of regular releases.
Mark, I do understand that for your case, each minor release is a
problem. So far, we haven't been able to understand and resolve how we
could alleviate that, other than by making fewer or no minor releases.
In the mean time, making an extra one would be sore.
Given that you're about the only downstream maintainer who discusses the
issues here, I take that seriously.
So, that takes us back to
1.) Proposing we stop or change the way we do minor releases, and do
something different?
2.) Maybe not insert an extra release. Instead,
2a.) postpone and change the release we've already prepared?; or
2b.) get the work ready for the next LTS instead?
What do you think we should do?
> Julian Foad wrote:
>> Surely the right approach is to release what we have got [...], then
>> [...] a new minor release, calling it 1.14.
>
> Would this be the LTS release it is supposed to be?
Do you mean, "Would this new '1.14' be an LTS release?" The answer to
that is no. It would be neither LTS nor regular. The next LTS will be
released next April; we previously assumed it would be numbered 1.14-LTS
but if we do things this way then it would probably be numbered 1.15-LTS
instead.
- Julian
Re: 1.13.x and swig-py3
Posted by Mark Phippard <ma...@gmail.com>.
> On Oct 21, 2019, at 7:16 AM, Julian Foad <ju...@apache.org> wrote:
>
> Johan Corveleyn wrote:
>> Nathan Hartman wrote:
>> 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.
>
> Dear all, with respect,
>
> I would love to see the Py3 support released ASAP.
>
> But, have we not learned from our past mistakes? We have prepared a regular release that is right now looking to be ready to deploy next week, on time. If we postpone and destabilize it now [1], this would make mockery of "regular" releases. I would love to trust that merging the branch will go smoothly with no follow-up required and no extra time taken, but history has taught us that it is foolish to assume so.
I think it is just another example that "regular" releases are not appropriate for this project at this stage of its life with a lack of regular activity.
> Surely the right approach is to release what we have got (the currently soaking 1.13), then release the new one as soon as we can get it ready. It sounds like it's not suitable for a patch release, so we'll make it a new minor release, calling it 1.14.
Would this be the LTS release it is supposed to be? Also, as brane already pointed out, this would also be making a mockery of regular releases.
Mark
Re: 1.13.x and swig-py3
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Oct 21, 2019 at 1:35 PM Branko Čibej <br...@apache.org> wrote:
> On 21.10.2019 13:16, Julian Foad wrote:
...
> > Surely the right approach is to release what we have got (the
> > currently soaking 1.13), then release the new one as soon as we can
> > get it ready. It sounds like it's not suitable for a patch release, so
> > we'll make it a new minor release, calling it 1.14.
>
>
> If you (or some other RM volunteer) is prepared to roll 1.14 with Python
> 3 support in, say, a month after 1.13 -- with all that implies for
> downstream packagers -- then sure.
I had the same thought. Creating more releases implies a lot of work
for downstream.
I'd say: if we don't want to postpone 1.13 for py3 (and we can't
backport it to a patch release), then we should indeed fix it for
1.14, but not make an extra release out of it. It will simply be part
of 1.14 LTS, to be released somewhere around April 2020.
Now, can someone please find a release blocking bug in 1.13, so we
have a valid reason for restarting the soak? ;-)
Seriously: we always have the option to retract / re-cut / ... 1.13 as
long as it has not been released. The projected release date is just
that, a _projected_ release date, which we aim for. If there is a
serious reason we can postpone the release ... (I understand that this
may not be a "serious reason" ... but downstreamers anyway have to
account for the possibility that an RC is thrown away even at the last
minute).
--
Johan
Re: 1.13.x and swig-py3
Posted by Branko Čibej <br...@apache.org>.
On 21.10.2019 13:16, Julian Foad wrote:
> Johan Corveleyn wrote:
>> Nathan Hartman wrote:
>> 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.
>
> Dear all, with respect,
>
> I would love to see the Py3 support released ASAP.
>
> But, have we not learned from our past mistakes? We have prepared a
> regular release that is right now looking to be ready to deploy next
> week, on time. If we postpone and destabilize it now [1], this would
> make mockery of "regular" releases. I would love to trust that
> merging the branch will go smoothly with no follow-up required and no
> extra time taken, but history has taught us that it is foolish to
> assume so.
>
> Surely the right approach is to release what we have got (the
> currently soaking 1.13), then release the new one as soon as we can
> get it ready. It sounds like it's not suitable for a patch release, so
> we'll make it a new minor release, calling it 1.14.
If you (or some other RM volunteer) is prepared to roll 1.14 with Python
3 support in, say, a month after 1.13 -- with all that implies for
downstream packagers -- then sure.
> Nothing says we shouldn't release an extra minor release, or that we
> shouldn't make two minor releases close together.
Well, other than that it is also, strictly speaking, a "mockery of
regular releases." :)
-- Brane
Re: 1.13.x and swig-py3
Posted by Julian Foad <ju...@apache.org>.
Johan Corveleyn wrote:
> Nathan Hartman wrote:
> 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.
Dear all, with respect,
I would love to see the Py3 support released ASAP.
But, have we not learned from our past mistakes? We have prepared a
regular release that is right now looking to be ready to deploy next
week, on time. If we postpone and destabilize it now [1], this would
make mockery of "regular" releases. I would love to trust that merging
the branch will go smoothly with no follow-up required and no extra time
taken, but history has taught us that it is foolish to assume so.
Surely the right approach is to release what we have got (the currently
soaking 1.13), then release the new one as soon as we can get it ready.
It sounds like it's not suitable for a patch release, so we'll make it a
new minor release, calling it 1.14.
Nothing says we shouldn't release an extra minor release, or that we
shouldn't make two minor releases close together.
Sure, there are no major developments in 1.13, but there are important
fixes [2]. And sure, 1.14 was previously listed as expected to be the
next LTS, and now it won't be. And people will need to choose whether
to upgrade to both or just one of them. And we will have to adjust our
terminology and docs a little as we will be calling it neither "regular"
nor "LTS". All small things to sort out. No big deal.
Then we will achieve everything we wanted. The regular releases remain
regular. The new stuff gets released ASAP, and before the next LTS release.
The existing 1.13 release has value in itself. In the role of release
manager, I plan to go ahead with the 1.13 release, and I would urge you
to support this by helping provide the final tests and signatures. Then
I will be willing to roll another release, including all the web site
updates etc, as soon as we can get it ready.
Can we do it that way, please?
- Julian
[1] Yes, from a release manager's POV, this is destabilizing, no matter
how much it has been tested already.
[2] There are important fixes in 1.13 that, if 1.13 were not to be
available, should otherwise be backported and released in 1.12. We are
not releasing them in a 1.12 patch because 1.13 is "known" to be coming
soon.
Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re:
PMCs: any Hackathon requests? (deadline 11 October)))
Posted by Johan Corveleyn <jc...@gmail.com>.
Op zo 20 okt. 2019 03:51 schreef Nathan Hartman <ha...@gmail.com>:
> On Sat, Oct 19, 2019 at 2:11 PM Branko Čibej <br...@apache.org> 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)))
Posted by Branko Čibej <br...@apache.org>.
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)))
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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)))
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Oct 19, 2019 at 2:11 PM Branko Čibej <br...@apache.org> 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)))
Posted by Branko Čibej <br...@apache.org>.
On 19.10.2019 12:06, Johan Corveleyn wrote:
> On Sat, Oct 19, 2019 at 1:23 AM Daniel Shahaf <d....@daniel.shahaf.name> 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)))
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Oct 19, 2019 at 1:23 AM Daniel Shahaf <d....@daniel.shahaf.name> 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