From wesmckinn at gmail.com  Mon Sep  5 10:04:47 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Mon, 5 Sep 2016 10:04:47 -0400
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
Message-ID: <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>

What does everyone think about going ahead with the move? I imagine
there are a variety of services (e.g. Travis CI and others) we'll need
to migrate over concurrently. Want to avoid possible disruptions to
day-to-day development (luckily GitHub has made this mostly painless
in my experience).

On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> I've parked github.com/pandas-dev for the time being. Interested to
> see what others think about the migration
>
> On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
>> Too bad about the "pandas" GitHub name. Still, if you want to go for this, I
>> say you should go ahead.
>>
>> My sense (have not checked actual data here) is that all other projects than
>> pandas add a very minimal amount of CI burden, though.
>>
>> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>>
>>> According to GitHub, the pandas account is showing activity that is
>>> not publicly visible. I've contacted the user twice in an effort to
>>> start a dialog but GitHub is very strict about protecting users'
>>> privacy.
>>>
>>> We could do something like @pandas-org for the time being, and hope
>>> that at some point we are able to contact the @pandas user (or they
>>> become inactive).
>>>
>>> - Wes
>>>
>>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>> > Did you have any luck going through GitHub's process for reclaiming an
>>> > unused name? You don't necessarily need to contact the account owner for
>>> > this.
>>> > https://help.github.com/articles/name-squatting-policy/
>>> >
>>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects do
>>> > make
>>> > this quite smooth.
>>> >
>>> > The main reason I switched xarray to pydata (from the separate xray org)
>>> > is
>>> > because I didn't think I would be successful claiming xarray, which
>>> > appears
>>> > to be in active use.
>>> >
>>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com>
>>> > wrote:
>>> >>
>>> >> We've occasionally discussed moving pandas and associated repos to a
>>> >> dedicated GitHub organization.
>>> >>
>>> >> Some arguments for moving to our own org:
>>> >>
>>> >> - More clear what repositories are part of the "pandas" umbrella (we
>>> >> can potentially formalize this in the pandas-governance repo)
>>> >>
>>> >> - Dedicated capacity from CI services
>>> >>
>>> >> - Easier for us to more clearly develop our own open source project
>>> >> branding independent from PyData (which has increasingly primarily
>>> >> become a conference / meetup brand)
>>> >>
>>> >> While I haven't had any success contacting the owner of
>>> >> github.com/pandas, if we can pick a suitable org name we might
>>> >> consider it. GitHub's route forwarding (including git remotes) makes
>>> >> org changes pretty painless these days
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> - Wes
>>> >> _______________________________________________
>>> >> Pandas-dev mailing list
>>> >> Pandas-dev at python.org
>>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>>> >
>>> >
>>
>>

From jorisvandenbossche at gmail.com  Mon Sep  5 10:34:02 2016
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Mon, 5 Sep 2016 16:34:02 +0200
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
Message-ID: <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>

I am positive on a move (although the 'pandas' org would be nice), so OK
with going ahead.

Joris

2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:

> What does everyone think about going ahead with the move? I imagine
> there are a variety of services (e.g. Travis CI and others) we'll need
> to migrate over concurrently. Want to avoid possible disruptions to
> day-to-day development (luckily GitHub has made this mostly painless
> in my experience).
>
> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> > I've parked github.com/pandas-dev for the time being. Interested to
> > see what others think about the migration
> >
> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com>
> wrote:
> >> Too bad about the "pandas" GitHub name. Still, if you want to go for
> this, I
> >> say you should go ahead.
> >>
> >> My sense (have not checked actual data here) is that all other projects
> than
> >> pandas add a very minimal amount of CI burden, though.
> >>
> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com>
> wrote:
> >>>
> >>> According to GitHub, the pandas account is showing activity that is
> >>> not publicly visible. I've contacted the user twice in an effort to
> >>> start a dialog but GitHub is very strict about protecting users'
> >>> privacy.
> >>>
> >>> We could do something like @pandas-org for the time being, and hope
> >>> that at some point we are able to contact the @pandas user (or they
> >>> become inactive).
> >>>
> >>> - Wes
> >>>
> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com>
> wrote:
> >>> > Did you have any luck going through GitHub's process for reclaiming
> an
> >>> > unused name? You don't necessarily need to contact the account owner
> for
> >>> > this.
> >>> > https://help.github.com/articles/name-squatting-policy/
> >>> >
> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects do
> >>> > make
> >>> > this quite smooth.
> >>> >
> >>> > The main reason I switched xarray to pydata (from the separate xray
> org)
> >>> > is
> >>> > because I didn't think I would be successful claiming xarray, which
> >>> > appears
> >>> > to be in active use.
> >>> >
> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> We've occasionally discussed moving pandas and associated repos to a
> >>> >> dedicated GitHub organization.
> >>> >>
> >>> >> Some arguments for moving to our own org:
> >>> >>
> >>> >> - More clear what repositories are part of the "pandas" umbrella (we
> >>> >> can potentially formalize this in the pandas-governance repo)
> >>> >>
> >>> >> - Dedicated capacity from CI services
> >>> >>
> >>> >> - Easier for us to more clearly develop our own open source project
> >>> >> branding independent from PyData (which has increasingly primarily
> >>> >> become a conference / meetup brand)
> >>> >>
> >>> >> While I haven't had any success contacting the owner of
> >>> >> github.com/pandas, if we can pick a suitable org name we might
> >>> >> consider it. GitHub's route forwarding (including git remotes) makes
> >>> >> org changes pretty painless these days
> >>> >>
> >>> >> Thoughts?
> >>> >>
> >>> >> - Wes
> >>> >> _______________________________________________
> >>> >> Pandas-dev mailing list
> >>> >> Pandas-dev at python.org
> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
> >>> >
> >>> >
> >>
> >>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160905/9b8634ea/attachment.html>

From tom.augspurger88 at gmail.com  Mon Sep  5 10:42:39 2016
From: tom.augspurger88 at gmail.com (Tom Augspurger)
Date: Mon, 5 Sep 2016 09:42:39 -0500
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
 <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
Message-ID: <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>

I just migrated a repo and it was painless. Is there a reason to wait till
after the release candidate?

On Mon, Sep 5, 2016 at 9:34 AM, Joris Van den Bossche <
jorisvandenbossche at gmail.com> wrote:

> I am positive on a move (although the 'pandas' org would be nice), so OK
> with going ahead.
>
> Joris
>
> 2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:
>
>> What does everyone think about going ahead with the move? I imagine
>> there are a variety of services (e.g. Travis CI and others) we'll need
>> to migrate over concurrently. Want to avoid possible disruptions to
>> day-to-day development (luckily GitHub has made this mostly painless
>> in my experience).
>>
>> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com>
>> wrote:
>> > I've parked github.com/pandas-dev for the time being. Interested to
>> > see what others think about the migration
>> >
>> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com>
>> wrote:
>> >> Too bad about the "pandas" GitHub name. Still, if you want to go for
>> this, I
>> >> say you should go ahead.
>> >>
>> >> My sense (have not checked actual data here) is that all other
>> projects than
>> >> pandas add a very minimal amount of CI burden, though.
>> >>
>> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com>
>> wrote:
>> >>>
>> >>> According to GitHub, the pandas account is showing activity that is
>> >>> not publicly visible. I've contacted the user twice in an effort to
>> >>> start a dialog but GitHub is very strict about protecting users'
>> >>> privacy.
>> >>>
>> >>> We could do something like @pandas-org for the time being, and hope
>> >>> that at some point we are able to contact the @pandas user (or they
>> >>> become inactive).
>> >>>
>> >>> - Wes
>> >>>
>> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com>
>> wrote:
>> >>> > Did you have any luck going through GitHub's process for reclaiming
>> an
>> >>> > unused name? You don't necessarily need to contact the account
>> owner for
>> >>> > this.
>> >>> > https://help.github.com/articles/name-squatting-policy/
>> >>> >
>> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects
>> do
>> >>> > make
>> >>> > this quite smooth.
>> >>> >
>> >>> > The main reason I switched xarray to pydata (from the separate xray
>> org)
>> >>> > is
>> >>> > because I didn't think I would be successful claiming xarray, which
>> >>> > appears
>> >>> > to be in active use.
>> >>> >
>> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com
>> >
>> >>> > wrote:
>> >>> >>
>> >>> >> We've occasionally discussed moving pandas and associated repos to
>> a
>> >>> >> dedicated GitHub organization.
>> >>> >>
>> >>> >> Some arguments for moving to our own org:
>> >>> >>
>> >>> >> - More clear what repositories are part of the "pandas" umbrella
>> (we
>> >>> >> can potentially formalize this in the pandas-governance repo)
>> >>> >>
>> >>> >> - Dedicated capacity from CI services
>> >>> >>
>> >>> >> - Easier for us to more clearly develop our own open source project
>> >>> >> branding independent from PyData (which has increasingly primarily
>> >>> >> become a conference / meetup brand)
>> >>> >>
>> >>> >> While I haven't had any success contacting the owner of
>> >>> >> github.com/pandas, if we can pick a suitable org name we might
>> >>> >> consider it. GitHub's route forwarding (including git remotes)
>> makes
>> >>> >> org changes pretty painless these days
>> >>> >>
>> >>> >> Thoughts?
>> >>> >>
>> >>> >> - Wes
>> >>> >> _______________________________________________
>> >>> >> Pandas-dev mailing list
>> >>> >> Pandas-dev at python.org
>> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>> >>> >
>> >>> >
>> >>
>> >>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160905/e8b975be/attachment-0001.html>

From jeffreback at gmail.com  Mon Sep  5 11:17:59 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Mon, 5 Sep 2016 11:17:59 -0400
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
 <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
 <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>
Message-ID: <FE34BF07-D355-4B6C-95B3-AE8EA735B838@gmail.com>

+1 in this

> On Sep 5, 2016, at 10:42 AM, Tom Augspurger <tom.augspurger88 at gmail.com> wrote:
> 
> I just migrated a repo and it was painless. Is there a reason to wait till after the release candidate?
> 
>> On Mon, Sep 5, 2016 at 9:34 AM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
>> I am positive on a move (although the 'pandas' org would be nice), so OK with going ahead.
>> 
>> Joris
>> 
>> 2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:
>>> What does everyone think about going ahead with the move? I imagine
>>> there are a variety of services (e.g. Travis CI and others) we'll need
>>> to migrate over concurrently. Want to avoid possible disruptions to
>>> day-to-day development (luckily GitHub has made this mostly painless
>>> in my experience).
>>> 
>>> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>> > I've parked github.com/pandas-dev for the time being. Interested to
>>> > see what others think about the migration
>>> >
>>> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>> >> Too bad about the "pandas" GitHub name. Still, if you want to go for this, I
>>> >> say you should go ahead.
>>> >>
>>> >> My sense (have not checked actual data here) is that all other projects than
>>> >> pandas add a very minimal amount of CI burden, though.
>>> >>
>>> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>> >>>
>>> >>> According to GitHub, the pandas account is showing activity that is
>>> >>> not publicly visible. I've contacted the user twice in an effort to
>>> >>> start a dialog but GitHub is very strict about protecting users'
>>> >>> privacy.
>>> >>>
>>> >>> We could do something like @pandas-org for the time being, and hope
>>> >>> that at some point we are able to contact the @pandas user (or they
>>> >>> become inactive).
>>> >>>
>>> >>> - Wes
>>> >>>
>>> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>> >>> > Did you have any luck going through GitHub's process for reclaiming an
>>> >>> > unused name? You don't necessarily need to contact the account owner for
>>> >>> > this.
>>> >>> > https://help.github.com/articles/name-squatting-policy/
>>> >>> >
>>> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects do
>>> >>> > make
>>> >>> > this quite smooth.
>>> >>> >
>>> >>> > The main reason I switched xarray to pydata (from the separate xray org)
>>> >>> > is
>>> >>> > because I didn't think I would be successful claiming xarray, which
>>> >>> > appears
>>> >>> > to be in active use.
>>> >>> >
>>> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> We've occasionally discussed moving pandas and associated repos to a
>>> >>> >> dedicated GitHub organization.
>>> >>> >>
>>> >>> >> Some arguments for moving to our own org:
>>> >>> >>
>>> >>> >> - More clear what repositories are part of the "pandas" umbrella (we
>>> >>> >> can potentially formalize this in the pandas-governance repo)
>>> >>> >>
>>> >>> >> - Dedicated capacity from CI services
>>> >>> >>
>>> >>> >> - Easier for us to more clearly develop our own open source project
>>> >>> >> branding independent from PyData (which has increasingly primarily
>>> >>> >> become a conference / meetup brand)
>>> >>> >>
>>> >>> >> While I haven't had any success contacting the owner of
>>> >>> >> github.com/pandas, if we can pick a suitable org name we might
>>> >>> >> consider it. GitHub's route forwarding (including git remotes) makes
>>> >>> >> org changes pretty painless these days
>>> >>> >>
>>> >>> >> Thoughts?
>>> >>> >>
>>> >>> >> - Wes
>>> >>> >> _______________________________________________
>>> >>> >> Pandas-dev mailing list
>>> >>> >> Pandas-dev at python.org
>>> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>>> >>> >
>>> >>> >
>>> >>
>>> >>
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>> 
>> 
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
> 
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160905/873e3e02/attachment.html>

From jeffreback at gmail.com  Mon Sep  5 11:48:33 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Mon, 5 Sep 2016 11:48:33 -0400
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <FE34BF07-D355-4B6C-95B3-AE8EA735B838@gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
 <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
 <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>
 <FE34BF07-D355-4B6C-95B3-AE8EA735B838@gmail.com>
Message-ID: <5C08151C-FC74-4031-99A7-A977CED7F977@gmail.com>


I think this would need to wait for the actual 0.19.0 release to be live so it can be announced - lots more folks read the whatsnew that are on the mailing list
also we are changing links in the docs 

> On Sep 5, 2016, at 11:17 AM, Jeff Reback <jeffreback at gmail.com> wrote:
> 
> +1 in this
> 
>> On Sep 5, 2016, at 10:42 AM, Tom Augspurger <tom.augspurger88 at gmail.com> wrote:
>> 
>> I just migrated a repo and it was painless. Is there a reason to wait till after the release candidate?
>> 
>>> On Mon, Sep 5, 2016 at 9:34 AM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
>>> I am positive on a move (although the 'pandas' org would be nice), so OK with going ahead.
>>> 
>>> Joris
>>> 
>>> 2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:
>>>> What does everyone think about going ahead with the move? I imagine
>>>> there are a variety of services (e.g. Travis CI and others) we'll need
>>>> to migrate over concurrently. Want to avoid possible disruptions to
>>>> day-to-day development (luckily GitHub has made this mostly painless
>>>> in my experience).
>>>> 
>>>> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>>> > I've parked github.com/pandas-dev for the time being. Interested to
>>>> > see what others think about the migration
>>>> >
>>>> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>>> >> Too bad about the "pandas" GitHub name. Still, if you want to go for this, I
>>>> >> say you should go ahead.
>>>> >>
>>>> >> My sense (have not checked actual data here) is that all other projects than
>>>> >> pandas add a very minimal amount of CI burden, though.
>>>> >>
>>>> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>>> >>>
>>>> >>> According to GitHub, the pandas account is showing activity that is
>>>> >>> not publicly visible. I've contacted the user twice in an effort to
>>>> >>> start a dialog but GitHub is very strict about protecting users'
>>>> >>> privacy.
>>>> >>>
>>>> >>> We could do something like @pandas-org for the time being, and hope
>>>> >>> that at some point we are able to contact the @pandas user (or they
>>>> >>> become inactive).
>>>> >>>
>>>> >>> - Wes
>>>> >>>
>>>> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>>> >>> > Did you have any luck going through GitHub's process for reclaiming an
>>>> >>> > unused name? You don't necessarily need to contact the account owner for
>>>> >>> > this.
>>>> >>> > https://help.github.com/articles/name-squatting-policy/
>>>> >>> >
>>>> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects do
>>>> >>> > make
>>>> >>> > this quite smooth.
>>>> >>> >
>>>> >>> > The main reason I switched xarray to pydata (from the separate xray org)
>>>> >>> > is
>>>> >>> > because I didn't think I would be successful claiming xarray, which
>>>> >>> > appears
>>>> >>> > to be in active use.
>>>> >>> >
>>>> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com>
>>>> >>> > wrote:
>>>> >>> >>
>>>> >>> >> We've occasionally discussed moving pandas and associated repos to a
>>>> >>> >> dedicated GitHub organization.
>>>> >>> >>
>>>> >>> >> Some arguments for moving to our own org:
>>>> >>> >>
>>>> >>> >> - More clear what repositories are part of the "pandas" umbrella (we
>>>> >>> >> can potentially formalize this in the pandas-governance repo)
>>>> >>> >>
>>>> >>> >> - Dedicated capacity from CI services
>>>> >>> >>
>>>> >>> >> - Easier for us to more clearly develop our own open source project
>>>> >>> >> branding independent from PyData (which has increasingly primarily
>>>> >>> >> become a conference / meetup brand)
>>>> >>> >>
>>>> >>> >> While I haven't had any success contacting the owner of
>>>> >>> >> github.com/pandas, if we can pick a suitable org name we might
>>>> >>> >> consider it. GitHub's route forwarding (including git remotes) makes
>>>> >>> >> org changes pretty painless these days
>>>> >>> >>
>>>> >>> >> Thoughts?
>>>> >>> >>
>>>> >>> >> - Wes
>>>> >>> >> _______________________________________________
>>>> >>> >> Pandas-dev mailing list
>>>> >>> >> Pandas-dev at python.org
>>>> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>>>> >>> >
>>>> >>> >
>>>> >>
>>>> >>
>>>> _______________________________________________
>>>> Pandas-dev mailing list
>>>> Pandas-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>> 
>>> 
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>> 
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160905/bfac467e/attachment-0001.html>

