matplotlib-devel Mailing List for matplotlib

On Wednesday, June 15, 2011, Darren Dale <dsd...@gm...> wrote:
> On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <md...@st...> wrote:
>> On 06/15/2011 01:00 PM, Darren Dale wrote:
>>>
>>> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>
>>>  wrote:
>>>>
>>>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>>>>
>>>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>
>>>>>  wrote:
>>>>>>
>>>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>
>>>>>>  wrote:
>>>>>>
>>>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>>>> everyone's attention to the fact the next release will be the first to
>>>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>>>> branch.
>>>>>>
>>>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>>>> release, but this will be a good impetus.  Should we give people a
>>>>>> couple of days to close any open tickets they want or push any last
>>>>>> minute changes in that we want before making the 1.1 release branch?
>>>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>>>> discussed last.
>>>>>
>>>>> Each pull request gets assigned to an issue.
>>>>
>>>> How do I apply labels to an issue with an associated pull request?  I see
>>>> how to do it for free-standing issues, but not the pull request ones.
>>>
>>> On the main issues page, you can select the check box for an issue,
>>> and then you can use the label, assignee, milestone widgets at the top
>>> of the issues list
>>>
>> Ok.  I have also added a milestone for v1.0.x for simple fixes to very
>> well-defined bugs -- things we should be able to get out as soon as
>> possible.
>
> I figured out how to migrate soureforges tracker to github issues with
> the new github api. There are 232 open issues on the sourceforge
> tracker, 79 of which are feature requests. Most sf issues are from
> 2009 and on, many in the last few months. How do we want to handle
> this? Migrate now and then cull the list at github? I can add a
> sourceforge-import label that we can use to filter the list, closing
> or assigning milestones and labels as we go, removing the sf-import
> label once the issue has been inspected. Then we could disable the
> tracker at the github site. Alternatively, we could try cull the list
> at sourceforge first. Whatever you guys want to do.
>

Just a quick note for my work, I am currently without Internet access
and (most) people in my apartment complex has learned to secure their
wifi.  I will try to look through the list of issues and pull requests
soon enough.

Ben Root

On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <md...@st...> wrote:
> On 06/15/2011 01:00 PM, Darren Dale wrote:
>>
>> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>
>>  wrote:
>>>
>>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>>>
>>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>
>>>>  wrote:
>>>>>
>>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>
>>>>>  wrote:
>>>>>
>>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>>> everyone's attention to the fact the next release will be the first to
>>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>>> branch.
>>>>>
>>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>>> release, but this will be a good impetus.  Should we give people a
>>>>> couple of days to close any open tickets they want or push any last
>>>>> minute changes in that we want before making the 1.1 release branch?
>>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>>> discussed last.
>>>>
>>>> Each pull request gets assigned to an issue.
>>>
>>> How do I apply labels to an issue with an associated pull request?  I see
>>> how to do it for free-standing issues, but not the pull request ones.
>>
>> On the main issues page, you can select the check box for an issue,
>> and then you can use the label, assignee, milestone widgets at the top
>> of the issues list
>>
> Ok.  I have also added a milestone for v1.0.x for simple fixes to very
> well-defined bugs -- things we should be able to get out as soon as
> possible.

I figured out how to migrate soureforges tracker to github issues with
the new github api. There are 232 open issues on the sourceforge
tracker, 79 of which are feature requests. Most sf issues are from
2009 and on, many in the last few months. How do we want to handle
this? Migrate now and then cull the list at github? I can add a
sourceforge-import label that we can use to filter the list, closing
or assigning milestones and labels as we go, removing the sf-import
label once the issue has been inspected. Then we could disable the
tracker at the github site. Alternatively, we could try cull the list
at sourceforge first. Whatever you guys want to do.

On 06/15/2011 01:00 PM, Darren Dale wrote:
> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>  wrote:
>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>    wrote:
>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>    wrote:
>>>>
>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>> everyone's attention to the fact the next release will be the first to
>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>> branch.
>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>> release, but this will be a good impetus.  Should we give people a
>>>> couple of days to close any open tickets they want or push any last
>>>> minute changes in that we want before making the 1.1 release branch?
>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>> discussed last.
>>> Each pull request gets assigned to an issue.
>> How do I apply labels to an issue with an associated pull request?  I see
>> how to do it for free-standing issues, but not the pull request ones.
> On the main issues page, you can select the check box for an issue,
> and then you can use the label, assignee, milestone widgets at the top
> of the issues list
>
Ok.  I have also added a milestone for v1.0.x for simple fixes to very 
well-defined bugs -- things we should be able to get out as soon as 
possible.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom <md...@st...> wrote:
> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>
>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>  wrote:
>>>
>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>  wrote:
>>>
>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>> consider it as a placeholder for now. Then we bump the version number
>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>> everyone's attention to the fact the next release will be the first to
>>>> drop support for<=python-2.5. Once folks start working with the
>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>> branch.
>>>
>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>> release, but this will be a good impetus.  Should we give people a
>>> couple of days to close any open tickets they want or push any last
>>> minute changes in that we want before making the 1.1 release branch?
>>> Once we branch, I suggest only release critical bug fixes go in as we
>>> discussed last.
>>
>> Each pull request gets assigned to an issue.
>
> How do I apply labels to an issue with an associated pull request?  I see
> how to do it for free-standing issues, but not the pull request ones.

On the main issues page, you can select the check box for an issue,
and then you can use the label, assignee, milestone widgets at the top
of the issues list

>>  I just added two labels
>> in the github issue tracker: wishlist and ongoing.
>
> So, to be clear, "wishlist" means "would be nice to have, but no real target
> date", and "ongoing" means someone is working on it?

