Thread: Re: [matplotlib-devel] v1.0.x branch seems confused (Page 2)

On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:

> Before we made the git transition, I read about various workflows.
> What we are doing now is somewhat similar to what used to be done with
> svnmerge. I just googled "git workflow", and found
> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
> See the section on "Merging Upwards":
>
>
Responding to  a few of the points mentioned above -- definitely +1 on more
releases.  I have been the bottleneck here and can do more.  With that in
mind, let's plan on getting a trunk release out with a 2 week timeline or
so.

I think there is a solid case for a release branch, so we can
test/refine/fix while allowing development in the trunk.  Once it is
released, one suggestion is to can keep it around as maintenance but only
for release critical bugs so that if we discover a show stopper three weeks
after the release, we can cut a bugfix release w/ a shorted round of
testing.  Perhaps if we limit it to release critical bugs, this will lower
the development burden on maintaining it and merging it.

On the animations issue, I have noticed one strange behavior when I tried to
remove the gtk extension code and replace it with pure python and found the
new animations API behaved strangely (but not the old) under the new code.
I never committed my changes because I could not resolve whether it was my
code or Ryan's that was causing the problem, and he wasn't sure either.  But
incompletely baked features (and I wouldn't even call the animations code
incompletely baked) are OK for releases.  It's better to get them out there
and in use so our users can find and fix the bugs :-)

JDH

On Fri, Jun 3, 2011 at 4:39 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>>
>> Before we made the git transition, I read about various workflows.
>> What we are doing now is somewhat similar to what used to be done with
>> svnmerge. I just googled "git workflow", and found
>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>> See the section on "Merging Upwards":
>>
>
> Responding to  a few of the points mentioned above -- definitely +1 on more
> releases.  I have been the bottleneck here and can do more.  With that in
> mind, let's plan on getting a trunk release out with a 2 week timeline or
> so.

That would be great. I am eager to merge the py3 stuff back into the
main repository and start thinking about a 1.2 release.

> I think there is a solid case for a release branch, so we can
> test/refine/fix while allowing development in the trunk.  Once it is
> released, one suggestion is to can keep it around as maintenance but only
> for release critical bugs so that if we discover a show stopper three weeks
> after the release, we can cut a bugfix release w/ a shorted round of
> testing.  Perhaps if we limit it to release critical bugs, this will lower
> the development burden on maintaining it and merging it.

Sounds like a good idea.

On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
> On the animations issue, I have noticed one strange behavior when I tried to
> remove the gtk extension code and replace it with pure python and found the
> new animations API behaved strangely (but not the old) under the new code.
> I never committed my changes because I could not resolve whether it was my
> code or Ryan's that was causing the problem, and he wasn't sure either.  But
> incompletely baked features (and I wouldn't even call the animations code
> incompletely baked) are OK for releases.  It's better to get them out there
> and in use so our users can find and fix the bugs :-)

Well if you need to rip it out/"temporarily" break it to improve the
gtk backend, by all means do so. I'll be bogged down for a few more
months, after which I'll be able to work more on it. (FINALLY.) The
only reason I even checked it in originally was so that others could
play, but I was (and still am) not ready to commit completely to the
API.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Well if you need to rip it out/"temporarily" break it to improve the
> gtk backend, by all means do so. I'll be bogged down for a few more
> months, after which I'll be able to work more on it. (FINALLY.) The
> only reason I even checked it in originally was so that others could
> play, but I was (and still am) not ready to commit completely to the
> API.
>

Not at all, I think it is at least as likely that there is a problem with my
gtk code rather than a problem in the animations API.  I only brought this
up as an example of how I would rather release mostly functioning code with
a few possible warts than incubate it in the trunk for months.  What you
have done is so much better than what we have that it needs to get out there
even if we have to fix or change the API later.

JDH

On Fri, Jun 3, 2011 at 8:50 AM, Ryan May <rm...@gm...> wrote:

> On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
> > On the animations issue, I have noticed one strange behavior when I tried
> to
> > remove the gtk extension code and replace it with pure python and found
> the
> > new animations API behaved strangely (but not the old) under the new
> code.
> > I never committed my changes because I could not resolve whether it was
> my
> > code or Ryan's that was causing the problem, and he wasn't sure either.
> But
> > incompletely baked features (and I wouldn't even call the animations code
> > incompletely baked) are OK for releases.  It's better to get them out
> there
> > and in use so our users can find and fix the bugs :-)
>
> Well if you need to rip it out/"temporarily" break it to improve the
> gtk backend, by all means do so. I'll be bogged down for a few more
> months, after which I'll be able to work more on it. (FINALLY.) The
> only reason I even checked it in originally was so that others could
> play, but I was (and still am) not ready to commit completely to the
> API.
>
> Ryan
>
>
The problem is that there aren't a lot of people playing with this code, and
people are still using the documentation's examples for animations.  Maybe
we ought to consider a mechanism to release it with the next release with a
huge "experimental" sticker on it, somehow?