From jeffreback at gmail.com  Tue Sep  6 10:24:22 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Tue, 6 Sep 2016 10:24:22 -0400
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <CALQtMBbYKVTUyL=55j0ygZO+VmcVHqnRYy-TT+oZO4dfFss25Q@mail.gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
 <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
 <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>
 <FE34BF07-D355-4B6C-95B3-AE8EA735B838@gmail.com>
 <5C08151C-FC74-4031-99A7-A977CED7F977@gmail.com>
 <CALQtMBbYKVTUyL=55j0ygZO+VmcVHqnRYy-TT+oZO4dfFss25Q@mail.gmail.com>
Message-ID: <FB8D5BE8-F99E-4435-B627-F6073FD40F0D@gmail.com>

no it was for the announcement and doc changes that matter here
the redirects should be fine


On Sep 6, 2016, at 10:20 AM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
> 
> I am not sure that it has to wait until the actual 0.19.0 release (we can certainly announce it then, but doing the transition earlier does not seem a problem given all redirects. Or Jeff, are you thinking of other problems?). 
> But as Tom suggested, maybe we can wait until after the rc just to prevent possible short-term problems with travis etc that have to be fixed just before the rc.
> 
> Joris
> 
> 2016-09-05 17:48 GMT+02:00 Jeff Reback <jeffreback at gmail.com>:
>> 
>> I think this would need to wait for the actual 0.19.0 release to be live so it can be announced - lots more folks read the whatsnew that are on the mailing list
>> also we are changing links in the docs 
>> 
>>> On Sep 5, 2016, at 11:17 AM, Jeff Reback <jeffreback at gmail.com> wrote:
>>> 
>>> +1 in this
>>> 
>>>> On Sep 5, 2016, at 10:42 AM, Tom Augspurger <tom.augspurger88 at gmail.com> wrote:
>>>> 
>>>> I just migrated a repo and it was painless. Is there a reason to wait till after the release candidate?
>>>> 
>>>>> On Mon, Sep 5, 2016 at 9:34 AM, Joris Van den Bossche <jorisvandenbossche at gmail.com> wrote:
>>>>> I am positive on a move (although the 'pandas' org would be nice), so OK with going ahead.
>>>>> 
>>>>> Joris
>>>>> 
>>>>> 2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:
>>>>>> What does everyone think about going ahead with the move? I imagine
>>>>>> there are a variety of services (e.g. Travis CI and others) we'll need
>>>>>> to migrate over concurrently. Want to avoid possible disruptions to
>>>>>> day-to-day development (luckily GitHub has made this mostly painless
>>>>>> in my experience).
>>>>>> 
>>>>>> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>>>>> > I've parked github.com/pandas-dev for the time being. Interested to
>>>>>> > see what others think about the migration
>>>>>> >
>>>>>> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>>>>> >> Too bad about the "pandas" GitHub name. Still, if you want to go for this, I
>>>>>> >> say you should go ahead.
>>>>>> >>
>>>>>> >> My sense (have not checked actual data here) is that all other projects than
>>>>>> >> pandas add a very minimal amount of CI burden, though.
>>>>>> >>
>>>>>> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> According to GitHub, the pandas account is showing activity that is
>>>>>> >>> not publicly visible. I've contacted the user twice in an effort to
>>>>>> >>> start a dialog but GitHub is very strict about protecting users'
>>>>>> >>> privacy.
>>>>>> >>>
>>>>>> >>> We could do something like @pandas-org for the time being, and hope
>>>>>> >>> that at some point we are able to contact the @pandas user (or they
>>>>>> >>> become inactive).
>>>>>> >>>
>>>>>> >>> - Wes
>>>>>> >>>
>>>>>> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
>>>>>> >>> > Did you have any luck going through GitHub's process for reclaiming an
>>>>>> >>> > unused name? You don't necessarily need to contact the account owner for
>>>>>> >>> > this.
>>>>>> >>> > https://help.github.com/articles/name-squatting-policy/
>>>>>> >>> >
>>>>>> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects do
>>>>>> >>> > make
>>>>>> >>> > this quite smooth.
>>>>>> >>> >
>>>>>> >>> > The main reason I switched xarray to pydata (from the separate xray org)
>>>>>> >>> > is
>>>>>> >>> > because I didn't think I would be successful claiming xarray, which
>>>>>> >>> > appears
>>>>>> >>> > to be in active use.
>>>>>> >>> >
>>>>>> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <wesmckinn at gmail.com>
>>>>>> >>> > wrote:
>>>>>> >>> >>
>>>>>> >>> >> We've occasionally discussed moving pandas and associated repos to a
>>>>>> >>> >> dedicated GitHub organization.
>>>>>> >>> >>
>>>>>> >>> >> Some arguments for moving to our own org:
>>>>>> >>> >>
>>>>>> >>> >> - More clear what repositories are part of the "pandas" umbrella (we
>>>>>> >>> >> can potentially formalize this in the pandas-governance repo)
>>>>>> >>> >>
>>>>>> >>> >> - Dedicated capacity from CI services
>>>>>> >>> >>
>>>>>> >>> >> - Easier for us to more clearly develop our own open source project
>>>>>> >>> >> branding independent from PyData (which has increasingly primarily
>>>>>> >>> >> become a conference / meetup brand)
>>>>>> >>> >>
>>>>>> >>> >> While I haven't had any success contacting the owner of
>>>>>> >>> >> github.com/pandas, if we can pick a suitable org name we might
>>>>>> >>> >> consider it. GitHub's route forwarding (including git remotes) makes
>>>>>> >>> >> org changes pretty painless these days
>>>>>> >>> >>
>>>>>> >>> >> Thoughts?
>>>>>> >>> >>
>>>>>> >>> >> - Wes
>>>>>> >>> >> _______________________________________________
>>>>>> >>> >> Pandas-dev mailing list
>>>>>> >>> >> Pandas-dev at python.org
>>>>>> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>
>>>>>> >>
>>>>>> _______________________________________________
>>>>>> Pandas-dev mailing list
>>>>>> Pandas-dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Pandas-dev mailing list
>>>>> Pandas-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>> 
>>>> _______________________________________________
>>>> Pandas-dev mailing list
>>>> Pandas-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pandas-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160906/ad56c677/attachment.html>

From jorisvandenbossche at gmail.com  Tue Sep  6 10:20:39 2016
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Tue, 6 Sep 2016 16:20:39 +0200
Subject: [Pandas-dev] Our own GitHub organization?
In-Reply-To: <5C08151C-FC74-4031-99A7-A977CED7F977@gmail.com>
References: <CAJPUwMDaPd8S4j2uBKbYQzD5ENOhQSNMa8rzdn2jZ9V-iNNMOg@mail.gmail.com>
 <CAEQ_TveHTjsO+H_1gMTZ=63npA5KD2SW=DKOs4FXMkoM4gCSJQ@mail.gmail.com>
 <CAJPUwMB1PaGZ4+sxvp67ez7ygN=35x8bmiLEC4XbfbpVuNc8nA@mail.gmail.com>
 <CAEQ_TvcgYmYvFOYsyZPOMNbw9_HtDDtBfMfsKHr=+y55oZSzpw@mail.gmail.com>
 <CAJPUwMAfuhcr95Nwq7bdkvK42tGRwkhPeUrWhMQjNMRZUDVbNg@mail.gmail.com>
 <CAJPUwMDP-O2WzGS17LgJMmHbjwYDZN08D4aTM8M=jiKsjVu5OQ@mail.gmail.com>
 <CALQtMBZ7suQmAMxYkxNsVPMJmNjkVcwLy6xj77ddG4cofGhr7A@mail.gmail.com>
 <CAE1aY-mCx_Pi6B=8LvvnRJaWYAMOaGPPgUb4wYgFtCU4Rh_d-A@mail.gmail.com>
 <FE34BF07-D355-4B6C-95B3-AE8EA735B838@gmail.com>
 <5C08151C-FC74-4031-99A7-A977CED7F977@gmail.com>
