Thread: Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?

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.

Should we move this discussion to the mpl-dev mailing list?

Darren

On 06/13/2011 07: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.
>
> Should we move this discussion to the mpl-dev mailing list?
>
> Darren
Ho I wasn't aware of an mpl-dev mailing list. Sorry.
py3 is already ok with python3  *and* python2 isn't it?

Maybe the website should advertise a bit on the needs to test the py3 
branch.
Users used to compile mpl from git should be able to produce valuable 
technical feedback, shoudn't they?

Xavier

On Mon, Jun 13, 2011 at 5:33 PM, Xavier Gnata <xav...@gm...> wrote:
> On 06/13/2011 07: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.
>>
>> Should we move this discussion to the mpl-dev mailing list?
>>
>> Darren
>
> Ho I wasn't aware of an mpl-dev mailing list. Sorry.
> py3 is already ok with python3  *and* python2 isn't it?

With python-2.6 and python-2.7, yes, but not with older versions.
There will be some outstanding issues with python3, like certain
backends that will not work because the gui toolkits have not been
ported.

> Maybe the website should advertise a bit on the needs to test the py3
> branch.
> Users used to compile mpl from git should be able to produce valuable
> technical feedback, shoudn't they?

I think we should wait until we merge py3 back into the main repo.

Darren

On 06/15/2011 10:35 AM, Darren Dale wrote:

>
> 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.

Dale,

I'm willing to go along with the transfer.  Probably just as well to get 
it over with now, assuming attached example files are included in some 
usable fashion.  As Mike notes, the sourceforge tracker is sluggish, 
although in some ways it is better-designed.

Eric

On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing <ef...@ha...> wrote:
> On 06/15/2011 10:35 AM, Darren Dale wrote:
>
>>
>> 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.
>
> Dale,
>
> I'm willing to go along with the transfer.  Probably just as well to get
> it over with now, assuming attached example files are included in some
> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
> although in some ways it is better-designed.

Eric,

Github's issue tracker still doesn't support attachements, so I've
been inserting a hyperlink in the github issue to direct to the
sourceforge issue, and I've included information at the bottom of the
github issue concerning the history, which would indicate an
attachment was submitted at sourceforge. Is that acceptable?

Darren (Dale is my last name)

On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing <ef...@ha...> wrote:
> On 06/15/2011 10:35 AM, Darren Dale wrote:
>
>>
>> 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.
>
> Dale,
>
> I'm willing to go along with the transfer.  Probably just as well to get
> it over with now, assuming attached example files are included in some
> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
> although in some ways it is better-designed.

Ok, I've migrated the issues over to github.

Darren

On 06/20/2011 08:47 AM, Darren Dale wrote:
> On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing<ef...@ha...>  wrote:
>> On 06/15/2011 10:35 AM, Darren Dale wrote:
>>
>>>
>>> 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.
>>
>> Dale,
>>
>> I'm willing to go along with the transfer.  Probably just as well to get
>> it over with now, assuming attached example files are included in some
>> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
>> although in some ways it is better-designed.
>
> Eric,
>
> Github's issue tracker still doesn't support attachements, so I've
> been inserting a hyperlink in the github issue to direct to the
> sourceforge issue, and I've included information at the bottom of the
> github issue concerning the history, which would indicate an
> attachment was submitted at sourceforge. Is that acceptable?

Darren,

Yes, I think that will work fine.  Thank you for all the work you have 
done and are doing for the sourceforge-to-github switch.

>
> Darren (Dale is my last name)

Oops, sorry--I knew that, but my brain disconnected from my fingers.

Eric

On 06/20/2011 11:29 AM, Darren Dale wrote:

> Ok, I've migrated the issues over to github.
>
> Darren

Darren,

Thank you.  Now I see another possible problem with the issue tracker: 
it doesn't seem to have a way to select issues that do *not* have a 
particular label.  Well, at least that gives us extra incentive to plow 
through the sourceforge imports and try to close as many as possible. 
Also to figure out a good standard set of labels.

Eric

On Mon, Jun 20, 2011 at 6:18 PM, Eric Firing <ef...@ha...> wrote:
> On 06/20/2011 11:29 AM, Darren Dale wrote:
>
>> Ok, I've migrated the issues over to github.
>>
>> Darren
>
> Darren,
>
> Thank you.  Now I see another possible problem with the issue tracker:
> it doesn't seem to have a way to select issues that do *not* have a
> particular label.

I just filed a support request and asked if this feature could be added.

> Well, at least that gives us extra incentive to plow
> through the sourceforge imports and try to close as many as possible.
> Also to figure out a good standard set of labels.

Since github thinks I am the original reporter of all of the migrated
issues, I'm getting notifications on all the sourceforge issues
activity. Impressive progress! I think we closed over 80 issues since
yesterday, and you handled a big majority of them.

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!  :)

> Should we move this discussion to the mpl-dev mailing list?

Sure.

Cheers,
Mike

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

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

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 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 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 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 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 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 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 06/15/2011 04:35 PM, Darren Dale wrote:
>
> 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.

My humble preference is to migrate them all to github with the special 
"SF" label.  I find the github tracker (while not as full featured) 
faster to use.

Cheers,
Mike

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