That was the idea. Ongoing meaning some progress has been made, but
nobody has taken ownership of the issue.

>>  I also created two
>> milestones: v1.1.0 and v2.0.0. Could the devs please look through the
>> issues and assign each one to either one of the milestones or apply
>> the wishlist label? I could try to merge the issues from sourceforge
>> as well, though that may take some time.
>
> It would be nice to merge those in -- wasn't there some tools other projects
> were using to import them en masse?

Yes: https://github.com/ddale/mpl-issues

I need to see if the code will still work since they upgraded their
issue tracker. I can have a look tonight.

On 06/15/2011 12:13 PM, Darren Dale wrote:
> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>  wrote:
>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>  wrote:
>>
>>> I suggest we make a 1.1.x branch from the current state of master, and
>>> consider it as a placeholder for now. Then we bump the version number
>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>> everyone's attention to the fact the next release will be the first to
>>> drop support for<=python-2.5. Once folks start working with the
>>> master (2.0) branch, if we have any complaints that a version 1.1
>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>> branch.
>> This works for me -- I obviously dropped the ball pushing for a 1.1
>> release, but this will be a good impetus.  Should we give people a
>> couple of days to close any open tickets they want or push any last
>> minute changes in that we want before making the 1.1 release branch?
>> Once we branch, I suggest only release critical bug fixes go in as we
>> discussed last.
> Each pull request gets assigned to an issue.

How do I apply labels to an issue with an associated pull request?  I 
see how to do it for free-standing issues, but not the pull request ones.

>   I just added two labels
> in the github issue tracker: wishlist and ongoing.

So, to be clear, "wishlist" means "would be nice to have, but no real 
target date", and "ongoing" means someone is working on it?

>   I also created two
> milestones: v1.1.0 and v2.0.0. Could the devs please look through the
> issues and assign each one to either one of the milestones or apply
> the wishlist label? I could try to merge the issues from sourceforge
> as well, though that may take some time.

It would be nice to merge those in -- wasn't there some tools other 
projects were using to import them en masse?  If we do so, I would also 
suggest (somewhat controversially) that we deleted everything before 
some arbitrary cut off date.  There are a lot of really old, and most 
likely obsolete bugs in there, and we should probably just declare 
bankruptcy on them.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Wed, Jun 15, 2011 at 10:06 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale <dsd...@gm...> wrote:
>
>> I suggest we make a 1.1.x branch from the current state of master, and
>> consider it as a placeholder for now. Then we bump the version number
>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>> everyone's attention to the fact the next release will be the first to
>> drop support for <=python-2.5. Once folks start working with the
>> master (2.0) branch, if we have any complaints that a version 1.1
>> release was needed after all, we can cut it from the 1.1.x placeholder
>> branch.
>
> This works for me -- I obviously dropped the ball pushing for a 1.1
> release, but this will be a good impetus.  Should we give people a
> couple of days to close any open tickets they want or push any last
> minute changes in that we want before making the 1.1 release branch?
> Once we branch, I suggest only release critical bug fixes go in as we
> discussed last.

Each pull request gets assigned to an issue. I just added two labels
in the github issue tracker: wishlist and ongoing. I also created two
milestones: v1.1.0 and v2.0.0. Could the devs please look through the
issues and assign each one to either one of the milestones or apply
the wishlist label? I could try to merge the issues from sourceforge
as well, though that may take some time.

On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale <dsd...@gm...> wrote:

> I suggest we make a 1.1.x branch from the current state of master, and
> consider it as a placeholder for now. Then we bump the version number
> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
> everyone's attention to the fact the next release will be the first to
> drop support for <=python-2.5. Once folks start working with the
> master (2.0) branch, if we have any complaints that a version 1.1
> release was needed after all, we can cut it from the 1.1.x placeholder
> branch.

This works for me -- I obviously dropped the ball pushing for a 1.1
release, but this will be a good impetus.  Should we give people a
couple of days to close any open tickets they want or push any last
minute changes in that we want before making the 1.1 release branch?
Once we branch, I suggest only release critical bug fixes go in as we
discussed last.

On Mon, Jun 13, 2011 at 2:29 PM, Michael Droettboom <md...@st...> wrote:
> On 06/13/2011 01:38 PM, Darren Dale wrote:
>>
>> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<md...@st...>
>>  wrote:
>>>
>>> This was recently discussed in the thread "v1.0.x branch seems confused."
>>>
>>> I (believe) the consensus was to get out another v1.0.x maintenance
>>> release out in the near future (which would not support py3k, but would
>>> still support Python 2.4), and then merge the py3 branch into master so
>>> it starts to get some more testing before making the next major release.
>>>
>>> I'm just today merging master into py3 so that when we are ready to do
>>> the merge the other way most of the hard work will have already been
>>> done.
>>
>> Are there features already in master that should be supported by
>> <python-2.6? If so, I think we should consider releasing 1.1.0 and
>> making a 1.1.x maintenance branch before merging the py3 stuff back
>> into master. Then mpl-1.2 could be the first to support py3.
>
> That's a good question.  We're now *officially* on 2.7 in my environment, so
> I don't have any compulsion to raise my hand here.  But others may.  Speak
> up!  :)

I suggest we make a 1.1.x branch from the current state of master, and
consider it as a placeholder for now. Then we bump the version number
in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
delete the py3 repo. The reason for bumping to v2.0 is simply to draw
everyone's attention to the fact the next release will be the first to
drop support for <=python-2.5. Once folks start working with the
master (2.0) branch, if we have any complaints that a version 1.1
release was needed after all, we can cut it from the 1.1.x placeholder
branch.

Darren