[Stackless] merging changes

Kristján Valur Jónsson kristjan at ccpgames.com
Fri Nov 1 15:24:48 CET 2013


Okay, I have merged all of those in.

One thing I noticed is that Anselm has been very tidy in keeping the stackless/changelog.txt up to date.
This is something I have not been doing :)

I have made a bunch of changes to 2.7 and need to update the changelog accordingly.

The changelog then needs to be migrated to 3.2 and 3.3.

However, it seems a bit awkward to be keeping the same minor release cadence as cpython.
Surely we can adopt a micro version number, or something,

e.g. 2.7.5.1  is cpython 2.7.5 with stackless version 1

Does this make sense?

Maybe that is all moot since I don't know if we are making proper regular stackless releases anymore :(

K

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Anselm Kruis
> Sent: 28. október 2013 20:30
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] merging changes
> 
> Hi,
> 
> Am 26.10.2013 12:51, schrieb Kristján Valur Jónsson:
> > As long as the features have unittests (stackless/unittests/...) then there is
> no special testing infrastructure needed.
> That's perfectly valid as long as everything works as expected. But
> sometimes things break in a subtle way and you need to closely investigate
> the problem. For instance, a valid 2.7 test case could be invalid for 3.x.
> Unfortunately I didn't use python 3.x yet and therefore I would probably
> need a lot of time which I don't have.
> 
> > Everything we add should be unit-testable if possible.  I have tried
> > to make it a habit to add these tests for all that I do
> and my 3.x testing when porting features consists of running the test suite.
> +1
> 
> As promised, here is a list of changes to be ported to 3.x.
> 
> http://www.stackless.com/ticket/24
> http://hg.python.org/stackless/rev/2612a56e0082
> 
> http://www.stackless.com/ticket/22
> http://www.stackless.com/changeset/00459789dc70
> Perhaps we should refactor and simplify the f_execute logic at the end of
> PyEval_EvalFrame_value. I didn't look into any 3.x version, but in
> 2.7 it is really hard to read.
> 
> http://www.stackless.com/ticket/20
> http://www.stackless.com/changeset/91ff56a0cd3c
> At least the test case.
> 
> http://www.stackless.com/ticket/18
> http://www.stackless.com/changeset/7d4f4b6fdf06
> http://www.stackless.com/changeset/7513dc7259b3
> 
> http://www.stackless.com/ticket/15
> http://www.stackless.com/changeset/0f46dcc0abf0
> 
> http://www.stackless.com/ticket/14
> http://www.stackless.com/changeset/53f0e5446729
> 
> http://www.stackless.com/ticket/12
> http://www.stackless.com/changeset/56982efdeb04
> 
> Regards
>    Anselm
> 
> 
> > K
> >
> > -----Original Message-----
> > From: Anselm Kruis [mailto:a.kruis at science-computing.de]
> > Sent: 25. október 2013 19:09
> > To: Kristján Valur Jónsson
> > Cc: stackless at stackless.com
> > Subject: Re: [Stackless] merging changes
> >
> > Hi Kristján,
> >
> > here at s+c we still use Python 2.7 almost exclusively. Therefore I have no
> real Python3 test infrastructure. I would appreciate it very much, if you could
> merge my changes into 3.*. I already added comments about this to the
> stackless issues, but I'll summarise it for you later this weekend.
> >
> > best regards
> >     Anselm
> >
> >
> > Am 25.10.2013 16:59, schrieb Kristján Valur Jónsson:
> >> Hello there.
> >> I notice that there have been a number of changes to 2.7 in the last
> months by other people than me.
> >> Anselm and Christian mostly.
> >>
> >> We should be careful to keep merging these changes to the 3.2 and 3.2
> branches.
> >> Merging from 2.7 to 3.2 is best done with the "graft" extension, I always
> do this for individual changes.
> >> Then, a branch merge from 3.2 to 3.3. can be performed, bringing the
> changes all the way.
> >>
> >> Anselm and Christian, do you want to do this?  Alternatively, if you
> identify the revisions that need merging, I can do it for you, n.p.
> >>
> >>
> >> K
> >>
> >>
> >>
> >> Hello there.
> >>
> >> I notice that there have been a number of changes to 2.7 in the last
> >> months by other people than me.
> >>
> >> Anselm and Christian mostly.
> >>
> >> We should be careful to keep merging these changes to the 3.2 and 3.2
> >> branches.
> >>
> >> Merging from 2.7 to 3.2 is best done with the "graft" extension, I
> >> always do this for individual changes.
> >>
> >> Then, a branch merge from 3.2 to 3.3. can be performed, bringing the
> >> changes all the way.
> >>
> >> Anselm and Christian, do you want to do this?  Alternatively, if you
> >> identify the revisions that need merging, I can do it for you, n.p.
> >>
> >> K
> >>
> >>
> >>
> >> _______________________________________________
> >> Stackless mailing list
> >> Stackless at stackless.com
> >> http://www.stackless.com/mailman/listinfo/stackless
> >>
> >
> 
> --
>   Dipl. Phys. Anselm Kruis                       science + computing ag
>   Senior Solution Architect                      Ingolstädter Str. 22
>   email A.Kruis at science-computing.de             80807 München, Germany
>   phone +49 89 356386 874  fax 737               www.science-computing.de
> --
> Vorstandsvorsitzender/Chairman of the board of management:
> Gerd-Lothar Leonhart
> Vorstand/Board of Management:
> Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech
> Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board:
> Philippe Miltin
> Sitz/Registered Office: Tuebingen
> Registergericht/Registration Court: Stuttgart Registernummer/Commercial
> Register No.: HRB 382196
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless





More information about the Stackless mailing list