Message-ID: <CALQtMBbYKVTUyL=55j0ygZO+VmcVHqnRYy-TT+oZO4dfFss25Q@mail.gmail.com>

I am not sure that it has to wait until the actual 0.19.0 release (we can
certainly announce it then, but doing the transition earlier does not seem
a problem given all redirects. Or Jeff, are you thinking of other
problems?).
But as Tom suggested, maybe we can wait until after the rc just to prevent
possible short-term problems with travis etc that have to be fixed just
before the rc.

Joris

2016-09-05 17:48 GMT+02:00 Jeff Reback <jeffreback at gmail.com>:

>
> I think this would need to wait for the actual 0.19.0 release to be live
> so it can be announced - lots more folks read the whatsnew that are on the
> mailing list
> also we are changing links in the docs
>
> On Sep 5, 2016, at 11:17 AM, Jeff Reback <jeffreback at gmail.com> wrote:
>
> +1 in this
>
> On Sep 5, 2016, at 10:42 AM, Tom Augspurger <tom.augspurger88 at gmail.com>
> wrote:
>
> I just migrated a repo and it was painless. Is there a reason to wait till
> after the release candidate?
>
> On Mon, Sep 5, 2016 at 9:34 AM, Joris Van den Bossche <
> jorisvandenbossche at gmail.com> wrote:
>
>> I am positive on a move (although the 'pandas' org would be nice), so OK
>> with going ahead.
>>
>> Joris
>>
>> 2016-09-05 16:04 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:
>>
>>> What does everyone think about going ahead with the move? I imagine
>>> there are a variety of services (e.g. Travis CI and others) we'll need
>>> to migrate over concurrently. Want to avoid possible disruptions to
>>> day-to-day development (luckily GitHub has made this mostly painless
>>> in my experience).
>>>
>>> On Tue, Aug 23, 2016 at 5:42 PM, Wes McKinney <wesmckinn at gmail.com>
>>> wrote:
>>> > I've parked github.com/pandas-dev for the time being. Interested to
>>> > see what others think about the migration
>>> >
>>> > On Tue, Aug 23, 2016 at 12:25 PM, Stephan Hoyer <shoyer at gmail.com>
>>> wrote:
>>> >> Too bad about the "pandas" GitHub name. Still, if you want to go for
>>> this, I
>>> >> say you should go ahead.
>>> >>
>>> >> My sense (have not checked actual data here) is that all other
>>> projects than
>>> >> pandas add a very minimal amount of CI burden, though.
>>> >>
>>> >> On Tue, Aug 23, 2016 at 12:06 PM, Wes McKinney <wesmckinn at gmail.com>
>>> wrote:
>>> >>>
>>> >>> According to GitHub, the pandas account is showing activity that is
>>> >>> not publicly visible. I've contacted the user twice in an effort to
>>> >>> start a dialog but GitHub is very strict about protecting users'
>>> >>> privacy.
>>> >>>
>>> >>> We could do something like @pandas-org for the time being, and hope
>>> >>> that at some point we are able to contact the @pandas user (or they
>>> >>> become inactive).
>>> >>>
>>> >>> - Wes
>>> >>>
>>> >>> On Tue, Aug 23, 2016 at 11:49 AM, Stephan Hoyer <shoyer at gmail.com>
>>> wrote:
>>> >>> > Did you have any luck going through GitHub's process for
>>> reclaiming an
>>> >>> > unused name? You don't necessarily need to contact the account
>>> owner for
>>> >>> > this.
>>> >>> > https://help.github.com/articles/name-squatting-policy/
>>> >>> >
>>> >>> > I'm +1 for switching to a dedicated pandas org. GitHub's redirects
>>> do
>>> >>> > make
>>> >>> > this quite smooth.
>>> >>> >
>>> >>> > The main reason I switched xarray to pydata (from the separate
>>> xray org)
>>> >>> > is
>>> >>> > because I didn't think I would be successful claiming xarray, which
>>> >>> > appears
>>> >>> > to be in active use.
>>> >>> >
>>> >>> > On Tue, Aug 23, 2016 at 11:40 AM, Wes McKinney <
>>> wesmckinn at gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> We've occasionally discussed moving pandas and associated repos
>>> to a
>>> >>> >> dedicated GitHub organization.
>>> >>> >>
>>> >>> >> Some arguments for moving to our own org:
>>> >>> >>
>>> >>> >> - More clear what repositories are part of the "pandas" umbrella
>>> (we
>>> >>> >> can potentially formalize this in the pandas-governance repo)
>>> >>> >>
>>> >>> >> - Dedicated capacity from CI services
>>> >>> >>
>>> >>> >> - Easier for us to more clearly develop our own open source
>>> project
>>> >>> >> branding independent from PyData (which has increasingly primarily
>>> >>> >> become a conference / meetup brand)
>>> >>> >>
>>> >>> >> While I haven't had any success contacting the owner of
>>> >>> >> github.com/pandas, if we can pick a suitable org name we might
>>> >>> >> consider it. GitHub's route forwarding (including git remotes)
>>> makes
>>> >>> >> org changes pretty painless these days
>>> >>> >>
>>> >>> >> Thoughts?
>>> >>> >>
>>> >>> >> - Wes
>>> >>> >> _______________________________________________
>>> >>> >> Pandas-dev mailing list
>>> >>> >> Pandas-dev at python.org
>>> >>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>>> >>> >
>>> >>> >
>>> >>
>>> >>
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>
>>
>>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160906/3c56a69e/attachment-0001.html>

From wesmckinn at gmail.com  Wed Sep  7 14:57:11 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Wed, 7 Sep 2016 14:57:11 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
Message-ID: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>

Since we are close on the 0.19.0 release (thanks Joris for the hard
work!), I wanted to see if we can start assembling a concrete plan for
0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
on the scope of the deprecations or other work desired for these
releases, it would be great ideally to reach 1.0 by Jan 1 or the first
couple months of 2017.

On the pandas 2.0 side, I don't think that the timeline for 0.20 or
1.0 will block progress from beginning. I'd soon like to start
prototyping some of the new designs we've been discussing to get some
concrete feedback on real working code (will create issues on
pydata/pandas-design to track). Once we establish some of the
essential design patterns (i.e. what does an alternative to the
BlockManager look like? How do we handle dynamic / multiple dispatch
based on type?) and feel comfortable with them, more of the "porting"
work can begin.

I think as long as the pandas-2.x branch rebases cleanly for the first
while then there will be no conflict. At some point rebasing may not
be possible and we will need to come up with a backporting policy.

Thanks
Wes

From jorisvandenbossche at gmail.com  Thu Sep  8 06:11:59 2016
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Thu, 8 Sep 2016 12:11:59 +0200
Subject: [Pandas-dev] ANN: pandas v0.19.0rc1 - RELEASE CANDIDATE
Message-ID: <CALQtMBbZGKSWgpg5yYfF9gfiPXn6ssc33-qs76EVk=O5aBsDbg@mail.gmail.com>

Hi,

I'm pleased to announce the availability of the first release candidate of
Pandas 0.19.0. Please try this RC and report any issues at the pandas issue
tracker <https://github.com/pydata/pandas/issues>.

The release candidate can be installed with conda from our development
channel (builds for osx-64, linux-64 and win-64 are available for Python
2.7, 3.4 and 3.5):

conda install -c pandas pandas=0.19.0rc1

or with pip from PyPI <https://pypi.python.org/pypi/pandas/0.19.0rc1>
(wheels are available):

pip install --pre pandas==0.19.0rc1

---
THIS IS NOT A PRODUCTION RELEASE

This is a major release from 0.18.1 and includes a number of API changes,
several new features, enhancements, and performance improvements along with
a large number of bug fixes.

Highlights include:

   - New method merge_asof for asof-style time-series joining, see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-enhancements-asof-merge>
   - The .rolling() method is now time-series aware, see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-enhancements-rolling-ts>
   - read_csv now supports parsing Categorical data, see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-enhancements-read-csv-categorical>
   - A function union_categorical has been added for combining
   categoricals, see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-enhancements-union-categoricals>
   - PeriodIndex now has its own period dtype, and changed to be more
   consistent with other Index classes. See here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-api-period>
   - Sparse data structures gained enhanced support of int and bool dtypes,
   see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-sparse>
   - Comparison operations with Series no longer ignores the index, see here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-api-series-ops>
   for an overview of the API changes.
   - Introduction of a pandas development API for utility functions, see
   here
   <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0190-dev-api>
   .
   - Deprecation of Panel4D and PanelND. We recommend to represent these
   types of n-dimensional data with the xarray package
   <http://xarray.pydata.org/en/stable/>.
   - Removal of the previously deprecated modules pandas.io.data,
   pandas.io.wb, pandas.tools.rplot.

