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 Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom <mdroe@...31...> 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.
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
···
On 06/13/2011 01:38 PM, Darren Dale wrote:
On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<mdroe@...31...> wrote:
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
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 06/13/2011 07:38 PM, Darren Dale wrote:
On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<mdroe@...31...> 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
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 Mon, Jun 13, 2011 at 5:33 PM, Xavier Gnata <xavier.gnata@...149...> wrote:
On 06/13/2011 07:38 PM, Darren Dale wrote:
On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<mdroe@...31...> >> 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.
Darren
···
On Mon, Jun 13, 2011 at 2:29 PM, Michael Droettboom <mdroe@...31...> wrote:
On 06/13/2011 01:38 PM, Darren Dale wrote:
On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<mdroe@...31...> >> 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!
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 9:02 AM, Darren Dale <dsdale24@...149...> 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.
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 10:06 AM, John Hunter <jdh2358@...149...> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale <dsdale24@...149...> 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.
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
···
On 06/15/2011 12:13 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2358@...149...> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdale24@...149...> wrote:
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
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: GitHub - 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 Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom <mdroe@...31...> wrote:
On 06/15/2011 12:13 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2358@...149...> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdale24@...149...> wrote:
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
···
On 06/15/2011 01:00 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<mdroe@...31...> wrote:
On 06/15/2011 12:13 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2358@...149...> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdale24@...149...> 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
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
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 Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <mdroe@...31...> wrote:
On 06/15/2011 01:00 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<mdroe@...31...> >> wrote:
On 06/15/2011 12:13 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2358@...149...> >>>> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdale24@...149...> >>>>> 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.
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 Wednesday, June 15, 2011, Darren Dale <dsdale24@...149...> wrote:
On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <mdroe@...31...> wrote:
On 06/15/2011 01:00 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<mdroe@...31...> >>> wrote:
On 06/15/2011 12:13 PM, Darren Dale wrote:
On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jdh2358@...149...> >>>>> wrote:
On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsdale24@...149...> >>>>>> 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.
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
···
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.
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
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 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.
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 <efiring@...229...> 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.
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 08:47 AM, Darren Dale wrote:
On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing<efiring@...229...> wrote:
On 06/15/2011 10:35 AM, Darren Dale wrote:
Ok, I've migrated the issues over to github.
Darren
···
On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing <efiring@...229...> 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.
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 06/20/2011 11:29 AM, Darren Dale wrote:
Ok, I've migrated the issues over to github.
Darren
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 Mon, Jun 20, 2011 at 6:18 PM, Eric Firing <efiring@...229...> wrote:
On 06/20/2011 11:29 AM, Darren Dale wrote: