From stefan_ml at behnel.de  Fri Jul 15 04:32:44 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 15 Jul 2016 10:32:44 +0200
Subject: [Cython] Cython 0.24.1 released
Message-ID: <57889FAC.9070507@behnel.de>

Hi all!

I just pushed a bug-fix-only release for the current 0.24 series.
The update should be safe for everyone using 0.24.

https://pypi.python.org/pypi/Cython/0.24.1

Complete changelog follows below.

SHA1 sum:
a837efb73c195585ce6e27cf53e3587285ccd39f  Cython-0.24.1.tar.gz

Have fun,

Stefan


0.24.1 (2016-07-15)
===================

Bugs fixed
----------

* IPython cell magic was lacking a good way to enable Python 3 code
  semantics.  It can now be used as "%%cython -3".

* Follow a recent change in PEP 492 and CPython 3.5.1 that now requires
  the "__aiter__()" method of asynchronous iterators to be a simple
  "def" method instead of an "async def" method.
  See https://www.python.org/dev/peps/pep-0498/

* Coroutines and generators were lacking the "__module__" special
  attribute.

* C++ "std::complex" values failed to auto-convert from and to Python
  complex objects.

* Namespaced C++ types could not be used as memory view types due to
  a lack of name mangling.  Patch by Ivan Smirnov.

* Assignments between identical C++ types that were declared with
  differently typedefed template types could fail.

* Rebuilds could fail to evaluate dependency timestamps in C++ mode.
  Patch by Ian Henriksen.

* Macros defined in the "distutils" compiler option do not require
  values anymore.  Patch by Ian Henriksen.

* Minor fixes for MSVC, Cygwin and PyPy.

From jdemeyer at cage.ugent.be  Fri Jul 15 05:46:48 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 15 Jul 2016 11:46:48 +0200
Subject: [Cython] cython.org
In-Reply-To: <CADiQ+QBNRd+qbJXY=OS6u_7r9ziy1CiHw=L3Pr4ZDcJVncC4NQ@mail.gmail.com>
References: <CACLE5GBeJmehj_4-YnOQ1SbHLVob1pgsHSCEBo=WUOuqK7XX_w@mail.gmail.com>
 <CADiQ+QBNRd+qbJXY=OS6u_7r9ziy1CiHw=L3Pr4ZDcJVncC4NQ@mail.gmail.com>
Message-ID: <5788B108.40609@cage.ugent.be>

On 2016-06-06 07:43, Robert Bradshaw wrote:
> trac - UW - the big loss (not sure how old any backup is)

Has there been any attempt to restart the Cython trac? Is the data still 
there?

From matthew.brett at gmail.com  Fri Jul 15 07:22:23 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 15 Jul 2016 12:22:23 +0100
Subject: [Cython] [cython-users] Cython 0.24.1 released
In-Reply-To: <57889FAC.9070507@behnel.de>
References: <57889FAC.9070507@behnel.de>
Message-ID: <CAH6Pt5q2N-63w-cFfBkES73dPPvM0K5UTMMFHSCifjVmY-fw7g@mail.gmail.com>

Hi,

On Fri, Jul 15, 2016 at 9:32 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi all!
>
> I just pushed a bug-fix-only release for the current 0.24 series.
> The update should be safe for everyone using 0.24.
>
> https://pypi.python.org/pypi/Cython/0.24.1
>
> Complete changelog follows below.
>
> SHA1 sum:
> a837efb73c195585ce6e27cf53e3587285ccd39f  Cython-0.24.1.tar.gz

Thanks a lot for the release.

I'm just building wheels via
https://travis-ci.org/MacPython/cython-wheels - will upload soon.   It
would be good to get the wheels up before the source archive, if at
all possible, to make sure that users don't get a blip where they
don't have wheels for a while.   Building should be straightforward,
just a new commit to https://github.com/MacPython/cython-wheels with
an edit to give the new tag name.   If y'all agree that's a good idea,
what's the best way to update the release procedure?

Cheers,

Matthew

From wstein at gmail.com  Fri Jul 15 16:58:02 2016
From: wstein at gmail.com (William Stein)
Date: Fri, 15 Jul 2016 13:58:02 -0700
Subject: [Cython] cython.org
In-Reply-To: <5788B108.40609@cage.ugent.be>
References: <CACLE5GBeJmehj_4-YnOQ1SbHLVob1pgsHSCEBo=WUOuqK7XX_w@mail.gmail.com>
 <CADiQ+QBNRd+qbJXY=OS6u_7r9ziy1CiHw=L3Pr4ZDcJVncC4NQ@mail.gmail.com>
 <5788B108.40609@cage.ugent.be>
Message-ID: <CACLE5GDMRjTP6U93DtfX5Mi5-qDez50Q=+Ofr6XFKnpJ1js0ow@mail.gmail.com>

On Fri, Jul 15, 2016 at 2:46 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> On 2016-06-06 07:43, Robert Bradshaw wrote:
>>
>> trac - UW - the big loss (not sure how old any backup is)
>
>
> Has there been any attempt to restart the Cython trac? Is the data still
> there?

It's probably up now (i.e., the actual computer -- if you knew the
ip).  I transferred the cython.org domain to Robert Bradshaw month(s)
ago when things were working.

Hint to the world: Github exists.

William

>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel



-- 
William (http://wstein.org)

From robertwb at gmail.com  Fri Jul 15 21:22:16 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 15 Jul 2016 18:22:16 -0700
Subject: [Cython] cython.org
In-Reply-To: <CACLE5GDMRjTP6U93DtfX5Mi5-qDez50Q=+Ofr6XFKnpJ1js0ow@mail.gmail.com>
References: <CACLE5GBeJmehj_4-YnOQ1SbHLVob1pgsHSCEBo=WUOuqK7XX_w@mail.gmail.com>
 <CADiQ+QBNRd+qbJXY=OS6u_7r9ziy1CiHw=L3Pr4ZDcJVncC4NQ@mail.gmail.com>
 <5788B108.40609@cage.ugent.be>
 <CACLE5GDMRjTP6U93DtfX5Mi5-qDez50Q=+Ofr6XFKnpJ1js0ow@mail.gmail.com>
Message-ID: <CADiQ+QAL1irSN3suoFw6BzZVWUxW3xOVu92r6MsC1mZi720RpA@mail.gmail.com>

On Fri, Jul 15, 2016 at 1:58 PM, William Stein <wstein at gmail.com> wrote:
> On Fri, Jul 15, 2016 at 2:46 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
>> On 2016-06-06 07:43, Robert Bradshaw wrote:
>>>
>>> trac - UW - the big loss (not sure how old any backup is)
>>
>>
>> Has there been any attempt to restart the Cython trac? Is the data still
>> there?
>
> It's probably up now (i.e., the actual computer -- if you knew the
> ip).  I transferred the cython.org domain to Robert Bradshaw month(s)
> ago when things were working.

