Hi Folks,
I'm planning on freezing the sourceforge svn repository Friday evening
at 8:00 (NY time), and moving the git repository to its new home on
Saturday morning.
If you have concerns, please speak up.
Darren
John discovered a problem with some very early project history that
was lost several years ago during the CVS to Subversion migration. We
have an opportunity to recover it during the git migration. However,
do to a recent attack, Sourceforge has taken their CVS service down,
and based on the latest information at SourceForge Community Blog - What's new on SourceForge.net ,
they do not expect it to be back before late this week. I do not think
I will available to work on the migration this upcoming weekend, Feb
4-6. So it will probably be February 7 or 8 before I have a chance to
try to recover the old history, convert the repos to git, and post
them to github.
Darren
···
On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale <dsdale24@...149...> wrote:
Hi Folks,
I'm planning on freezing the sourceforge svn repository Friday evening
at 8:00 (NY time), and moving the git repository to its new home on
Saturday morning.If you have concerns, please speak up.
It looks like the history we were looking for does not exist in the
CVS repository either.
John, could you freeze the svn repo around noon on Friday? I'll
convert the repositories and push them up to github on Saturday. Is it
possible to close the sourceforge bugtracker, feature requests, etc to
new issues as well?
Darren
···
On Sun, Jan 30, 2011 at 8:10 AM, Darren Dale <dsdale24@...149...> wrote:
On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale <dsdale24@...149...> wrote:
Hi Folks,
I'm planning on freezing the sourceforge svn repository Friday evening
at 8:00 (NY time), and moving the git repository to its new home on
Saturday morning.If you have concerns, please speak up.
John discovered a problem with some very early project history that
was lost several years ago during the CVS to Subversion migration. We
have an opportunity to recover it during the git migration. However,
do to a recent attack, Sourceforge has taken their CVS service down,
and based on the latest information at SourceForge Community Blog - What's new on SourceForge.net ,
they do not expect it to be back before late this week. I do not think
I will available to work on the migration this upcoming weekend, Feb
4-6. So it will probably be February 7 or 8 before I have a chance to
try to recover the old history, convert the repos to git, and post
them to github.
Hey,
John, could you freeze the svn repo around noon on Friday? I'll
convert the repositories and push them up to github on Saturday. Is it
possible to close the sourceforge bugtracker, feature requests, etc to
new issues as well?
are you guys planning on transfering the old bugs to github? As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.
Glad to see eveythong moving over to github! (since scipy is also
about to do the same, as soon as 0.9 is out, for which things are
already at the RC stage).
A huge thank you to Darren for putting so much hard work into this, I
admire your attention to detail (and I wish I'd been so thorough when
I transitioned ipython, where we could have recovered from some old
history problems, but I'm too lazy for that :).
Cheers,
f
···
On Wed, Feb 16, 2011 at 5:00 AM, Darren Dale <dsdale24@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.
Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.
Glad to see eveythong moving over to github! (since scipy is also
about to do the same, as soon as 0.9 is out, for which things are
already at the RC stage).A huge thank you to
Hang on, don't jinx it.
Darren
···
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez <fperez.net@...149...> wrote:
I did some poking around and do not see an easy way to freeze the
repo. I can disable it, but then I think it won't be available for
read access. One thing I could do is remove commit privs for every
developer, making the repo read only going forward. This seems like a
reasonable approach.
As for the tracker, similarly, I see how to disable it but not to
freeze it so that no new issues can be added. Anyone seeing things
differently?
JDH
···
On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsdale24@...149...> wrote:
John, could you freeze the svn repo around noon on Friday? I'll
convert the repositories and push them up to github on Saturday. Is it
possible to close the sourceforge bugtracker, feature requests, etc to
new issues as well?
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.
Darren,
Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the "delete" disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer.
Eric
···
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
Glad to see eveythong moving over to github! (since scipy is also
about to do the same, as soon as 0.9 is out, for which things are
already at the RC stage).A huge thank you to
Hang on, don't jinx it.
Darren
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
a pre-commit hook that just "exit 1" ? it prevents commits but not checkouts.
Just my 2c,
···
On Wed, Feb 16, 2011 at 19:57, John Hunter <jdh2358@...149...> wrote:
On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsdale24@...149...> wrote:
John, could you freeze the svn repo around noon on Friday? I'll
convert the repositories and push them up to github on Saturday. Is it
possible to close the sourceforge bugtracker, feature requests, etc to
new issues as well?I did some poking around and do not see an easy way to freeze the
repo. I can disable it, but then I think it won't be available for
read access. One thing I could do is remove commit privs for every
developer, making the repo read only going forward. This seems like a
reasonable approach.
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Even better, a pre-commit hook that also echos out a message stating where to go. And maybe a pre-update/pre-checkout hook that does something similar?
Ben Root
···
On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi <morph@…12…> wrote:
On Wed, Feb 16, 2011 at 19:57, John Hunter <jdh2358@…149…> wrote:
On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsdale24@…149…> wrote:
John, could you freeze the svn repo around noon on Friday? I’ll
convert the repositories and push them up to github on Saturday. Is it
possible to close the sourceforge bugtracker, feature requests, etc to
new issues as well?
I did some poking around and do not see an easy way to freeze the
repo. I can disable it, but then I think it won’t be available for
read access. One thing I could do is remove commit privs for every
developer, making the repo read only going forward. This seems like a
reasonable approach.
a pre-commit hook that just “exit 1” ? it prevents commits but not checkouts.
Just my 2c,
Not sure Sourceforge allows custom hooks in SVN.
Mike
We have a couple in place already
https://sourceforge.net/project/admin/svn.php?group_id=80706
···
On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom <mdroe@...31...> wrote:
Not sure Sourceforge allows custom hooks in SVN.
Yes. But those aren't custom -- SF only provides a fixed set of scripts one can apply. Notably, I don't think there's one that prevents further commits.
Mike
···
On 02/16/2011 03:53 PM, John Hunter wrote:
On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<mdroe@...31...> wrote:
Not sure Sourceforge allows custom hooks in SVN.
We have a couple in place already
https://sourceforge.net/project/admin/svn.php?group_id=80706
If that is the case, then let's just change the permissions for all
the devs to read-only. We can leave the tracker, feature requests, and
so forth enabled until we are ready to disable them at some later
time. Once the website is online at matplotlib.github.com, we can
follow the directions for "project relocation" at
https://sourceforge.net/project/admin/removal.php?group_id=80706 .
SourceForge will keep the project intact as an archive.
Darren
···
On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom <mdroe@...31...> wrote:
On 02/16/2011 03:53 PM, John Hunter wrote:
On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<mdroe@...31...> wrote:
Not sure Sourceforge allows custom hooks in SVN.
We have a couple in place already
https://sourceforge.net/project/admin/svn.php?group_id=80706
Yes. But those aren't custom -- SF only provides a fixed set of scripts
one can apply. Notably, I don't think there's one that prevents further
commits.
We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"
···
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing <efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.
I made the tracker display the maximum number of entries per page, then clicked "check all", then "mass update" with "delete", and it marked them as "deleted"--but they never get deleted. They are still there, but marked "deleted". It sounds like that is the same as what you tried, so I don't know why you are getting that error message.
Which tracker category is showing the new spam?
Eric
···
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"
The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.
The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewedeThe tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues at The tracker export
xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues . Devs, please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.
···
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <efiring@...229...> wrote:
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"I made the tracker display the maximum number of entries per page, then
clicked "check all", then "mass update" with "delete", and it marked
them as "deleted"--but they never get deleted. They are still there,
but marked "deleted". It sounds like that is the same as what you tried,
so I don't know why you are getting that error message.Which tracker category is showing the new spam?
Let me try again:
The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.
···
On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale <dsdale24@...149...> wrote:
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <efiring@...229...> wrote:
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"I made the tracker display the maximum number of entries per page, then
clicked "check all", then "mass update" with "delete", and it marked
them as "deleted"--but they never get deleted. They are still there,
but marked "deleted". It sounds like that is the same as what you tried,
so I don't know why you are getting that error message.Which tracker category is showing the new spam?
The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.
The submitter info is lost?
And when it was originally submitted?
If yes to either, then I think that we should not transfer these from sourceforge, but deal with them there.
Overall, the tracking interface on github looks so bad that I can't see why we would want to move. Sourceforge is slow, but at least the tracker has the right sort of functionality: the ability to scan a lot of info on one screen, the ability to categorize, attach files, assign, etc. Maybe some of this is available but not evident in the github tracker, but what I see is not encouraging.
Mpl historically has not done well in using the tracker. I hope that eventually we can transition to a tool that will help us do better, not worse.
Eric
···
On 02/26/2011 10:54 AM, Darren Dale wrote:
On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsdale24@...149...> wrote:
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<efiring@...229...> wrote:
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...149...> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"I made the tracker display the maximum number of entries per page, then
clicked "check all", then "mass update" with "delete", and it marked
them as "deleted"--but they never get deleted. They are still there,
but marked "deleted". It sounds like that is the same as what you tried,
so I don't know why you are getting that error message.Which tracker category is showing the new spam?
The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.Let me try again:
The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.
Ditto on this. Github has been a wonderful tool for developers, but for users of projects, I haven’t seen the amount of sophistication and polish that sourceforge has.
I am personally fine with continuing to use sourceforge for the tracker (I know I need to catch up on bugs there…). My main concern, though, is having two active issue trackers – one on sourceforge and one on github.
Ben Root
···
On Sat, Feb 26, 2011 at 4:58 PM, Eric Firing <efiring@…552…229…> wrote:
On 02/26/2011 10:54 AM, Darren Dale wrote:
On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsdale24@…149…> wrote:
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<efiring@…229…> wrote:
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@…229…> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@gmail.com> wrote:
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that’s irrelevant here). I’m going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I’ll be
happy to help out.
Thanks, that would be very helpful. I’ll follow up once I figure out
how to extract the information from sourceforge.
Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the “delete” disposition, but
I don’t think that actually gets rid of them. If it doesn’t, then maybe
they can be filtered out during the transfer.
We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: “XSRF Attempt Detected!”
I made the tracker display the maximum number of entries per page, then
clicked “check all”, then “mass update” with “delete”, and it marked
them as “deleted”–but they never get deleted. They are still there,
but marked “deleted”. It sounds like that is the same as what you tried,
so I don’t know why you are getting that error message.
Which tracker category is showing the new spam?
The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.
Let me try again:
The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don’t know if that
would mean that we can no longer host the homepage at sourceforge.
The submitter info is lost?
And when it was originally submitted?
If yes to either, then I think that we should not transfer these from
sourceforge, but deal with them there.
Overall, the tracking interface on github looks so bad that I can’t see
why we would want to move. Sourceforge is slow, but at least the
tracker has the right sort of functionality: the ability to scan a lot
of info on one screen, the ability to categorize, attach files, assign,
etc. Maybe some of this is available but not evident in the github
tracker, but what I see is not encouraging.
Mpl historically has not done well in using the tracker. I hope that
eventually we can transition to a tool that will help us do better, not
worse.
Eric
are you guys planning on transfering the old bugs to github?
Probably at some point.
As I
mentioned, I have code lying around for the upload (and to download
from launchpad, but that's irrelevant here). I'm going to be mosly
offline til Monday (conference trip), but if someone pings me on my
Berkeley email address, which I monitor even while traveling, I'll be
happy to help out.Thanks, that would be very helpful. I'll follow up once I figure out
how to extract the information from sourceforge.Darren,
Just a heads-up on that: In November the tracker was heavily spammed.
Recently I marked a few hundred items with the "delete" disposition, but
I don't think that actually gets rid of them. If it doesn't, then maybe
they can be filtered out during the transfer.We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"I made the tracker display the maximum number of entries per page, then
clicked "check all", then "mass update" with "delete", and it marked
them as "deleted"--but they never get deleted. They are still there,
but marked "deleted". It sounds like that is the same as what you tried,
so I don't know why you are getting that error message.Which tracker category is showing the new spam?
The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.Let me try again:
The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.The submitter info is lost?
And when it was originally submitted?
No, I can improve it so this information is included.
If yes to either, then I think that we should not transfer these from
sourceforge, but deal with them there.
Each issue has a hyperlink to the report at sourceforge.
Overall, the tracking interface on github looks so bad that I can't see
why we would want to move. Sourceforge is slow, but at least the
tracker has the right sort of functionality: the ability to scan a lot
of info on one screen, the ability to categorize, attach files, assign,
etc. Maybe some of this is available but not evident in the github
tracker, but what I see is not encouraging.
I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.
There are some good things about it though. Labels, the ability to
link between an issue and the commits that resolve it, the ability for
people to provide feedback on what issues are important to them.
Mpl historically has not done well in using the tracker. I hope that
eventually we can transition to a tool that will help us do better, not
worse.
I disagree that we would do worse with the github tracker.
···
On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <efiring@...229...> wrote:
On 02/26/2011 10:54 AM, Darren Dale wrote:
On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsdale24@...149...> wrote:
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<efiring@...229...> wrote:
On 02/26/2011 09:26 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<efiring@...229...> wrote:
On 02/16/2011 08:38 AM, Darren Dale wrote:
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@...761.....> wrote: