On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <md...@stsci.edu> wrote: > On 06/15/2011 01:00 PM, Darren Dale wrote: >> >> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@stsci.edu> >> wrote: >>> >>> On 06/15/2011 12:13 PM, Darren Dale wrote: >>>> >>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2...@gmail.com> >>>> wrote: >>>>> >>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdal...@gmail.com> >>>>> 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. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