I have the data, but haven't tried starting an instance. Exactly where
we want to do is still TBD (but just yesterday I finally got
permissions to manage http://cython.readthedocs.io/en/latest/ )

I've been leaning towards migrating to github issues--been meaning to
start a thread on that.

From swapniljariwala87 at gmail.com  Fri Jul 15 08:11:22 2016
From: swapniljariwala87 at gmail.com (swapnil jariwala)
Date: Fri, 15 Jul 2016 17:41:22 +0530
Subject: [Cython] bug report
Message-ID: <CANjVt1tEGnHRdfzZj-BhyoNsXqstd2sNTk-TeoMLSA_jeo5FFQ@mail.gmail.com>

Hello all,
trac.cython.org does not open for me, I've come across an error while
trying the tutorial, I've elaborated the same in below question

http://stackoverflow.com/questions/38386722/how-to-resolve-error-error-compiling-cython-file-error

any help would be highly appreciated.

Thanks
Swapnil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160715/7a15a25d/attachment.html>

From robertwb at gmail.com  Mon Jul 18 11:56:47 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Mon, 18 Jul 2016 08:56:47 -0700
Subject: [Cython] [cython-users] Cython 0.24.1 released
In-Reply-To: <CAH6Pt5q2N-63w-cFfBkES73dPPvM0K5UTMMFHSCifjVmY-fw7g@mail.gmail.com>
References: <57889FAC.9070507@behnel.de>
 <CAH6Pt5q2N-63w-cFfBkES73dPPvM0K5UTMMFHSCifjVmY-fw7g@mail.gmail.com>
Message-ID: <CADiQ+QCa1TxC8RZGi0orBpJYBcnXJi0z7e8bs62cqAeqKK5Q0g@mail.gmail.com>

On Fri, Jul 15, 2016 at 4:22 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Fri, Jul 15, 2016 at 9:32 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Hi all!
>>
>> I just pushed a bug-fix-only release for the current 0.24 series.
>> The update should be safe for everyone using 0.24.
>>
>> https://pypi.python.org/pypi/Cython/0.24.1
>>
>> Complete changelog follows below.
>>
>> SHA1 sum:
>> a837efb73c195585ce6e27cf53e3587285ccd39f  Cython-0.24.1.tar.gz
>
> Thanks a lot for the release.
>
> I'm just building wheels via
> https://travis-ci.org/MacPython/cython-wheels - will upload soon.   It
> would be good to get the wheels up before the source archive, if at
> all possible, to make sure that users don't get a blip where they
> don't have wheels for a while.   Building should be straightforward,
> just a new commit to https://github.com/MacPython/cython-wheels with
> an edit to give the new tag name.   If y'all agree that's a good idea,
> what's the best way to update the release procedure?

Good point.

I'm not sure the best process (for wheels on all platforms)--maybe an
email before we push to pypi once we've settled on what commit to
release? (Typically we have a thread of release candidates, etc.)

From matthew.brett at gmail.com  Mon Jul 18 12:17:21 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 18 Jul 2016 17:17:21 +0100
Subject: [Cython] [cython-users] Cython 0.24.1 released
In-Reply-To: <CADiQ+QCa1TxC8RZGi0orBpJYBcnXJi0z7e8bs62cqAeqKK5Q0g@mail.gmail.com>
References: <57889FAC.9070507@behnel.de>
 <CAH6Pt5q2N-63w-cFfBkES73dPPvM0K5UTMMFHSCifjVmY-fw7g@mail.gmail.com>
 <CADiQ+QCa1TxC8RZGi0orBpJYBcnXJi0z7e8bs62cqAeqKK5Q0g@mail.gmail.com>
Message-ID: <CAH6Pt5p8D9tZAn67FQyGp8yLw0wi7JRH0f1nkiJU9BjrA9jQHw@mail.gmail.com>

Hi,

On Mon, Jul 18, 2016 at 4:56 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Fri, Jul 15, 2016 at 4:22 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> On Fri, Jul 15, 2016 at 9:32 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> Hi all!
>>>
>>> I just pushed a bug-fix-only release for the current 0.24 series.
>>> The update should be safe for everyone using 0.24.
>>>
>>> https://pypi.python.org/pypi/Cython/0.24.1
>>>
>>> Complete changelog follows below.
>>>
>>> SHA1 sum:
>>> a837efb73c195585ce6e27cf53e3587285ccd39f  Cython-0.24.1.tar.gz
>>
>> Thanks a lot for the release.
>>
>> I'm just building wheels via
>> https://travis-ci.org/MacPython/cython-wheels - will upload soon.   It
>> would be good to get the wheels up before the source archive, if at
>> all possible, to make sure that users don't get a blip where they
>> don't have wheels for a while.   Building should be straightforward,
>> just a new commit to https://github.com/MacPython/cython-wheels with
>> an edit to give the new tag name.   If y'all agree that's a good idea,
>> what's the best way to update the release procedure?
>
> Good point.
>
> I'm not sure the best process (for wheels on all platforms)--maybe an
> email before we push to pypi once we've settled on what commit to
> release? (Typically we have a thread of release candidates, etc.)

Yes, that would certainly help.

If whoever is releasing, wants to do the wheel building, the procedure is here:

https://github.com/MacPython/cython-wheels#triggering-a-build

(summary, edit appveyor and travis files to set tag, commit and push).

But, if you shoot me an email, I'm happy to do it too,

Cheers,

Matthew

From stefan_ml at behnel.de  Mon Jul 18 14:50:03 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 18 Jul 2016 20:50:03 +0200
Subject: [Cython] PEP 487 -- Simpler customisation of class creation
Message-ID: <578D24DB.4000002@behnel.de>

Hi all!

Here's a nice PEP that we should implement in Cython. It has been accepted
for inclusion in Python 3.6.

https://www.python.org/dev/peps/pep-0487/

We should at least support it for all Cython implemented Python classes.
Backporting it to older CPython versions would then require an internally
defined metaclass, since Python itself would otherwise not support it for
subclasses.

Any volunteers? Please reply on the cython-devel mailing list.

Stefan

From stefan_ml at behnel.de  Mon Jul 18 15:02:52 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 18 Jul 2016 21:02:52 +0200
Subject: [Cython] PEP 520 -- Preserving Class Attribute Definition Order
Message-ID: <578D27DC.6030704@behnel.de>

Hi all!

Here's a nice PEP that seems easy to implement in Cython. It has been
accepted for inclusion in Python 3.6.

https://www.python.org/dev/peps/pep-0520/

Any volunteers? Please reply on the cython-devel mailing list.

Stefan

From robertwb at gmail.com  Wed Jul 20 02:01:01 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Tue, 19 Jul 2016 23:01:01 -0700
Subject: [Cython] Cython infrastructure
Message-ID: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>

Since the inception of the Cython project, William Stein's generously
allowed us to share Sage's hardware to host Cython's infrastructure,
which has been a great help. However, I think the time has come to
re-evaluate our options, which have actually improved a lot over the
last couple of years.

Note that this is not simply an issue of finding hardware, or raw VMs,
as we want to cut down on the personal maintenance costs as well (both
ongoing and emergency, neither of which are suited to a small number
of volunteers).

Several years ago we moved the main repositories over to github, and
the wiki was moved a while ago as well (to solve the spam problem).
However, the web site, trac (for bugs), and jenkins (for continuous
testing) are still on UW hardware. I propose we address them as
follows:

cython.org
Currently cython.org consists of a single landing page, a pile of
release tarballs, and all the documentation (which is 100% generated
from the repository). I propose we rely on github pages for the
(small) site, pypi for tarball archiving, and
http://cython.readthedocs.io (I recently got admin permission for) for
the documentation.

trac.cython.org
This is probably the most controversial, but I think it makes sense to
migrate to github issues. While clearly not as powerful, featureful,
or customizable as trac, it seems it would fulfill our modest needs. I
am happy to do the migration if no one objects.

jenkins
This is the hardest to replace. We have travis.ci which integrates
well with github (e.g. automatically checking pull requests) but is
much more limited (e.g. it doesn't have artifact caching, there's no
way we'd have enough CPU to build and test the latest pre-releases of
CPython, let alone all of Sage). This has been where UW's hardware has
been something we simply couldn't get anywhere else.

There are really three parts to this: (1) the configuration (2) the
hosting of the jeknins server and (3) the build slaves themselves. (3)
is ephemeral, and ideally could come and go with little friction as
people and institutions are willing to donate raw horsepower (e.g.
UW). I'm not sure about (2)--that requires a single machine at least
(but less beefy than those for (3)). Ideally (1) could be under
revision control (e.g. in a git repository) allowing us to set up (2)
and (3) easily.

Anyone have any input/experience on this? Or can travis-ci be adopted
to be a sufficient replacement?


All of this puts a lot in the hands of one company (github). I highly
doubt they're going away, but because of the distributed nature of Git
even if they disappeared nothing permanent would be lost. I would also
set up a script to periodically backup github issues which is the one
non-repo-backed service we use. (Is it worth also trying to archive
github pr discussion? Maybe set up a and subscribe mailing list just
for that?)

- Robert

From jdemeyer at cage.ugent.be  Wed Jul 20 03:21:33 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Wed, 20 Jul 2016 09:21:33 +0200
Subject: [Cython] Cython infrastructure
In-Reply-To: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
Message-ID: <578F267D.2080901@cage.ugent.be>

On 2016-07-20 08:01, Robert Bradshaw wrote:
> let alone all of Sage

Curious. Does Cython upstream regularly test SageMath? I know I test 
Cython master occasionally on SageMath and stuff breaks sometimes.


From robertwb at gmail.com  Wed Jul 20 03:45:41 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 20 Jul 2016 00:45:41 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <578F267D.2080901@cage.ugent.be>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <578F267D.2080901@cage.ugent.be>
Message-ID: <CADiQ+QDMLH5FHnSL_Qj6v9JrYKFD5LVYQ8AP9s7qxC1ah_DxtQ@mail.gmail.com>

On Wed, Jul 20, 2016 at 12:21 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> On 2016-07-20 08:01, Robert Bradshaw wrote:
>>
>> let alone all of Sage
>
> Curious. Does Cython upstream regularly test SageMath? I know I test Cython
> master occasionally on SageMath and stuff breaks sometimes.

Admittedly that target has bit-rotted lately, but we'd like to.

From devel at baptiste-carvello.net  Wed Jul 20 05:55:31 2016
From: devel at baptiste-carvello.net (Baptiste Carvello)
Date: Wed, 20 Jul 2016 11:55:31 +0200
Subject: [Cython] Cython infrastructure
In-Reply-To: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
Message-ID: <nmnhqt$emo$1@ger.gmane.org>

Le 20/07/2016 08:01, Robert Bradshaw a ?crit :

> trac.cython.org
> This is probably the most controversial, but I think it makes sense to
> migrate to github issues. While clearly not as powerful, featureful,
> or customizable as trac, it seems it would fulfill our modest needs. I
> am happy to do the migration if no one objects.

I suppose the dev guide will be updated with advice on how users without
a Github ID should report and interact with issues. It may lead to more
issues-related discussion on this mailing list.

Cheers,
Baptiste

For avoidance of doubt: "subscribe to Github" is not an acceptable
answer, given that this means consenting to be tracked, not only inside
the Cython project, but also across projects.


From dimpase+github at gmail.com  Wed Jul 20 06:19:45 2016
From: dimpase+github at gmail.com (Dima Pasechnik)
Date: Wed, 20 Jul 2016 11:19:45 +0100
Subject: [Cython] Cython infrastructure
In-Reply-To: <nmnhqt$emo$1@ger.gmane.org>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
Message-ID: <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>

On Wed, Jul 20, 2016 at 10:55 AM, Baptiste Carvello
<devel at baptiste-carvello.net> wrote:
> Le 20/07/2016 08:01, Robert Bradshaw a ?crit :
>
>> trac.cython.org
>> This is probably the most controversial, but I think it makes sense to
>> migrate to github issues. While clearly not as powerful, featureful,
>> or customizable as trac, it seems it would fulfill our modest needs. I
>> am happy to do the migration if no one objects.
>
> I suppose the dev guide will be updated with advice on how users without
> a Github ID should report and interact with issues. It may lead to more
> issues-related discussion on this mailing list.
>
> Cheers,
> Baptiste
>
> For avoidance of doubt: "subscribe to Github" is not an acceptable
> answer, given that this means consenting to be tracked, not only inside
> the Cython project, but also across projects.

Github is not spyware, IMHO. It would be good to understand which of these:

https://help.github.com/articles/github-privacy-policy/

you have a problem with.

Yes, you will need to allow cookies in your browser.
Anything else seems to be irrelevant.

Best,
Dima

From wstein at gmail.com  Wed Jul 20 10:41:25 2016
From: wstein at gmail.com (William Stein)
Date: Wed, 20 Jul 2016 07:41:25 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
Message-ID: <CACLE5GBh77AgcZf=hwe6cozY75dBMBsdKJao=OB4fstjM80G5Q@mail.gmail.com>

On Tue, Jul 19, 2016 at 11:01 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
> Since the inception of the Cython project, William Stein's generously
> allowed us to share Sage's hardware to host Cython's infrastructure,
> which has been a great help. However, I think the time has come to
> re-evaluate our options, which have actually improved a lot over the
> last couple of years.
>
> Note that this is not simply an issue of finding hardware, or raw VMs,
> as we want to cut down on the personal maintenance costs as well (both
> ongoing and emergency, neither of which are suited to a small number
> of volunteers).
>
> Several years ago we moved the main repositories over to github, and
> the wiki was moved a while ago as well (to solve the spam problem).
> However, the web site, trac (for bugs), and jenkins (for continuous
> testing) are still on UW hardware. I propose we address them as
> follows:

Despite the flakiness of Univ of Washington hardware, and lack of any
admin support at all right now, I just want to make clear that you are
still very much allowed to use our resources, and I don't expect this
to change.   But a strategy to not have to *rely* on it in any way is
critical.

A weird curveball is that I am being "forced" by a grant to spend
about $10K on a new server (or servers) at UW in early September.  My
current plan is to get a small number of very high quality machines
and install Kubernetes on them.  Kubernetes makes it so people with
appropriate credentials can trivially point a kubernetes client at the
cluster and launch Docker container images.    This could be very
useful for build testing while making the ephemeral nature of the
available resources clear.      Though I'm busy with SageMath, Inc.,
there are a number of other people working fulltime on it now, and I'm
not teaching anymore, so I think I'll personally have the time to at
least install and setup k8s on a few machines at UW in September.

>
> cython.org
> Currently cython.org consists of a single landing page, a pile of
> release tarballs, and all the documentation (which is 100% generated
> from the repository). I propose we rely on github pages for the
> (small) site, pypi for tarball archiving, and
> http://cython.readthedocs.io (I recently got admin permission for) for
> the documentation.
>
> trac.cython.org
> This is probably the most controversial, but I think it makes sense to
> migrate to github issues. While clearly not as powerful, featureful,
> or customizable as trac, it seems it would fulfill our modest needs. I
> am happy to do the migration if no one objects.
>
> jenkins
> This is the hardest to replace. We have travis.ci which integrates
> well with github (e.g. automatically checking pull requests) but is
> much more limited (e.g. it doesn't have artifact caching, there's no
> way we'd have enough CPU to build and test the latest pre-releases of
> CPython, let alone all of Sage). This has been where UW's hardware has
> been something we simply couldn't get anywhere else.
>
> There are really three parts to this: (1) the configuration (2) the
> hosting of the jeknins server and (3) the build slaves themselves. (3)
> is ephemeral, and ideally could come and go with little friction as
> people and institutions are willing to donate raw horsepower (e.g.
> UW). I'm not sure about (2)--that requires a single machine at least
> (but less beefy than those for (3)). Ideally (1) could be under
> revision control (e.g. in a git repository) allowing us to set up (2)
> and (3) easily.
>
> Anyone have any input/experience on this? Or can travis-ci be adopted
> to be a sufficient replacement?
>
>
> All of this puts a lot in the hands of one company (github). I highly
> doubt they're going away, but because of the distributed nature of Git
> even if they disappeared nothing permanent would be lost. I would also
> set up a script to periodically backup github issues which is the one
> non-repo-backed service we use. (Is it worth also trying to archive
> github pr discussion? Maybe set up a and subscribe mailing list just
> for that?)

I'm sure a lot of people have precisely the same concern.  I do with
sagemathcloud's source code, but haven't setup similar backups yet.
I'm curious what you do.


>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel



-- 
William (http://wstein.org)

From robertwb at gmail.com  Wed Jul 20 13:18:09 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 20 Jul 2016 10:18:09 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <CACLE5GBh77AgcZf=hwe6cozY75dBMBsdKJao=OB4fstjM80G5Q@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <CACLE5GBh77AgcZf=hwe6cozY75dBMBsdKJao=OB4fstjM80G5Q@mail.gmail.com>
Message-ID: <CADiQ+QDTNh77JgQBhFJ5wY8=p7eO2HrKyG6+8Zq+9TbhPWZFhQ@mail.gmail.com>

On Wed, Jul 20, 2016 at 7:41 AM, William Stein <wstein at gmail.com> wrote:
> On Tue, Jul 19, 2016 at 11:01 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>> Since the inception of the Cython project, William Stein's generously
>> allowed us to share Sage's hardware to host Cython's infrastructure,
>> which has been a great help. However, I think the time has come to
>> re-evaluate our options, which have actually improved a lot over the
>> last couple of years.
>>
>> Note that this is not simply an issue of finding hardware, or raw VMs,
>> as we want to cut down on the personal maintenance costs as well (both
>> ongoing and emergency, neither of which are suited to a small number
>> of volunteers).
>>
>> Several years ago we moved the main repositories over to github, and
>> the wiki was moved a while ago as well (to solve the spam problem).
>> However, the web site, trac (for bugs), and jenkins (for continuous
>> testing) are still on UW hardware. I propose we address them as
>> follows:
>
> Despite the flakiness of Univ of Washington hardware, and lack of any
> admin support at all right now,

The track record is still pretty good, better than my home server on a
Comcast connection :).

> I just want to make clear that you are
> still very much allowed to use our resources, and I don't expect this
> to change.   But a strategy to not have to *rely* on it in any way is
> critical.

Thanks, and my thoughts exactly.

> A weird curveball is that I am being "forced" by a grant to spend
> about $10K on a new server (or servers) at UW in early September.  My
> current plan is to get a small number of very high quality machines
> and install Kubernetes on them.  Kubernetes makes it so people with
> appropriate credentials can trivially point a kubernetes client at the
> cluster and launch Docker container images.    This could be very
> useful for build testing while making the ephemeral nature of the
> available resources clear.      Though I'm busy with SageMath, Inc.,
> there are a number of other people working fulltime on it now, and I'm
> not teaching anymore, so I think I'll personally have the time to at
> least install and setup k8s on a few machines at UW in September.

Cool.

>> cython.org
>> Currently cython.org consists of a single landing page, a pile of
>> release tarballs, and all the documentation (which is 100% generated
>> from the repository). I propose we rely on github pages for the
>> (small) site, pypi for tarball archiving, and
>> http://cython.readthedocs.io (I recently got admin permission for) for
>> the documentation.
>>
>> trac.cython.org
>> This is probably the most controversial, but I think it makes sense to
>> migrate to github issues. While clearly not as powerful, featureful,
>> or customizable as trac, it seems it would fulfill our modest needs. I
>> am happy to do the migration if no one objects.
>>
>> jenkins
>> This is the hardest to replace. We have travis.ci which integrates
>> well with github (e.g. automatically checking pull requests) but is
>> much more limited (e.g. it doesn't have artifact caching, there's no
>> way we'd have enough CPU to build and test the latest pre-releases of
>> CPython, let alone all of Sage). This has been where UW's hardware has
>> been something we simply couldn't get anywhere else.
>>
>> There are really three parts to this: (1) the configuration (2) the
>> hosting of the jeknins server and (3) the build slaves themselves. (3)
>> is ephemeral, and ideally could come and go with little friction as
>> people and institutions are willing to donate raw horsepower (e.g.
>> UW). I'm not sure about (2)--that requires a single machine at least
>> (but less beefy than those for (3)). Ideally (1) could be under
>> revision control (e.g. in a git repository) allowing us to set up (2)
>> and (3) easily.
>>
>> Anyone have any input/experience on this? Or can travis-ci be adopted
>> to be a sufficient replacement?
>>
>>
>> All of this puts a lot in the hands of one company (github). I highly
>> doubt they're going away, but because of the distributed nature of Git
>> even if they disappeared nothing permanent would be lost. I would also
>> set up a script to periodically backup github issues which is the one
>> non-repo-backed service we use. (Is it worth also trying to archive
>> github pr discussion? Maybe set up a and subscribe mailing list just
>> for that?)
>
> I'm sure a lot of people have precisely the same concern.  I do with
> sagemathcloud's source code, but haven't setup similar backups yet.
> I'm curious what you do.

I'll probably have a cron job that syncs all the repos and downloads
the issues to my home server, which is backed up. I'd share this
script and encourage others to do the same.

From robertwb at gmail.com  Wed Jul 20 13:23:25 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 20 Jul 2016 10:23:25 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
Message-ID: <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>

On Wed, Jul 20, 2016 at 3:19 AM, Dima Pasechnik
<dimpase+github at gmail.com> wrote:
> On Wed, Jul 20, 2016 at 10:55 AM, Baptiste Carvello
> <devel at baptiste-carvello.net> wrote:
>> Le 20/07/2016 08:01, Robert Bradshaw a ?crit :
>>
>>> trac.cython.org
>>> This is probably the most controversial, but I think it makes sense to
>>> migrate to github issues. While clearly not as powerful, featureful,
>>> or customizable as trac, it seems it would fulfill our modest needs. I
>>> am happy to do the migration if no one objects.
>>
>> I suppose the dev guide will be updated with advice on how users without
>> a Github ID should report and interact with issues. It may lead to more
>> issues-related discussion on this mailing list.
>>
>> Cheers,
>> Baptiste
>>
>> For avoidance of doubt: "subscribe to Github" is not an acceptable
>> answer, given that this means consenting to be tracked, not only inside
>> the Cython project, but also across projects.
>
> Github is not spyware, IMHO. It would be good to understand which of these:
>
> https://help.github.com/articles/github-privacy-policy/
>
> you have a problem with.
>
> Yes, you will need to allow cookies in your browser.
> Anything else seems to be irrelevant.

+1

I'm a big advocate of privacy, and informed consent when choosing to
give any of it away (e.g. allowing linking of activities to build a
(pseudonymous or not) reputation). Personally, I'm actually quite
happy to have my activities on github correlated with my identity.
(Actually, it's a net plus, not a concession.)

Of course you can always set up any number of unrelated pseudonyms on
github, delete cookies, use incognito mode, and even do everything via
tor if you really want.

However, while "Subscribe to Github" is a perfectly reasonable answer,
and one that would in practice include more people than it would
exclude (compared to our current system, or many alternatives), it's
not like we're going to suddenly refuse all discussions of bugs on the
mailing lists. We're low enough volume to be flexible. A real bug
tracker is simply more useful for tracking issues than an inbox.

Does this alleviate your concerns?

- Robert

From elizabeth.fischer at columbia.edu  Wed Jul 20 13:35:19 2016
From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer)
Date: Wed, 20 Jul 2016 13:35:19 -0400
Subject: [Cython] Cython infrastructure
In-Reply-To: <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
Message-ID: <CAC_jL3wA_LbAHOQi5WtvJnL1nyrFtyKYFdvMXE91woKnvUxAWg@mail.gmail.com>

I'm of the opinion that the simplicity of GitHub Issues is a plus in many
ways.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160720/c56cd6cd/attachment.html>

From stefan_ml at behnel.de  Thu Jul 21 02:13:48 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 21 Jul 2016 08:13:48 +0200
Subject: [Cython] bug report
In-Reply-To: <CANjVt1tEGnHRdfzZj-BhyoNsXqstd2sNTk-TeoMLSA_jeo5FFQ@mail.gmail.com>
References: <CANjVt1tEGnHRdfzZj-BhyoNsXqstd2sNTk-TeoMLSA_jeo5FFQ@mail.gmail.com>
Message-ID: <ad9c0720-059d-7b4b-4538-00342f00915e@behnel.de>

swapnil jariwala schrieb am 15.07.2016 um 14:11:
> trac.cython.org does not open for me, I've come across an error while
> trying the tutorial, I've elaborated the same in below question
> 
> http://stackoverflow.com/questions/38386722/how-to-resolve-error-error-compiling-cython-file-error
> 
> any help would be highly appreciated.

It seems to me that you don't want the "__init__.py" file in your
directory. That makes it a package.

Note that this question would be best suited for the cython-users mailing
list, rather than the cython-devel core developers mailing list.

Stefan


From devel at baptiste-carvello.net  Thu Jul 21 04:42:45 2016
From: devel at baptiste-carvello.net (Baptiste Carvello)
Date: Thu, 21 Jul 2016 10:42:45 +0200
Subject: [Cython] Cython infrastructure
In-Reply-To: <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
Message-ID: <nmq1ug$t7k$1@ger.gmane.org>

Le 20/07/2016 12:19, Dima Pasechnik a ?crit :

> Github is not spyware, IMHO. It would be good to understand which of these:
> 
> https://help.github.com/articles/github-privacy-policy/
> 
> you have a problem with.

That's this one, in the terms of service:

"One person or legal entity may not maintain more than one free account,
and one machine user account that is used exclusively for performing
automated tasks."

Which means the account identifies me as a person, not just as a project
member, and they can correlate my actions across all projects.

Baptiste


From devel at baptiste-carvello.net  Thu Jul 21 05:18:43 2016
From: devel at baptiste-carvello.net (Baptiste Carvello)
Date: Thu, 21 Jul 2016 11:18:43 +0200
Subject: [Cython] Cython infrastructure
In-Reply-To: <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
Message-ID: <nmq41u$vk2$1@ger.gmane.org>

Le 20/07/2016 19:23, Robert Bradshaw a ?crit :

> +1
> 
> I'm a big advocate of privacy, and informed consent when choosing to
> give any of it away (e.g. allowing linking of activities to build a
> (pseudonymous or not) reputation).

(philosophical side note: "consent" is not free of coercion, and thus
rather irrelevant, when Github is taking over 90% of Open Source projects.)

> [...] Personally, I'm actually quite
> happy to have my activities on github correlated with my identity.
> (Actually, it's a net plus, not a concession.)

I understand your point, but I'd like to make a different choice.

> Of course you can always set up any number of unrelated pseudonyms on
> github, delete cookies, use incognito mode, and even do everything via
> tor if you really want.

No, I can't (unless I want to play cat and mouse with them, which is no
fun). And that is the whole of the problem, as I say in my other message.

> However, while "Subscribe to Github" is a perfectly reasonable answer,
> and one that would in practice include more people than it would
> exclude (compared to our current system, or many alternatives), it's
> not like we're going to suddenly refuse all discussions of bugs on the
> mailing lists. We're low enough volume to be flexible. A real bug
> tracker is simply more useful for tracking issues than an inbox.

As long as the mailing list stays, any concrete difficulty can be solved
when it arises through a constructive discussion, so nothing is lost!

I trust that Cython won't ever do like some other projects, which have
suppressed any kind of non-Github contact channel. That would be the
real pain.

> Does this alleviate your concerns?

Not fully, but I can live with it :-)