Ben Root

On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:

> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>
>> Before we made the git transition, I read about various workflows.
>> What we are doing now is somewhat similar to what used to be done with
>> svnmerge. I just googled "git workflow", and found
>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>> See the section on "Merging Upwards":
>>
>>
> Responding to  a few of the points mentioned above -- definitely +1 on more
> releases.  I have been the bottleneck here and can do more.  With that in
> mind, let's plan on getting a trunk release out with a 2 week timeline or
> so.
>
> I think there is a solid case for a release branch, so we can
> test/refine/fix while allowing development in the trunk.  Once it is
> released, one suggestion is to can keep it around as maintenance but only
> for release critical bugs so that if we discover a show stopper three weeks
> after the release, we can cut a bugfix release w/ a shorted round of
> testing.  Perhaps if we limit it to release critical bugs, this will lower
> the development burden on maintaining it and merging it.
>

Why not just call it a release candidate and follow a similar process for it
as numpy just did a short while ago?

Plus, with regards to timing.  Do we want to release before or after the
upcoming SciPy conference in July?  Depending on who will be there
(unfortunately, I won't be), we might want to wait for after that conference
to take advantage of any activity then.

Also, I know I have repeatedly stated that I won't be a release manager, but
I am going to put together a wish-list of mine for what I would like to see
for the next release.  Maybe with that as a base, we can come up with a
final set of goals for v1.1.0 and determine how much time it would take to
get there?

Ben Root

On Fri, Jun 3, 2011 at 10:04 AM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>>>
>>> Before we made the git transition, I read about various workflows.
>>> What we are doing now is somewhat similar to what used to be done with
>>> svnmerge. I just googled "git workflow", and found
>>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>>> See the section on "Merging Upwards":
>>>
>>
>> Responding to  a few of the points mentioned above -- definitely +1 on
>> more releases.  I have been the bottleneck here and can do more.  With that
>> in mind, let's plan on getting a trunk release out with a 2 week timeline or
>> so.
>>
>> I think there is a solid case for a release branch, so we can
>> test/refine/fix while allowing development in the trunk.  Once it is
>> released, one suggestion is to can keep it around as maintenance but only
>> for release critical bugs so that if we discover a show stopper three weeks
>> after the release, we can cut a bugfix release w/ a shorted round of
>> testing.  Perhaps if we limit it to release critical bugs, this will lower
>> the development burden on maintaining it and merging it.
>
> Why not just call it a release candidate and follow a similar process for it
> as numpy just did a short while ago?
>
> Plus, with regards to timing.  Do we want to release before or after the
> upcoming SciPy conference in July?  Depending on who will be there
> (unfortunately, I won't be), we might want to wait for after that conference
> to take advantage of any activity then.

If we have the resources, it might be better to release before, and
encourage activity at scipy to focus on py3 support (assuming it has
been merged into master by then).

On Fri, Jun 3, 2011 at 9:04 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> Plus, with regards to timing.  Do we want to release before or after the
> upcoming SciPy conference in July?  Depending on who will be there
> (unfortunately, I won't be), we might want to wait for after that conference
> to take advantage of any activity then.
>
>

I don't feel the need to wait -- things move slowly enought that we might
get one release out in the next couple of weeks and one bugfix release 2-4
weeks after that and that will dovetail with scipy conference.  Also, my
June is a lot better than my July as I will be traveling in July for the
first couple of weeks.


> Also, I know I have repeatedly stated that I won't be a release manager,
> but I am going to put together a wish-list of mine for what I would like to
> see for the next release.  Maybe with that as a base, we can come up with a
> final set of goals for v1.1.0 and determine how much time it would take to
> get there?
>


This might be a better idea for a 1.2 release, since this sounds like it
will take a while.  There has been a lot of progress in the trunk since
1.0.1 and with the release-early-release-often philosophy I'd rather get
something out there and then if we want to do something more formalized for
the next iteration we will have plenty of time for it.  I would shoot for
people to get their changes in for a 1.1 release by early next week, branch
and cut a release candidate, test for a week and put in bug fixes, cut a
second release candidate a week later.  If people would like more time for a
formal process and bug closing extravaganza, I'm fine with that too.



JDH