0.7, 0.8 and what's up

[josef...@gmail.com]

After having some fun again with writing new code for a while, I returned back to maintenance.

First, time based releases without having someone to do the release or having the infrastructure that does the release almost automatically doesn't work.

I have been holding new PRs away from master since winter and it makes our continuing development quite difficult. So I would like to open master for 0.8 developement very soon. 

I spent a few days preparing and merging bugfixes that were submitted in the last few months. There is still a bit left that should be included before tagging 0.7.

for 0.8:

current count 89 open PRs, 

There are several PRs that are almost ready to merge and have been on hold (or ignored for several months, I'm sorry about this).

One of the current big issue is penalized estimation with one GSOC project and PRs by Kerby and me that need to be merged soon to consolidate and share code before we can finish up this round of new features.

Several other new features are work in progress and partially need common refactoring that should also be in master.

We have 4 GSOC projects which will have PRs that should be merged during summer or in Fall.

And then we have several older large PRs (to merge or not to merge - donkey with two haystacks)

I really don't like it that we have many old PRs with good but outdated and unfinished code waiting for some help and for merging. 

We have two options (the 3rd option, finishing up, ain't happening yet):

- keep them out, until a volunteer volunteers, or

- "dump" them into master

I would be in favor on merging them as unfinished, so they stay updated with refactorings, so it's easier to use the functioning parts and so the barrier is lower to make "digestible" improvements.

I would be in favor of keeping them out, because someone might use them without paying attention to a "unfinished" warning and catch some bugs.

cases: Panel data, survival, system of equations, tobit, robust estimators, nonlinear least squares and a few more.

preliminary date for 0.8 (assuming release infrastructure is available) late fall or early winter, not time based but based on what will happen until then.

As a general note: 

Master is (almost) always release ready and trustworthy except for the latest models, features and enhancements. I'm usually very conservative in merging changes that affect commonly used and established code, but the API and implementation of new features can take some time until they settle and become established and subject to backwards compatibility restrictions.

Bugs and behavior in corner cases are not replicable within a release cycle.and across version.

Josef

[Ralf Gommers]

On Tue, Jun 30, 2015 at 6:27 AM, <josef...@gmail.com> wrote:

After having some fun again with writing new code for a while, I returned back to maintenance.

First, time based releases without having someone to do the release or having the infrastructure that does the release almost automatically doesn't work.

I have been holding new PRs away from master since winter and it makes our continuing development quite difficult. So I would like to open master for 0.8 developement very soon. 

We have 4 GSOC projects which will have PRs that should be merged during summer or in Fall.

And then we have several older large PRs (to merge or not to merge - donkey with two haystacks)

I really don't like it that we have many old PRs with good but outdated and unfinished code waiting for some help and for merging. 

We have two options (the 3rd option, finishing up, ain't happening yet):

- keep them out, until a volunteer volunteers, or

- "dump" them into master

I would be in favor on merging them as unfinished, so they stay updated with refactorings, so it's easier to use the functioning parts and so the barrier is lower to make "digestible" improvements.

I would be in favor of keeping them out, because someone might use them without paying attention to a "unfinished" warning and catch some bugs.

If keeping them updated with refactorings is the goal, why not merge them while not yet exposing any public functions/classes? Adding a few underscores should do the job. That addresses the risk of not exposing them to unsuspecting users.

Ralf

[josef...@gmail.com]

I have started to use the underscores for adding methods to existing models, and some generic modules that are still mainly targeted for internal use, until we have a better idea how to expose them. We haven't used underscores for big models yet.

However, this reminds me that we do have now a strong separation of most users from expert users since we have the established API : `import statsmodels.api as sm` 

So, I guess it will work to hide code from "unsuspecting users".

Sounds like some fun time with interactive git rebase and python 2->3 conversion coming up.

Josef

 

Ralf

[josef...@gmail.com]

On Tue, Jun 30, 2015 at 9:07 AM, <josef...@gmail.com> wrote:

On Tue, Jun 30, 2015 at 1:32 AM, Ralf Gommers <ralf.g...@gmail.com> wrote:

On Tue, Jun 30, 2015 at 6:27 AM, <josef...@gmail.com> wrote:

After having some fun again with writing new code for a while, I returned back to maintenance.

First, time based releases without having someone to do the release or having the infrastructure that does the release almost automatically doesn't work.

I have been holding new PRs away from master since winter and it makes our continuing development quite difficult. So I would like to open master for 0.8 developement very soon. 

my current shortlist for 0.7, candidates for merging before going to Europe in two days:

https://github.com/statsmodels/statsmodels/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Aprio-high+milestone%3A0.7+

(doc fixes might not make it.)

Anything else for the prio-high label?

(aside: I was looking into fixing a problem with GMM, and it looks more like two weeks of refactoring, enhancements, unit tests and documentation, and then my maintenance streak will be on hold again.)

Josef