Baptiste


From isuruf at gmail.com  Thu Jul 21 05:44:54 2016
From: isuruf at gmail.com (Isuru Fernando)
Date: Thu, 21 Jul 2016 15:14:54 +0530
Subject: [Cython] Cython infrastructure
In-Reply-To: <nmq41u$vk2$1@ger.gmane.org>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
 <nmq41u$vk2$1@ger.gmane.org>
Message-ID: <CA+01voMQ+CbRs2HNJTg_Ksq5OfMCr6uyR13SOFxBUiz8Sj5FOA@mail.gmail.com>

FYI, travis does support CPython dev versions.
https://docs.travis-ci.com/user/languages/python#Choosing-Python-versions-to-test-against

Travis supports caching of build dependencies. (I remember it was not free
on OS X, but it might be now). https://docs.travis-ci.com/user/caching/

Sage is a bit tricky. If there are binaries of Sage develop branch built
for Ubuntu 12.04 or 14.04 built by Sagebots hosted somewhere, then you can
use it on Travis. I use a Sage release binary to test a project and haven't
had any issues with it.

Isuru Fernando

On Thu, Jul 21, 2016 at 2:48 PM, Baptiste Carvello <
devel at baptiste-carvello.net> wrote:

> Le 20/07/2016 19:23, Robert Bradshaw a ?crit :
>
> > +1
> >
> > I'm a big advocate of privacy, and informed consent when choosing to
> > give any of it away (e.g. allowing linking of activities to build a
> > (pseudonymous or not) reputation).
>
> (philosophical side note: "consent" is not free of coercion, and thus
> rather irrelevant, when Github is taking over 90% of Open Source projects.)
>
> > [...] Personally, I'm actually quite
> > happy to have my activities on github correlated with my identity.
> > (Actually, it's a net plus, not a concession.)
>
> I understand your point, but I'd like to make a different choice.
>
> > Of course you can always set up any number of unrelated pseudonyms on
> > github, delete cookies, use incognito mode, and even do everything via
> > tor if you really want.
>
> No, I can't (unless I want to play cat and mouse with them, which is no
> fun). And that is the whole of the problem, as I say in my other message.
>
> > However, while "Subscribe to Github" is a perfectly reasonable answer,
> > and one that would in practice include more people than it would
> > exclude (compared to our current system, or many alternatives), it's
> > not like we're going to suddenly refuse all discussions of bugs on the
> > mailing lists. We're low enough volume to be flexible. A real bug
> > tracker is simply more useful for tracking issues than an inbox.
>
> As long as the mailing list stays, any concrete difficulty can be solved
> when it arises through a constructive discussion, so nothing is lost!
>
> I trust that Cython won't ever do like some other projects, which have
> suppressed any kind of non-Github contact channel. That would be the
> real pain.
>
> > Does this alleviate your concerns?
>
> Not fully, but I can live with it :-)
>
> Baptiste
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160721/da83854d/attachment.html>

From robertwb at gmail.com  Thu Jul 21 06:14:45 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 21 Jul 2016 03:14:45 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <CA+01voMQ+CbRs2HNJTg_Ksq5OfMCr6uyR13SOFxBUiz8Sj5FOA@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
 <nmq41u$vk2$1@ger.gmane.org>
 <CA+01voMQ+CbRs2HNJTg_Ksq5OfMCr6uyR13SOFxBUiz8Sj5FOA@mail.gmail.com>
Message-ID: <CADiQ+QABnqhiNGMqJGtodepSVRgqA1nZa3=EpQk1q-92GmmJug@mail.gmail.com>

On Thu, Jul 21, 2016 at 2:44 AM, Isuru Fernando <isuruf at gmail.com> wrote:
> FYI, travis does support CPython dev versions.
> https://docs.travis-ci.com/user/languages/python#Choosing-Python-versions-to-test-against
>
> Travis supports caching of build dependencies. (I remember it was not free
> on OS X, but it might be now). https://docs.travis-ci.com/user/caching/
>
> Sage is a bit tricky. If there are binaries of Sage develop branch built for
> Ubuntu 12.04 or 14.04 built by Sagebots hosted somewhere, then you can use
> it on Travis. I use a Sage release binary to test a project and haven't had
> any issues with it.

Interesting.

In this case we actually have to (re?)build Sage to test Cython, which
is quite expensive, and testing Sage is even more expensive, so
release binaries might not be quite enough.

> Isuru Fernando
>
> On Thu, Jul 21, 2016 at 2:48 PM, Baptiste Carvello
> <devel at baptiste-carvello.net> wrote:
>>
>> Le 20/07/2016 19:23, Robert Bradshaw a ?crit :
>>
>> > +1
>> >
>> > I'm a big advocate of privacy, and informed consent when choosing to
>> > give any of it away (e.g. allowing linking of activities to build a
>> > (pseudonymous or not) reputation).
>>
>> (philosophical side note: "consent" is not free of coercion, and thus
>> rather irrelevant, when Github is taking over 90% of Open Source
>> projects.)
>>
>> > [...] Personally, I'm actually quite
>> > happy to have my activities on github correlated with my identity.
>> > (Actually, it's a net plus, not a concession.)
>>
>> I understand your point, but I'd like to make a different choice.
>>
>> > Of course you can always set up any number of unrelated pseudonyms on
>> > github, delete cookies, use incognito mode, and even do everything via
>> > tor if you really want.
>>
>> No, I can't (unless I want to play cat and mouse with them, which is no
>> fun). And that is the whole of the problem, as I say in my other message.
>>
>> > However, while "Subscribe to Github" is a perfectly reasonable answer,
>> > and one that would in practice include more people than it would
>> > exclude (compared to our current system, or many alternatives), it's
>> > not like we're going to suddenly refuse all discussions of bugs on the
>> > mailing lists. We're low enough volume to be flexible. A real bug
>> > tracker is simply more useful for tracking issues than an inbox.
>>
>> As long as the mailing list stays, any concrete difficulty can be solved
>> when it arises through a constructive discussion, so nothing is lost!
>>
>> I trust that Cython won't ever do like some other projects, which have
>> suppressed any kind of non-Github contact channel. That would be the
>> real pain.
>>
>> > Does this alleviate your concerns?
>>
>> Not fully, but I can live with it :-)
>>
>> Baptiste
>>
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> https://mail.python.org/mailman/listinfo/cython-devel
>
>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>

From dimpase+github at gmail.com  Thu Jul 21 07:13:58 2016
From: dimpase+github at gmail.com (Dima Pasechnik)
Date: Thu, 21 Jul 2016 12:13:58 +0100
Subject: [Cython] Cython infrastructure
In-Reply-To: <nmq1ug$t7k$1@ger.gmane.org>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <nmq1ug$t7k$1@ger.gmane.org>
Message-ID: <CAAWYfq2NGRrPC3_q3ewbv9mDnV1r4U-kUkeAa80jFEJr8MCnkw@mail.gmail.com>

On Thu, Jul 21, 2016 at 9:42 AM, Baptiste Carvello
<devel at baptiste-carvello.net> wrote:
> Le 20/07/2016 12:19, Dima Pasechnik a ?crit :
>
>> Github is not spyware, IMHO. It would be good to understand which of these:
>>
>> https://help.github.com/articles/github-privacy-policy/
>>
>> you have a problem with.
>
> That's this one, in the terms of service:
>
> "One person or legal entity may not maintain more than one free account,
> and one machine user account that is used exclusively for performing
> automated tasks."
>
> Which means the account identifies me as a person, not just as a project
> member, and they can correlate my actions across all projects.
>
Apart from browser cookies, they have no real means to identify users
having several identities.
This is merely done for preventing abuse by people who basically use
so much resource that they ought to pay.

That is, yes, you will need one email address per one account, and would not
try to have a 100 of such identities accessing github from the same IP.

At worst you will lose an account, that's all.

Dima

> Baptiste

From dimpase+github at gmail.com  Thu Jul 21 07:29:02 2016
From: dimpase+github at gmail.com (Dima Pasechnik)
Date: Thu, 21 Jul 2016 12:29:02 +0100
Subject: [Cython] Cython infrastructure
In-Reply-To: <nmq41u$vk2$1@ger.gmane.org>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
 <nmq41u$vk2$1@ger.gmane.org>
Message-ID: <CAAWYfq3WkA2xWYASWxVnUHSRUFTQQO+JfgVXskb15Nnzu6mgUg@mail.gmail.com>

On Thu, Jul 21, 2016 at 10:18 AM, Baptiste Carvello
<devel at baptiste-carvello.net> wrote:
> Le 20/07/2016 19:23, Robert Bradshaw a ?crit :
>
>> +1
>>
>> I'm a big advocate of privacy, and informed consent when choosing to
>> give any of it away (e.g. allowing linking of activities to build a
>> (pseudonymous or not) reputation).
>
> (philosophical side note: "consent" is not free of coercion, and thus
> rather irrelevant, when Github is taking over 90% of Open Source projects.)
>
>> [...] Personally, I'm actually quite
>> happy to have my activities on github correlated with my identity.
>> (Actually, it's a net plus, not a concession.)
>
> I understand your point, but I'd like to make a different choice.
>
>> Of course you can always set up any number of unrelated pseudonyms on
>> github, delete cookies, use incognito mode, and even do everything via
>> tor if you really want.
>
> No, I can't (unless I want to play cat and mouse with them, which is no
> fun). And that is the whole of the problem, as I say in my other message.

Actually, it's not clear why this is a problem. If you do not want to
play cat and
mouse (which means removing cookies often, etc), you would create an
identity that
only you know, and let this avatar do all the talking and working on github.
There are plenty of github users out there like this, nobody sees who
they really are.
(github knows a working email address for them, that's basically all).

>
>> However, while "Subscribe to Github" is a perfectly reasonable answer,
>> and one that would in practice include more people than it would
>> exclude (compared to our current system, or many alternatives), it's
>> not like we're going to suddenly refuse all discussions of bugs on the
>> mailing lists. We're low enough volume to be flexible. A real bug
>> tracker is simply more useful for tracking issues than an inbox.
>
> As long as the mailing list stays, any concrete difficulty can be solved
> when it arises through a constructive discussion, so nothing is lost!
>
> I trust that Cython won't ever do like some other projects, which have
> suppressed any kind of non-Github contact channel. That would be the
> real pain.

IMHO this is just spreading FUD.
Many, many projects with presence on github have, say, google groups
or/and non-github based bug/issue trackers as primary means of
communication. Noone ever heard of github undermining these projects
in any way.

Dima

>
>> Does this alleviate your concerns?
>
> Not fully, but I can live with it :-)
>
> Baptiste
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel

From robertwb at gmail.com  Sat Jul 23 20:25:45 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Sat, 23 Jul 2016 17:25:45 -0700
Subject: [Cython] Cython infrastructure
In-Reply-To: <CAAWYfq3WkA2xWYASWxVnUHSRUFTQQO+JfgVXskb15Nnzu6mgUg@mail.gmail.com>
References: <CADiQ+QDWPuehPM3qyC777OAZBGCeDGu8KX1Rjah6szdi-Tc=cA@mail.gmail.com>
 <nmnhqt$emo$1@ger.gmane.org>
 <CAAWYfq0eRu-nMmsaUwY8sn8Q6kfJaU8t_EQcya_igH3mBLgYSg@mail.gmail.com>
 <CADiQ+QDY8RUV-rAGDRLj+AJwCYA-eENDAJ2MNB-2PwmSERpifg@mail.gmail.com>
 <nmq41u$vk2$1@ger.gmane.org>
 <CAAWYfq3WkA2xWYASWxVnUHSRUFTQQO+JfgVXskb15Nnzu6mgUg@mail.gmail.com>
Message-ID: <CADiQ+QAg4RVg03TXOp-E4_yc4xrzpexyA6xGH-KuT5tvxx368Q@mail.gmail.com>

On Thu, Jul 21, 2016 at 4:29 AM, Dima Pasechnik
<dimpase+github at gmail.com> wrote:
> On Thu, Jul 21, 2016 at 10:18 AM, Baptiste Carvello
> <devel at baptiste-carvello.net> wrote:
>> Le 20/07/2016 19:23, Robert Bradshaw a ?crit :
>>
>>> +1
>>>
>>> I'm a big advocate of privacy, and informed consent when choosing to
>>> give any of it away (e.g. allowing linking of activities to build a
>>> (pseudonymous or not) reputation).
>>
>> (philosophical side note: "consent" is not free of coercion, and thus
>> rather irrelevant, when Github is taking over 90% of Open Source projects.)
>>
>>> [...] Personally, I'm actually quite
>>> happy to have my activities on github correlated with my identity.
>>> (Actually, it's a net plus, not a concession.)
>>
>> I understand your point, but I'd like to make a different choice.
>>
>>> Of course you can always set up any number of unrelated pseudonyms on
>>> github, delete cookies, use incognito mode, and even do everything via
>>> tor if you really want.
>>
>> No, I can't (unless I want to play cat and mouse with them, which is no
>> fun). And that is the whole of the problem, as I say in my other message.
>
> Actually, it's not clear why this is a problem. If you do not want to
> play cat and
> mouse (which means removing cookies often, etc), you would create an
> identity that
> only you know, and let this avatar do all the talking and working on github.
> There are plenty of github users out there like this, nobody sees who
> they really are.
> (github knows a working email address for them, that's basically all).
>
>>
>>> However, while "Subscribe to Github" is a perfectly reasonable answer,
>>> and one that would in practice include more people than it would
>>> exclude (compared to our current system, or many alternatives), it's
>>> not like we're going to suddenly refuse all discussions of bugs on the
>>> mailing lists. We're low enough volume to be flexible. A real bug
>>> tracker is simply more useful for tracking issues than an inbox.
>>
>> As long as the mailing list stays, any concrete difficulty can be solved
>> when it arises through a constructive discussion, so nothing is lost!
>>
>> I trust that Cython won't ever do like some other projects, which have
>> suppressed any kind of non-Github contact channel. That would be the
>> real pain.
>
> IMHO this is just spreading FUD.
> Many, many projects with presence on github have, say, google groups
> or/and non-github based bug/issue trackers as primary means of
> communication. Noone ever heard of github undermining these projects
> in any way.

I think he's concerned about projects that decide (deliberately or
not) to discontinue (or ignore) their mailing lists, only
communicating via github (or some other closed system). Or if one had
dozens of bug reports coming in a week, I could understand asking
users to always file reports in the tracker themselves, and keep
discussion there (where it's more easily filtered and keeps the main
dev list a reasonable volume). Yes, this would require a github
account, which is too much for some people.

We're keeping our mailing list(s). We require at least email address
and an online presence (no snail mail) to submit and discuss bugs.
That is too much for some people too.

It sounds like there's no objections to moving the site, everyone can
live with moving the bug tracker, and we're still up in the air on
what to do with the build farm. I'll get on the first two.

- Robert

From yury at shurup.com  Mon Jul 25 09:27:40 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Mon, 25 Jul 2016 15:27:40 +0200 (CEST)
Subject: [Cython] (Possible) bug: module level global vars end up in upper
 scope?
Message-ID: <alpine.LRH.2.20.1607251520260.13656@vps.zaytsev.net>

Hi,

I've hit the following deviation from Python 2: when a Cython module has a 
global variable, somehow, upon importing the module, the global variables 
end up in the *current* (importing) module scope, rather than *imported* 
module scope, and, while normally relatively harmless, in the case of 
namedtuples, for instance, this has caused pickling errors in our 
production code.

test1.py / test2.pyx

     import collections

     Test = collections.namedtuple("Test", ["test"])

$ ipython
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
IPython 1.2.1 -- An enhanced Interactive Python.

In [1]: import test1

In [2]: test1.Test
Out[2]: test1.Test

In [3]: import test2

In [4]: test2.Test
Out[4]: __main__.Test

I would appreciate any hints in the case that I'm deeply confused and 
doing something obviously wrong...

-- 
Sincerely yours,
Yury V. Zaytsev

From jdemeyer at cage.ugent.be  Wed Jul 27 11:34:40 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Wed, 27 Jul 2016 17:34:40 +0200
Subject: [Cython] BUG: cannot override cdef by cpdef method in .pxd
Message-ID: <5798D490.8090804@cage.ugent.be>

Hello,

I recently learned from Robert Bradshaw that it is legal in Cython to 
override cdef methods by cpdef methods. But doing this in a .pxd file 
causes a compile-time error:

*foo.pyx*:

cdef class Base(object):
     cdef meth(self):
         print("Base.meth()")

cdef class Derived(Base):
     cpdef meth(self):
         print("Derived.meth()")

*foo.pxd*:

cdef class Base(object):
     cdef meth(self)

cdef class Derived(Base):
     cpdef meth(self)

This gives (both on 0.24.1 and on master):

Error compiling Cython file:
------------------------------------------------------------
...
cdef class Base(object):
     cdef meth(self):
         return self

cdef class Derived(Base):
     cpdef meth(self):
          ^
------------------------------------------------------------

foo.pyx:6:10: 'meth' already defined


As second attempt, I could simply not declare the cpdef method in the 
.pxd file. Just use

cdef class Derived(Base):
     pass

This compiles, but leads to bugs with broken vtabs. I am omitting the 
complete code here, but it's clear why this cannot work: other modules 
get the vtab wrong since they don't know about the cpdef slot.


Jeroen.

From stefan_ml at behnel.de  Wed Jul 27 14:42:06 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 27 Jul 2016 20:42:06 +0200
Subject: [Cython] (Possible) bug: module level global vars end up in
 upper scope?
In-Reply-To: <alpine.LRH.2.20.1607251520260.13656@vps.zaytsev.net>
References: <alpine.LRH.2.20.1607251520260.13656@vps.zaytsev.net>
Message-ID: <77729699-282c-58b5-1d71-35f8b5bda522@behnel.de>

