matplotlib-devel Mailing List for matplotlib

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