See the Whatsnew
<http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html> file for
more information. Please report any issues here
<https://github.com/pydata/pandas/issues/>.

A big thanks to all contributors!

Joris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160908/1ec072b1/attachment.html>

From wesmckinn at gmail.com  Tue Sep 13 09:51:04 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Tue, 13 Sep 2016 09:51:04 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
Message-ID: <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>

hi folks,

Bumping this thread. At minimum we should start discussing what we may
want to deprecate (e.g. Panels, .ix) in the next major release.

- Wes

On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> Since we are close on the 0.19.0 release (thanks Joris for the hard
> work!), I wanted to see if we can start assembling a concrete plan for
> 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
> on the scope of the deprecations or other work desired for these
> releases, it would be great ideally to reach 1.0 by Jan 1 or the first
> couple months of 2017.
>
> On the pandas 2.0 side, I don't think that the timeline for 0.20 or
> 1.0 will block progress from beginning. I'd soon like to start
> prototyping some of the new designs we've been discussing to get some
> concrete feedback on real working code (will create issues on
> pydata/pandas-design to track). Once we establish some of the
> essential design patterns (i.e. what does an alternative to the
> BlockManager look like? How do we handle dynamic / multiple dispatch
> based on type?) and feel comfortable with them, more of the "porting"
> work can begin.
>
> I think as long as the pandas-2.x branch rebases cleanly for the first
> while then there will be no conflict. At some point rebasing may not
> be possible and we will need to come up with a backporting policy.
>
> Thanks
> Wes

From jeffreback at gmail.com  Tue Sep 13 17:26:39 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Tue, 13 Sep 2016 17:26:39 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
Message-ID: <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>

So here's what I am thinking.

We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
approx 3 months ('regular' major release). The difference here is we can
limit new additions to this release (prob just period dtype?) and do major
deprecation removal https://github.com/pydata/pandas/issues/13777 / add
anything else (e.g. Panel/.ix) deprecations.

Then we turn around and do a 1.0 say 1 month after that, which is the api
stable release.

So then the 1.x / LTS can continue with the following categories:

- bug fixes
- perf improvements
- deprecation removals (hate to do it, but we have to)
- minor / limited deprecations
- limited new enhancements

So mostly continue the usual pattern. Maybe with a higher hurdle for
introducing changes that are potentially disruptive. E.g. would we accept
Interval/IntervalIndex for example. This should have a new dtype. (that's
why I am picking on it).

I am promoting a pattern like this to avoid the pitfall of: 'hey pandas is
in LTS / stable, so we won't contribute any more, its just bug fixes' issue.

Jeff

On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com> wrote:

> hi folks,
>
> Bumping this thread. At minimum we should start discussing what we may
> want to deprecate (e.g. Panels, .ix) in the next major release.
>
> - Wes
>
> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> > Since we are close on the 0.19.0 release (thanks Joris for the hard
> > work!), I wanted to see if we can start assembling a concrete plan for
> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
> > on the scope of the deprecations or other work desired for these
> > releases, it would be great ideally to reach 1.0 by Jan 1 or the first
> > couple months of 2017.
> >
> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
> > 1.0 will block progress from beginning. I'd soon like to start
> > prototyping some of the new designs we've been discussing to get some
> > concrete feedback on real working code (will create issues on
> > pydata/pandas-design to track). Once we establish some of the
> > essential design patterns (i.e. what does an alternative to the
> > BlockManager look like? How do we handle dynamic / multiple dispatch
> > based on type?) and feel comfortable with them, more of the "porting"
> > work can begin.
> >
> > I think as long as the pandas-2.x branch rebases cleanly for the first
> > while then there will be no conflict. At some point rebasing may not
> > be possible and we will need to come up with a backporting policy.
> >
> > Thanks
> > Wes
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160913/76084360/attachment.html>

From jeffreback at gmail.com  Tue Sep 13 17:29:26 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Tue, 13 Sep 2016 17:29:26 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
 <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>
Message-ID: <CAHMnJKgR2Pt8T=Bn+K-g6MaqYLNdbHT_KWwRydbVV1y5GbMHHA@mail.gmail.com>

Oh and this means that we would do very very limited bug fixes on
deprecated things (e.g. Panel / .ix); which for the most part are stale
(IOW, not being worked on). I am going to create a milestone for things
like this.

Further, the issue of *when* to remove Panel/.ix entirely is an open
question, is this 1.x, or 2.0?

On Tue, Sep 13, 2016 at 5:26 PM, Jeff Reback <jeffreback at gmail.com> wrote:

> So here's what I am thinking.
>
> We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
> approx 3 months ('regular' major release). The difference here is we can
> limit new additions to this release (prob just period dtype?) and do major
> deprecation removal https://github.com/pydata/pandas/issues/13777 / add
> anything else (e.g. Panel/.ix) deprecations.
>
> Then we turn around and do a 1.0 say 1 month after that, which is the api
> stable release.
>
> So then the 1.x / LTS can continue with the following categories:
>
> - bug fixes
> - perf improvements
> - deprecation removals (hate to do it, but we have to)
> - minor / limited deprecations
> - limited new enhancements
>
> So mostly continue the usual pattern. Maybe with a higher hurdle for
> introducing changes that are potentially disruptive. E.g. would we accept
> Interval/IntervalIndex for example. This should have a new dtype. (that's
> why I am picking on it).
>
> I am promoting a pattern like this to avoid the pitfall of: 'hey pandas is
> in LTS / stable, so we won't contribute any more, its just bug fixes' issue.
>
> Jeff
>
> On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com> wrote:
>
>> hi folks,
>>
>> Bumping this thread. At minimum we should start discussing what we may
>> want to deprecate (e.g. Panels, .ix) in the next major release.
>>
>> - Wes
>>
>> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>> > Since we are close on the 0.19.0 release (thanks Joris for the hard
>> > work!), I wanted to see if we can start assembling a concrete plan for
>> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
>> > on the scope of the deprecations or other work desired for these
>> > releases, it would be great ideally to reach 1.0 by Jan 1 or the first
>> > couple months of 2017.
>> >
>> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
>> > 1.0 will block progress from beginning. I'd soon like to start
>> > prototyping some of the new designs we've been discussing to get some
>> > concrete feedback on real working code (will create issues on
>> > pydata/pandas-design to track). Once we establish some of the
>> > essential design patterns (i.e. what does an alternative to the
>> > BlockManager look like? How do we handle dynamic / multiple dispatch
>> > based on type?) and feel comfortable with them, more of the "porting"
>> > work can begin.
>> >
>> > I think as long as the pandas-2.x branch rebases cleanly for the first
>> > while then there will be no conflict. At some point rebasing may not
>> > be possible and we will need to come up with a backporting policy.
>> >
>> > Thanks
>> > Wes
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160913/eb034e5b/attachment.html>

From jeffreback at gmail.com  Tue Sep 13 17:37:43 2016
From: jeffreback at gmail.com (Jeff Reback)
Date: Tue, 13 Sep 2016 17:37:43 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAHMnJKgR2Pt8T=Bn+K-g6MaqYLNdbHT_KWwRydbVV1y5GbMHHA@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
 <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>
 <CAHMnJKgR2Pt8T=Bn+K-g6MaqYLNdbHT_KWwRydbVV1y5GbMHHA@mail.gmail.com>
Message-ID: <CAHMnJKgXjgAMQaYDWKpRNMAtD_ahG+ZqXfHA=Vf-1tDcnORFTw@mail.gmail.com>

typo on the deprecation issue, really should be:
https://github.com/pydata/pandas/issues/6581

IOW deprecations that need to be removed.

On Tue, Sep 13, 2016 at 5:29 PM, Jeff Reback <jeffreback at gmail.com> wrote:

> Oh and this means that we would do very very limited bug fixes on
> deprecated things (e.g. Panel / .ix); which for the most part are stale
> (IOW, not being worked on). I am going to create a milestone for things
> like this.
>
> Further, the issue of *when* to remove Panel/.ix entirely is an open
> question, is this 1.x, or 2.0?
>
> On Tue, Sep 13, 2016 at 5:26 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>
>> So here's what I am thinking.
>>
>> We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
>> approx 3 months ('regular' major release). The difference here is we can
>> limit new additions to this release (prob just period dtype?) and do major
>> deprecation removal https://github.com/pydata/pandas/issues/13777 / add
>> anything else (e.g. Panel/.ix) deprecations.
>>
>> Then we turn around and do a 1.0 say 1 month after that, which is the api
>> stable release.
>>
>> So then the 1.x / LTS can continue with the following categories:
>>
>> - bug fixes
>> - perf improvements
>> - deprecation removals (hate to do it, but we have to)
>> - minor / limited deprecations
>> - limited new enhancements
>>
>> So mostly continue the usual pattern. Maybe with a higher hurdle for
>> introducing changes that are potentially disruptive. E.g. would we accept
>> Interval/IntervalIndex for example. This should have a new dtype. (that's
>> why I am picking on it).
>>
>> I am promoting a pattern like this to avoid the pitfall of: 'hey pandas
>> is in LTS / stable, so we won't contribute any more, its just bug fixes'
>> issue.
>>
>> Jeff
>>
>> On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com>
>> wrote:
>>
>>> hi folks,
>>>
>>> Bumping this thread. At minimum we should start discussing what we may
>>> want to deprecate (e.g. Panels, .ix) in the next major release.
>>>
>>> - Wes
>>>
>>> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com>
>>> wrote:
>>> > Since we are close on the 0.19.0 release (thanks Joris for the hard
>>> > work!), I wanted to see if we can start assembling a concrete plan for
>>> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
>>> > on the scope of the deprecations or other work desired for these
>>> > releases, it would be great ideally to reach 1.0 by Jan 1 or the first
>>> > couple months of 2017.
>>> >
>>> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
>>> > 1.0 will block progress from beginning. I'd soon like to start
>>> > prototyping some of the new designs we've been discussing to get some
>>> > concrete feedback on real working code (will create issues on
>>> > pydata/pandas-design to track). Once we establish some of the
>>> > essential design patterns (i.e. what does an alternative to the
>>> > BlockManager look like? How do we handle dynamic / multiple dispatch
>>> > based on type?) and feel comfortable with them, more of the "porting"
>>> > work can begin.
>>> >
>>> > I think as long as the pandas-2.x branch rebases cleanly for the first
>>> > while then there will be no conflict. At some point rebasing may not
>>> > be possible and we will need to come up with a backporting policy.
>>> >
>>> > Thanks
>>> > Wes
>>> _______________________________________________
>>> Pandas-dev mailing list
>>> Pandas-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160913/c58b17ec/attachment-0001.html>

From tom.augspurger88 at gmail.com  Tue Sep 13 22:07:40 2016
From: tom.augspurger88 at gmail.com (Tom Augspurger)
Date: Tue, 13 Sep 2016 21:07:40 -0500
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAHMnJKgXjgAMQaYDWKpRNMAtD_ahG+ZqXfHA=Vf-1tDcnORFTw@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
 <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>
 <CAHMnJKgR2Pt8T=Bn+K-g6MaqYLNdbHT_KWwRydbVV1y5GbMHHA@mail.gmail.com>
 <CAHMnJKgXjgAMQaYDWKpRNMAtD_ahG+ZqXfHA=Vf-1tDcnORFTw@mail.gmail.com>
Message-ID: <CAE1aY-=bT7O9jk4Xpmra88j5uY+my8V5cpn2D=9dzw0Jd2iC_w@mail.gmail.com>

On Tue, Sep 13, 2016 at 4:37 PM, Jeff Reback <jeffreback at gmail.com> wrote:

> typo on the deprecation issue, really should be:
> https://github.com/pydata/pandas/issues/6581
>
> IOW deprecations that need to be removed.
>
> On Tue, Sep 13, 2016 at 5:29 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>
>> Oh and this means that we would do very very limited bug fixes on
>> deprecated things (e.g. Panel / .ix); which for the most part are stale
>> (IOW, not being worked on). I am going to create a milestone for things
>> like this.
>>
>> Further, the issue of *when* to remove Panel/.ix entirely is an open
>> question, is this 1.x, or 2.0?
>>
> On Tue, Sep 13, 2016 at 5:26 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>>
>>> So here's what I am thinking.
>>>
>>> We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
>>> approx 3 months ('regular' major release). The difference here is we can
>>> limit new additions to this release (prob just period dtype?) and do major
>>> deprecation removal https://github.com/pydata/pandas/issues/13777 / add
>>> anything else (e.g. Panel/.ix) deprecations.
>>>
>>> Then we turn around and do a 1.0 say 1 month after that, which is the
>>> api stable release.
>>>
>>> So then the 1.x / LTS can continue with the following categories:
>>>
>>> - bug fixes
>>> - perf improvements
>>> - deprecation removals (hate to do it, but we have to)
>>> - minor / limited deprecations
>>> - limited new enhancements
>>>
>>> So mostly continue the usual pattern. Maybe with a higher hurdle for
>>> introducing changes that are potentially disruptive. E.g. would we accept
>>> Interval/IntervalIndex for example. This should have a new dtype. (that's
>>> why I am picking on it).
>>>
>>> I am promoting a pattern like this to avoid the pitfall of: 'hey pandas
>>> is in LTS / stable, so we won't contribute any more, its just bug fixes'
>>> issue.
>>>
>>
This all sounds good. The important point is we should only hold off on
things, enhancements *or bugfixes*, because they get too deep into the
internals,
not just because they're an enhancement.


> Jeff
>>>
>>> On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com>
>>> wrote:
>>>
>>>> hi folks,
>>>>
>>>> Bumping this thread. At minimum we should start discussing what we may
>>>> want to deprecate (e.g. Panels, .ix) in the next major release.
>>>
>>>
I think deprecating ix and Panel in 0.20, is OK, as long as we 1.) make it
clear that they're being removed in 2.0, but around for all of 1.x LTS,
and 2.) provide an option to silence them. I don't feel strongly about this
though.


>
>>>> - Wes
>>>>
>>>> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com>
>>>> wrote:
>>>> > Since we are close on the 0.19.0 release (thanks Joris for the hard
>>>> > work!), I wanted to see if we can start assembling a concrete plan for
>>>> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
>>>> > on the scope of the deprecations or other work desired for these
>>>> > releases, it would be great ideally to reach 1.0 by Jan 1 or the first
>>>> > couple months of 2017.
>>>> >
>>>> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
>>>> > 1.0 will block progress from beginning. I'd soon like to start
>>>> > prototyping some of the new designs we've been discussing to get some
>>>> > concrete feedback on real working code (will create issues on
>>>> > pydata/pandas-design to track). Once we establish some of the
>>>> > essential design patterns (i.e. what does an alternative to the
>>>> > BlockManager look like? How do we handle dynamic / multiple dispatch
>>>> > based on type?) and feel comfortable with them, more of the "porting"
>>>> > work can begin.
>>>> >
>>>> > I think as long as the pandas-2.x branch rebases cleanly for the first
>>>> > while then there will be no conflict. At some point rebasing may not
>>>> > be possible and we will need to come up with a backporting policy.
>>>> >
>>>> > Thanks
>>>> > Wes
>>>> _______________________________________________
>>>> Pandas-dev mailing list
>>>> Pandas-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>>
>>>
>>>
>>
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160913/e00bea7f/attachment.html>

From wesmckinn at gmail.com  Tue Sep 13 22:49:35 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Tue, 13 Sep 2016 22:49:35 -0400
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAE1aY-=bT7O9jk4Xpmra88j5uY+my8V5cpn2D=9dzw0Jd2iC_w@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
 <CAHMnJKgm0R4=RE-Wgv-s01t+G-LU2mfuQC0azqkFrFgW_7eWsw@mail.gmail.com>
 <CAHMnJKgR2Pt8T=Bn+K-g6MaqYLNdbHT_KWwRydbVV1y5GbMHHA@mail.gmail.com>
 <CAHMnJKgXjgAMQaYDWKpRNMAtD_ahG+ZqXfHA=Vf-1tDcnORFTw@mail.gmail.com>
 <CAE1aY-=bT7O9jk4Xpmra88j5uY+my8V5cpn2D=9dzw0Jd2iC_w@mail.gmail.com>
Message-ID: <CAJPUwMCJ9XnD7i-eOc1CMcYJdX8jeVNyQrspD+-MJBijmK5CBA@mail.gmail.com>