Yury V. Zaytsev schrieb am 25.07.2016 um 15:27:
> I've hit the following deviation from Python 2: when a Cython module has a
> global variable, somehow, upon importing the module, the global variables
> end up in the *current* (importing) module scope, rather than *imported*
> module scope, and, while normally relatively harmless, in the case of
> namedtuples, for instance, this has caused pickling errors in our
> production code.
> 
> test1.py / test2.pyx
> 
>     import collections
> 
>     Test = collections.namedtuple("Test", ["test"])
> 
> $ ipython
> Python 2.7.6 (default, Jun 22 2015, 17:58:13)
> IPython 1.2.1 -- An enhanced Interactive Python.
> 
> In [1]: import test1
> 
> In [2]: test1.Test
> Out[2]: test1.Test
> 
> In [3]: import test2
> 
> In [4]: test2.Test
> Out[4]: __main__.Test
> 
> I would appreciate any hints in the case that I'm deeply confused and doing
> something obviously wrong...

namedtuple has an impressively complicated and fragile implementation.
Amongst other things, it does this at the end:

    result.__module__ = _sys._getframe(1).f_globals.get(
                                             '__name__', '__main__')

Since Cython modules do not have frames (by default, for performance
reasons), the module it finds then points to the caller instead.

I wonder if we shouldn't consider the module init function a special
(enough) case here that is never performance critical, and just always
generate a frame for it. Later frame lookups would then still fail (so we'd
create somewhat of an inconsistency), but the case above looks like a
legitimate use case, and namedtuples are often (I guess in *most* cases)
created at module init time.

I created a ticket.

https://github.com/cython/cython/issues/536

As a work-around, I could only come up with a hack. You could create a
Python module, import and call into it from your Cython module, create the
namedtuple in Python, and then fix the __module__ reference of the
namedtuple class after the fact. Although I wonder when the insertion into
the module namespace happens. I couldn't find it on a quick look.

Stefan


From yury at shurup.com  Wed Jul 27 16:05:59 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Wed, 27 Jul 2016 22:05:59 +0200 (CEST)
Subject: [Cython] (Possible) bug: module level global vars end up in
 upper scope?
In-Reply-To: <77729699-282c-58b5-1d71-35f8b5bda522@behnel.de>
References: <alpine.LRH.2.20.1607251520260.13656@vps.zaytsev.net>
 <77729699-282c-58b5-1d71-35f8b5bda522@behnel.de>
Message-ID: <alpine.LRH.2.20.1607272157421.13656@vps.zaytsev.net>

Hi Stefan,

On Wed, 27 Jul 2016, Stefan Behnel wrote:

> I wonder if we shouldn't consider the module init function a special
> (enough) case here that is never performance critical, and just always
> generate a frame for it. Later frame lookups would then still fail (so we'd
> create somewhat of an inconsistency), but the case above looks like a
> legitimate use case, and namedtuples are often (I guess in *most* cases)
> created at module init time.
>
> I created a ticket.
>
> https://github.com/cython/cython/issues/536

Thank you very much for the insightful analysis, makes total sense!

I agree that creating a frame for the init function sounds like a most 
reasonable solution, the only drawback that I can see is the inconsistency 
you mentioned, but apparently that's as good as it gets...

> As a work-around, I could only come up with a hack. You could create a 
> Python module, import and call into it from your Cython module, create 
> the namedtuple in Python, and then fix the __module__ reference of the 
> namedtuple class after the fact. Although I wonder when the insertion 
> into the module namespace happens. I couldn't find it on a quick look.

Now that you've explained the root cause, I believe that there is a less 
disgusting workaround one could possibly go for, what do you think?

     class PyTest(namedtuple('Test', 'test')):
         pass

-- 
Sincerely yours,
Yury V. Zaytsev

From robertwb at gmail.com  Thu Jul 28 18:33:44 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 28 Jul 2016 15:33:44 -0700
Subject: [Cython] Migration of tickets from trac to github
Message-ID: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>

Please see https://github.com/robertwb/issues-import-test/issues/ as
to what this would look like. (This is a partial import, due to github
API rate limiting issues.) Unless something looks terribly wrong, I'll
start the real migration shortly.

- Robert

From stefan_ml at behnel.de  Fri Jul 29 00:13:09 2016
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 29 Jul 2016 06:13:09 +0200
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
Message-ID: <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>

Robert Bradshaw schrieb am 29.07.2016 um 00:33:
> Please see https://github.com/robertwb/issues-import-test/issues/ as
> to what this would look like. (This is a partial import, due to github
> API rate limiting issues.) Unless something looks terribly wrong, I'll
> start the real migration shortly.

Nice, also the formatting and tagging. And the milestone history also seems
to have passed through nicely.

My comments:

Tags like "C: Code Generation" look like they are referring specifically to
C-Code, but I guess you meant "C-omponent". Maybe change the abbreviation
to M-odule or T-opic ?

Do we really need the empty "modified by" comments, e.g. here:
https://github.com/robertwb/issues-import-test/issues/110

This looks a bit overly empty:
https://github.com/robertwb/issues-import-test/issues/55

When I click on one of the "migrated from" links to "trac.cython.org", I
get redirected back to github, but with the trac ticket number, which means
I get either a 404 or a totally different ticket on github. I guess that
can be fixed once we have a mapping from trac ticket numbers to github tickets.

Related to that: converted ticket #73 has a reference to another trac
ticket (#51) in a comment, which now links to the (wrong) github ticket #51.
https://github.com/robertwb/issues-import-test/issues/73

Also, the formatting is broken in the description of that ticket (#73).
Might already have been a problem in trac.

And again #73: there is a link to the old hg repo in a comment. I guess we
might simply not be able to recover the old hg changeset IDs to provide a
mapping of those to the corresponding github changeset URLs, right?

Stefan


From robertwb at math.washington.edu  Fri Jul 29 00:50:28 2016
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 28 Jul 2016 21:50:28 -0700
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
Message-ID: <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>

On Thu, Jul 28, 2016 at 9:13 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw schrieb am 29.07.2016 um 00:33:
>> Please see https://github.com/robertwb/issues-import-test/issues/ as
>> to what this would look like. (This is a partial import, due to github
>> API rate limiting issues.) Unless something looks terribly wrong, I'll
>> start the real migration shortly.
>
> Nice, also the formatting and tagging. And the milestone history also seems
> to have passed through nicely.

Thanks. FYI, I'm using https://github.com/trustmaster/trac2github .
(It's been a looong time since I've messed with php, but the couple of
Python ones were broken or not as feature complete...)

> My comments:
>
> Tags like "C: Code Generation" look like they are referring specifically to
> C-Code, but I guess you meant "C-omponent". Maybe change the abbreviation
> to M-odule or T-opic ?

The C is "component." Probably could simply drop the C altogether.

> Do we really need the empty "modified by" comments, e.g. here:
> https://github.com/robertwb/issues-import-test/issues/110

Hmm... I wonder if this was an ownership change (that was having
trouble exporting).

> This looks a bit overly empty:
> https://github.com/robertwb/issues-import-test/issues/55

Yeah, that was empty before.

> When I click on one of the "migrated from" links to "trac.cython.org", I
> get redirected back to github, but with the trac ticket number, which means
> I get either a 404 or a totally different ticket on github. I guess that
> can be fixed once we have a mapping from trac ticket numbers to github tickets.

Yep. Had we not had any issues, we could have maybe kept the numbers,
but it's too late for that now.

I'm not quite sure how to serve the mappings--I'd rather not run a
service just for that. One idea is a custom 404 page with javascript?
Or I suppose there's a finite number, so we could just a static for
each one in the site in a ticket subdirectory.

> Related to that: converted ticket #73 has a reference to another trac
> ticket (#51) in a comment, which now links to the (wrong) github ticket #51.
> https://github.com/robertwb/issues-import-test/issues/73

Hmm... I should spell that out.

> Also, the formatting is broken in the description of that ticket (#73).
> Might already have been a problem in trac.

The spaces were there, the code markers weren't. Doesn't seem too
common. I think we'll have to fix some one-offs.

> And again #73: there is a link to the old hg repo in a comment. I guess we
> might simply not be able to recover the old hg changeset IDs to provide a
> mapping of those to the corresponding github changeset URLs, right?

Yeah, that's a bit harder. (With an old hg repo, one could probably
recover the mapping using temestamps and/or description+author...)

From yury at shurup.com  Fri Jul 29 01:15:02 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Fri, 29 Jul 2016 07:15:02 +0200 (CEST)
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
 <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1607290711560.13656@vps.zaytsev.net>

On Thu, 28 Jul 2016, Robert Bradshaw wrote:

>> When I click on one of the "migrated from" links to "trac.cython.org", 
>> I get redirected back to github, but with the trac ticket number, which 
>> means I get either a 404 or a totally different ticket on github. I 
>> guess that can be fixed once we have a mapping from trac ticket numbers 
>> to github tickets.
>
> Yep. Had we not had any issues, we could have maybe kept the numbers, 
> but it's too late for that now.

Just an idea: one could, of course, disable issues for the main cython 
repository and create a separate repository like `cython-issues`. Not sure 
if it's worth it though...

-- 
Sincerely yours,
Yury V. Zaytsev

From robertwb at math.washington.edu  Fri Jul 29 03:38:06 2016
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Fri, 29 Jul 2016 00:38:06 -0700
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <alpine.LRH.2.20.1607290711560.13656@vps.zaytsev.net>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
 <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
 <alpine.LRH.2.20.1607290711560.13656@vps.zaytsev.net>
Message-ID: <CADiQ+QALWt05WW7546HxHPQ52mpgKv+DA8BjfZt6UvkdQ0eAJQ@mail.gmail.com>

On Thu, Jul 28, 2016 at 10:15 PM, Yury V. Zaytsev <yury at shurup.com> wrote:
> On Thu, 28 Jul 2016, Robert Bradshaw wrote:
>
>>> When I click on one of the "migrated from" links to "trac.cython.org", I
>>> get redirected back to github, but with the trac ticket number, which means
>>> I get either a 404 or a totally different ticket on github. I guess that can
>>> be fixed once we have a mapping from trac ticket numbers to github tickets.
>>
>>
>> Yep. Had we not had any issues, we could have maybe kept the numbers, but
>> it's too late for that now.
>
>
> Just an idea: one could, of course, disable issues for the main cython
> repository and create a separate repository like `cython-issues`. Not sure
> if it's worth it though...

That's an idea, though then we'd loose things like pull request
linkage and have to migrate the issues that are already there. I think
it's worth having a bounded amount of "odd" history with a "standard"
setup going forward.

From jdemeyer at cage.ugent.be  Fri Jul 29 03:46:43 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 29 Jul 2016 09:46:43 +0200
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
 <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
Message-ID: <579B09E3.9070502@cage.ugent.be>

On 2016-07-29 06:50, Robert Bradshaw wrote:
> I'm not quite sure how to serve the mappings

I think it's really important to keep redirects from the old Trac 
tickets to GitHub. There are a lot of links from SageMath to some Cython 
Trac ticket and it would be a shame to lose that.

>> Related to that: converted ticket #73 has a reference to another trac
>> ticket (#51) in a comment, which now links to the (wrong) github ticket #51.
>> https://github.com/robertwb/issues-import-test/issues/73
>
> Hmm... I should spell that out.

Just make the link explicit to trac.cython.org...

From jdemeyer at cage.ugent.be  Fri Jul 29 03:49:44 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 29 Jul 2016 09:49:44 +0200
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
Message-ID: <579B0A98.3060306@cage.ugent.be>

There are some duplicates, like
https://github.com/robertwb/issues-import-test/issues/130
and
https://github.com/robertwb/issues-import-test/issues/137

From yury at shurup.com  Fri Jul 29 03:50:27 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Fri, 29 Jul 2016 09:50:27 +0200 (CEST)
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QALWt05WW7546HxHPQ52mpgKv+DA8BjfZt6UvkdQ0eAJQ@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
 <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
 <alpine.LRH.2.20.1607290711560.13656@vps.zaytsev.net>
 <CADiQ+QALWt05WW7546HxHPQ52mpgKv+DA8BjfZt6UvkdQ0eAJQ@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1607290943490.13656@vps.zaytsev.net>

On Fri, 29 Jul 2016, Robert Bradshaw wrote:

> That's an idea, though then we'd loose things like pull request linkage 
> and have to migrate the issues that are already there.

Not that I'm advocating for this option, but pull request linkage will 
stay in place: disabling issues doesn't disable pull requests. Also, 
references to the old issues might remain valid, although I'm not so sure 
about that.

Anyways, on GitHub, you can reference issues across the repositories, so 
for migrated issues one could just use that, which brings me neatly to the 
next point:

One could also consider migrating Trac to a separate issues-only 
repository under Cython account for historical / archiving / cross-linking 
purposes, and agreeing to freeze it going forward. From that point on one 
might just start making full use of issues under the main repository...

P.S. If you don't want to hear more stupid proposals, please let me know.

-- 
Sincerely yours,
Yury V. Zaytsev

From robertwb at gmail.com  Fri Jul 29 03:50:28 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 29 Jul 2016 00:50:28 -0700
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <579B09E3.9070502@cage.ugent.be>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <d81e74e6-a053-6031-5beb-5d95ec9cb29a@behnel.de>
 <CADiQ+QDRSii5cm9yKUXT6+LwtLA-6OAYFirfh_JzzCpC07mbOA@mail.gmail.com>
 <579B09E3.9070502@cage.ugent.be>
Message-ID: <CADiQ+QCJbcGZb9dVNQz0d+YjEq=CWYTcs9cyuVN3snH0XhtWOw@mail.gmail.com>

On Fri, Jul 29, 2016 at 12:46 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> On 2016-07-29 06:50, Robert Bradshaw wrote:
>>
>> I'm not quite sure how to serve the mappings
>
> I think it's really important to keep redirects from the old Trac tickets to
> GitHub. There are a lot of links from SageMath to some Cython Trac ticket
> and it would be a shame to lose that.

Yes. I figured out how to do redirects (e.g.
http://trac.cython.org/ticket/32 ). Now to generate the tickets and
get the mappings...

>>> Related to that: converted ticket #73 has a reference to another trac
>>> ticket (#51) in a comment, which now links to the (wrong) github ticket
>>> #51.
>>> https://github.com/robertwb/issues-import-test/issues/73
>>
>>
>> Hmm... I should spell that out.
>
> Just make the link explicit to trac.cython.org...

Yep.

From robertwb at gmail.com  Fri Jul 29 03:51:20 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 29 Jul 2016 00:51:20 -0700
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <579B0A98.3060306@cage.ugent.be>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <579B0A98.3060306@cage.ugent.be>
Message-ID: <CADiQ+QCB7bm+WZTtaY10G_1my_DNEa86xthmw6tjM-xJbFXU6g@mail.gmail.com>

Yes, several. I was intentionally re-importing the same ranges to see
how things looked.

On Fri, Jul 29, 2016 at 12:49 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> There are some duplicates, like
> https://github.com/robertwb/issues-import-test/issues/130
> and
> https://github.com/robertwb/issues-import-test/issues/137
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel

From jdemeyer at cage.ugent.be  Fri Jul 29 04:23:48 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 29 Jul 2016 10:23:48 +0200
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
Message-ID: <579B1294.508@cage.ugent.be>

What about attachments to Trac tickets? This ones mentions a patch, but 
the patch does not appear on GitHub as far as I can tell:

https://github.com/robertwb/issues-import-test/issues/122

From robertwb at gmail.com  Fri Jul 29 04:30:36 2016
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 29 Jul 2016 01:30:36 -0700
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <579B1294.508@cage.ugent.be>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
 <579B1294.508@cage.ugent.be>
Message-ID: <CADiQ+QAzDHE5hs7jkDVAbWFaQfm==Qb-twAX=TEViMXuW5znCA@mail.gmail.com>

No, this didn't do attachments. It'd be good to get a handle on how
large a loss that would be for Cython (for Sage attachments are key).

I also just discovered
https://gist.github.com/jonmagic/5282384165e0f86ef105 which looks like
it might be a better solution.

On Fri, Jul 29, 2016 at 1:23 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> What about attachments to Trac tickets? This ones mentions a patch, but the
> patch does not appear on GitHub as far as I can tell:
>
> https://github.com/robertwb/issues-import-test/issues/122
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel

From jdemeyer at cage.ugent.be  Fri Jul 29 08:37:55 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 29 Jul 2016 14:37:55 +0200
Subject: [Cython] Migration of tickets from trac to github
In-Reply-To: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
References: <CADiQ+QBM8maiieSpuW54Vpy5Nyt=iwDcXdFTsDvhTN_SJH1cYA@mail.gmail.com>
Message-ID: <579B4E23.6040503@cage.ugent.be>

We should also about a convention about naming testsuite files.

For example, there is
tests/compile/distutils_libraries_T845.srctree

Should this be changed to
tests/compile/distutils_libraries_GH1234.srctree

if this becomes GitHub issue #1234?

From jdemeyer at cage.ugent.be  Fri Jul 29 09:24:15 2016
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Fri, 29 Jul 2016 15:24:15 +0200
Subject: [Cython] BUG: cannot override cdef by cpdef method in .pxd
In-Reply-To: <5798D490.8090804@cage.ugent.be>
References: <5798D490.8090804@cage.ugent.be>
Message-ID: <579B58FF.50206@cage.ugent.be>

Fixed with a 1-line change:
https://github.com/cython/cython/pull/545