On Wednesday, June 15, 2011, Darren Dale <dsdal...@gmail.com> wrote: > 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. >
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 ------------------------------------------------------------------------------ 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