On Tue, Sep 13, 2016 at 10:07 PM, Tom Augspurger
<tom.augspurger88 at gmail.com> wrote:
>
> On Tue, Sep 13, 2016 at 4:37 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>>
>> typo on the deprecation issue, really should be:
>> https://github.com/pydata/pandas/issues/6581
>>
>> IOW deprecations that need to be removed.
>>
>> On Tue, Sep 13, 2016 at 5:29 PM, Jeff Reback <jeffreback at gmail.com> wrote:
>>>
>>> Oh and this means that we would do very very limited bug fixes on
>>> deprecated things (e.g. Panel / .ix); which for the most part are stale
>>> (IOW, not being worked on). I am going to create a milestone for things like
>>> this.
>>>
>>> Further, the issue of *when* to remove Panel/.ix entirely is an open
>>> question, is this 1.x, or 2.0?
>>>
>>> On Tue, Sep 13, 2016 at 5:26 PM, Jeff Reback <jeffreback at gmail.com>
>>> wrote:
>>>>
>>>> So here's what I am thinking.
>>>>
>>>> We need a bug fix release (0.19.1) say 1 month. Then we need a 0.20.0 in
>>>> approx 3 months ('regular' major release). The difference here is we can
>>>> limit new additions to this release (prob just period dtype?) and do major
>>>> deprecation removal https://github.com/pydata/pandas/issues/13777 / add
>>>> anything else (e.g. Panel/.ix) deprecations.
>>>>
>>>> Then we turn around and do a 1.0 say 1 month after that, which is the
>>>> api stable release.
>>>>
>>>> So then the 1.x / LTS can continue with the following categories:
>>>>
>>>> - bug fixes
>>>> - perf improvements
>>>> - deprecation removals (hate to do it, but we have to)
>>>> - minor / limited deprecations
>>>> - limited new enhancements
>>>>
>>>> So mostly continue the usual pattern. Maybe with a higher hurdle for
>>>> introducing changes that are potentially disruptive. E.g. would we accept
>>>> Interval/IntervalIndex for example. This should have a new dtype. (that's
>>>> why I am picking on it).
>>>>
>>>> I am promoting a pattern like this to avoid the pitfall of: 'hey pandas
>>>> is in LTS / stable, so we won't contribute any more, its just bug fixes'
>>>> issue.
>
>
> This all sounds good. The important point is we should only hold off on
> things, enhancements *or bugfixes*, because they get too deep into the
> internals,
> not just because they're an enhancement.
>

I think the watershed will be "does it rebase cleanly?". At least for
a while the pandas 2.0 branch (once we get going) won't be in conflict
but at some point rebasing will become more difficult. We'll have to
make best efforts to avoid the conflict for as long as possible. I
think this is OK, because the "new DataFrame internals" is a large and
fairly independent effort in the early stages, so the refactor to
change things out will happen somewhat late in the process after the
essential features and behavior have been implemented.

>>>>
>>>> Jeff
>>>>
>>>> On Tue, Sep 13, 2016 at 9:51 AM, Wes McKinney <wesmckinn at gmail.com>
>>>> wrote:
>>>>>
>>>>> hi folks,
>>>>>
>>>>> Bumping this thread. At minimum we should start discussing what we may
>>>>> want to deprecate (e.g. Panels, .ix) in the next major release.
>
>
> I think deprecating ix and Panel in 0.20, is OK, as long as we 1.) make it
> clear that they're being removed in 2.0, but around for all of 1.x LTS,
> and 2.) provide an option to silence them. I don't feel strongly about this
> though.
>
>>>>>
>>>>>
>>>>> - Wes
>>>>>
>>>>> On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com>
>>>>> wrote:
>>>>> > Since we are close on the 0.19.0 release (thanks Joris for the hard
>>>>> > work!), I wanted to see if we can start assembling a concrete plan
>>>>> > for
>>>>> > 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending
>>>>> > on the scope of the deprecations or other work desired for these
>>>>> > releases, it would be great ideally to reach 1.0 by Jan 1 or the
>>>>> > first
>>>>> > couple months of 2017.
>>>>> >
>>>>> > On the pandas 2.0 side, I don't think that the timeline for 0.20 or
>>>>> > 1.0 will block progress from beginning. I'd soon like to start
>>>>> > prototyping some of the new designs we've been discussing to get some
>>>>> > concrete feedback on real working code (will create issues on
>>>>> > pydata/pandas-design to track). Once we establish some of the
>>>>> > essential design patterns (i.e. what does an alternative to the
>>>>> > BlockManager look like? How do we handle dynamic / multiple dispatch
>>>>> > based on type?) and feel comfortable with them, more of the "porting"
>>>>> > work can begin.
>>>>> >
>>>>> > I think as long as the pandas-2.x branch rebases cleanly for the
>>>>> > first
>>>>> > while then there will be no conflict. At some point rebasing may not
>>>>> > be possible and we will need to come up with a backporting policy.
>>>>> >
>>>>> > Thanks
>>>>> > Wes
>>>>> _______________________________________________
>>>>> Pandas-dev mailing list
>>>>> Pandas-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pandas-dev
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
>>
>
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>

From Christopher.Aycock at twosigma.com  Tue Sep 13 09:59:14 2016
From: Christopher.Aycock at twosigma.com (Christopher Aycock)
Date: Tue, 13 Sep 2016 13:59:14 +0000
Subject: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?
In-Reply-To: <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
References: <CAJPUwMBxnhbKW_kD4HWgESLE42MjsH_OpEbA+KGJuzVE7DWkNQ@mail.gmail.com>
 <CAJPUwMABd4ZFLoFnzNvr73SdLJqo7+enJug+VZtsZOr036TRcQ@mail.gmail.com>
Message-ID: <5fb29046aa0543129c0e54fd0f53fd37@EXMBNJE8.ad.twosigma.com>

I'd honestly like to see some way of getting rid of DataFrame indices. They confuse beginners and aren't used much by experts. There was a proposal for a Table type, which I think is a great way to go forward. That means that many operations must be able to work without an index.

-----Original Message-----
From: Pandas-dev [mailto:pandas-dev-bounces+christopher.aycock=twosigma.com at python.org] On Behalf Of Wes McKinney
Sent: Tuesday, September 13, 2016 9:51 AM
To: pandas-dev at python.org
Subject: Re: [Pandas-dev] 0.20 and 1.0 timeline, 2.x interactions?

hi folks,

Bumping this thread. At minimum we should start discussing what we may want to deprecate (e.g. Panels, .ix) in the next major release.

- Wes

On Wed, Sep 7, 2016 at 2:57 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> Since we are close on the 0.19.0 release (thanks Joris for the hard 
> work!), I wanted to see if we can start assembling a concrete plan for
> 0.20 and/or 1.0 (API-stability / maintenance branch begin). Depending 
> on the scope of the deprecations or other work desired for these 
> releases, it would be great ideally to reach 1.0 by Jan 1 or the first 
> couple months of 2017.
>
> On the pandas 2.0 side, I don't think that the timeline for 0.20 or
> 1.0 will block progress from beginning. I'd soon like to start 
> prototyping some of the new designs we've been discussing to get some 
> concrete feedback on real working code (will create issues on 
> pydata/pandas-design to track). Once we establish some of the 
> essential design patterns (i.e. what does an alternative to the 
> BlockManager look like? How do we handle dynamic / multiple dispatch 
> based on type?) and feel comfortable with them, more of the "porting"
> work can begin.
>
> I think as long as the pandas-2.x branch rebases cleanly for the first 
> while then there will be no conflict. At some point rebasing may not 
> be possible and we will need to come up with a backporting policy.
>
> Thanks
> Wes
_______________________________________________
Pandas-dev mailing list
Pandas-dev at python.org
https://mail.python.org/mailman/listinfo/pandas-dev

From Christopher.Aycock at twosigma.com  Wed Sep 14 14:47:24 2016
From: Christopher.Aycock at twosigma.com (Christopher Aycock)
Date: Wed, 14 Sep 2016 18:47:24 +0000
Subject: [Pandas-dev] GitHub's new code-review tools
Message-ID: <8bde15e396554b679df7d786dcd71a64@EXMBNJE8.ad.twosigma.com>

Hot off the presses, GitHub has more robust code-review tools:

https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features

Do these features help at all with the current problems reviewers have been having?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160914/a14fef0b/attachment.html>

From wesmckinn at gmail.com  Wed Sep 14 23:24:21 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Wed, 14 Sep 2016 23:24:21 -0400
Subject: [Pandas-dev] GitHub's new code-review tools
In-Reply-To: <8bde15e396554b679df7d786dcd71a64@EXMBNJE8.ad.twosigma.com>
References: <8bde15e396554b679df7d786dcd71a64@EXMBNJE8.ad.twosigma.com>
Message-ID: <CAJPUwMBZSPHToa7QT4tjbTPBy1Lg+oLCTHzt=k7eSmr78_eJyA@mail.gmail.com>

This helps by reducing some of the e-mail chatter / grouping together
sets of comments.

Biggest outstanding weakness I see versus other tools (e.g. Gerrit) is
that it does not seem to support reviews of incremental changes to the
PR. More mature review tools allow you to see how each comment was
addressed in the incremental patch. On larger / more complex patches,
reviews may go through several rounds of incremental changes. Multiple
times in the last year I've had to make 3 or more careful passes
through patches over 1000 lines. You can leave comments on individual
commits, but that presumes that each commit is meaningful (this is
distinct from the notion of patch sets -- transactional changes to the
patch -- used in Rietveld, Gerrit, etc.)

To give you a concrete example, I participated in this code review
earlier this year which went through 17 patch sets:

https://gerrit.cloudera.org/#/c/2645/

Here's an example of an incremental diff; this shows comments between
patch sets 15 and 16 and how the comments were addressed:

https://gerrit.cloudera.org/#/c/2645/15..16/src/hs2client/operation.cc

I continue to worry that GitHub makes it too tempting to just rubber
stamp larger PRs or leave less detailed / more superficial commentary.

(for historical commentary on the origin of these review tools:
https://en.wikipedia.org/wiki/Rietveld_(software) )

- Wes

On Wed, Sep 14, 2016 at 2:47 PM, Christopher Aycock
<Christopher.Aycock at twosigma.com> wrote:
> Hot off the presses, GitHub has more robust code-review tools:
>
>
>
> https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features
>
>
>
> Do these features help at all with the current problems reviewers have been
> having?
>
>
>
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>

From shoyer at gmail.com  Thu Sep 15 11:54:06 2016
From: shoyer at gmail.com (Stephan Hoyer)
Date: Thu, 15 Sep 2016 15:54:06 +0000
Subject: [Pandas-dev] GitHub's new code-review tools
In-Reply-To: <CAJPUwMBZSPHToa7QT4tjbTPBy1Lg+oLCTHzt=k7eSmr78_eJyA@mail.gmail.com>
References: <8bde15e396554b679df7d786dcd71a64@EXMBNJE8.ad.twosigma.com>
 <CAJPUwMBZSPHToa7QT4tjbTPBy1Lg+oLCTHzt=k7eSmr78_eJyA@mail.gmail.com>
Message-ID: <CAEQ_Tvc_m_24zvLOA4v7cLGYMBx_KmEM=MHuLO=AFpEQ9xHPBQ@mail.gmail.com>

Agreed -- github isn't quite there yet. But they do seem to be making
steady progress in the right direction. I am cautiously optimistic that an
incremental diff tool like this is in the works (no idea on the timeline,
of course). It has to be one of the largest blockers they hear from
prospective enterprise customers.
On Wed, Sep 14, 2016 at 8:25 PM Wes McKinney <wesmckinn at gmail.com> wrote:

> This helps by reducing some of the e-mail chatter / grouping together
> sets of comments.
>
> Biggest outstanding weakness I see versus other tools (e.g. Gerrit) is
> that it does not seem to support reviews of incremental changes to the
> PR. More mature review tools allow you to see how each comment was
> addressed in the incremental patch. On larger / more complex patches,
> reviews may go through several rounds of incremental changes. Multiple
> times in the last year I've had to make 3 or more careful passes
> through patches over 1000 lines. You can leave comments on individual
> commits, but that presumes that each commit is meaningful (this is
> distinct from the notion of patch sets -- transactional changes to the
> patch -- used in Rietveld, Gerrit, etc.)
>
> To give you a concrete example, I participated in this code review
> earlier this year which went through 17 patch sets:
>
> https://gerrit.cloudera.org/#/c/2645/
>
> Here's an example of an incremental diff; this shows comments between
> patch sets 15 and 16 and how the comments were addressed:
>
> https://gerrit.cloudera.org/#/c/2645/15..16/src/hs2client/operation.cc
>
> I continue to worry that GitHub makes it too tempting to just rubber
> stamp larger PRs or leave less detailed / more superficial commentary.
>
> (for historical commentary on the origin of these review tools:
> https://en.wikipedia.org/wiki/Rietveld_(software) )
>
> - Wes
>
> On Wed, Sep 14, 2016 at 2:47 PM, Christopher Aycock
> <Christopher.Aycock at twosigma.com> wrote:
> > Hot off the presses, GitHub has more robust code-review tools:
> >
> >
> >
> >
> https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features
> >
> >
> >
> > Do these features help at all with the current problems reviewers have
> been
> > having?
> >
> >
> >
> >
> > _______________________________________________
> > Pandas-dev mailing list
> > Pandas-dev at python.org
> > https://mail.python.org/mailman/listinfo/pandas-dev
> >
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160915/0539805c/attachment.html>

From jorisvandenbossche at gmail.com  Thu Sep 15 18:38:36 2016
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Fri, 16 Sep 2016 00:38:36 +0200
Subject: [Pandas-dev] welcome Chris Bartak to the core team
Message-ID: <CALQtMBZfHcLWXWjArX7Gi3PvP2H0T5KVTUPqL=SKJ0wUSRHT4Q@mail.gmail.com>

Hi all,

We would like to welcome Chris Bartak (@chris-b1) as new member of the core
dev team of pandas.

Chris has been contributing for more than a year with nice PRs and helpful
reviews and comments. Thanks for all those contributions, and looking
forward to your continued involvement!

Great to have you on board!

Regards,
Joris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160916/4c26ee8f/attachment.html>

From wesmckinn at gmail.com  Thu Sep 15 22:44:52 2016
From: wesmckinn at gmail.com (Wes McKinney)
Date: Thu, 15 Sep 2016 22:44:52 -0400
Subject: [Pandas-dev] welcome Chris Bartak to the core team
In-Reply-To: <CALQtMBZfHcLWXWjArX7Gi3PvP2H0T5KVTUPqL=SKJ0wUSRHT4Q@mail.gmail.com>
References: <CALQtMBZfHcLWXWjArX7Gi3PvP2H0T5KVTUPqL=SKJ0wUSRHT4Q@mail.gmail.com>
Message-ID: <CAJPUwMAe-K8ZTEeEkEQ=mt2AN2SrFo6MvFTi98YA0Zjb3kccUw@mail.gmail.com>

Congrats Chris and welcome! Thank you for all the hard work on the project.

On Thu, Sep 15, 2016 at 6:38 PM, Joris Van den Bossche
<jorisvandenbossche at gmail.com> wrote:
> Hi all,
>
> We would like to welcome Chris Bartak (@chris-b1) as new member of the core
> dev team of pandas.
>
> Chris has been contributing for more than a year with nice PRs and helpful
> reviews and comments. Thanks for all those contributions, and looking
> forward to your continued involvement!
>
> Great to have you on board!
>
> Regards,
> Joris
>
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>

From sinhrks at gmail.com  Sat Sep 17 07:01:47 2016
From: sinhrks at gmail.com (Sin Hrks)
Date: Sat, 17 Sep 2016 20:01:47 +0900
Subject: [Pandas-dev] welcome Chris Bartak to the core team
In-Reply-To: <CAJPUwMAe-K8ZTEeEkEQ=mt2AN2SrFo6MvFTi98YA0Zjb3kccUw@mail.gmail.com>
References: <CALQtMBZfHcLWXWjArX7Gi3PvP2H0T5KVTUPqL=SKJ0wUSRHT4Q@mail.gmail.com>
 <CAJPUwMAe-K8ZTEeEkEQ=mt2AN2SrFo6MvFTi98YA0Zjb3kccUw@mail.gmail.com>
Message-ID: <7B5941A7-96A7-4F76-992C-23DFB4DA588B@gmail.com>

Welcome Chris, your contributions are really fantastic!

Masaaki Horikoshi (sinhrks)

> On Sep 16, 2016, at 11:44 AM, Wes McKinney <wesmckinn at gmail.com> wrote:
> 
> Congrats Chris and welcome! Thank you for all the hard work on the project.
> 
> On Thu, Sep 15, 2016 at 6:38 PM, Joris Van den Bossche
> <jorisvandenbossche at gmail.com> wrote:
>> Hi all,
>> 
>> We would like to welcome Chris Bartak (@chris-b1) as new member of the core
>> dev team of pandas.
>> 
>> Chris has been contributing for more than a year with nice PRs and helpful
>> reviews and comments. Thanks for all those contributions, and looking
>> forward to your continued involvement!
>> 
>> Great to have you on board!
>> 
>> Regards,
>> Joris
>> 
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev