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
On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale <dsd...@gm...> 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 http://sourceforge.net/blog/ , 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 Sun, Jan 30, 2011 at 8:10 AM, Darren Dale <dsd...@gm...> wrote: > On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale <dsd...@gm...> 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 http://sourceforge.net/blog/ , > 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. 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 Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...> 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. 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 19:57, John Hunter <jd...@gm...> wrote: > On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...> 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, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi <mo...@de...> wrote: > On Wed, Feb 16, 2011 at 19:57, John Hunter <jd...@gm...> wrote: > > On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm...> 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, > 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
Hey, On Wed, Feb 16, 2011 at 5:00 AM, Darren Dale <dsd...@gm...> 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? 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 12:39 PM, Fernando Perez <fpe...@gm...> 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 02/16/2011 08:38 AM, Darren Dale wrote: > On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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. Eric > >> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing <ef...@ha...> wrote: > On 02/16/2011 08:38 AM, Darren Dale wrote: >> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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!"
Not sure Sourceforge allows custom hooks in SVN. Mike On 02/16/2011 02:45 PM, Benjamin Root wrote: > On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi <mo...@de... > <mailto:mo...@de...>> wrote: > > On Wed, Feb 16, 2011 at 19:57, John Hunter <jd...@gm... > <mailto:jd...@gm...>> wrote: > > On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale <dsd...@gm... > <mailto:dsd...@gm...>> 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, > > > 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 > > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom <md...@st...> 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
On 02/16/2011 03:53 PM, John Hunter wrote: > On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<md...@st...> 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. Mike
On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom <md...@st...> wrote: > On 02/16/2011 03:53 PM, John Hunter wrote: >> On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<md...@st...> 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. 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 02/26/2011 09:26 AM, Darren Dale wrote: > On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> wrote: >> On 02/16/2011 08:38 AM, Darren Dale wrote: >>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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? Eric
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote: > On 02/26/2011 09:26 AM, Darren Dale wrote: >> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> wrote: >>> On 02/16/2011 08:38 AM, Darren Dale wrote: >>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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 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 3:52 PM, Darren Dale <dsd...@gm...> wrote: > On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote: >> On 02/26/2011 09:26 AM, Darren Dale wrote: >>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> wrote: >>>> On 02/16/2011 08:38 AM, Darren Dale wrote: >>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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.
On 02/26/2011 10:54 AM, Darren Dale wrote: > On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...> wrote: >> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...> wrote: >>> On 02/26/2011 09:26 AM, Darren Dale wrote: >>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> wrote: >>>>> On 02/16/2011 08:38 AM, Darren Dale wrote: >>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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
On Sat, Feb 26, 2011 at 4:58 PM, Eric Firing <ef...@ha...> wrote: > On 02/26/2011 10:54 AM, Darren Dale wrote: > > On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...> wrote: > >> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...> > wrote: > >>> On 02/26/2011 09:26 AM, Darren Dale wrote: > >>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> > 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 > > 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 6:15 PM, Benjamin Root <ben...@ou...> wrote: > 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. The one at github can be easily disabled.
On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote: > On 02/26/2011 10:54 AM, Darren Dale wrote: >> On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...> wrote: >>> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...> wrote: >>>> On 02/26/2011 09:26 AM, Darren Dale wrote: >>>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...> wrote: >>>>>> On 02/16/2011 08:38 AM, Darren Dale wrote: >>>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...> 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? 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 3:24 PM, Darren Dale <dsd...@gm...> wrote: > > I agree that the github interface is not great. The github devs seem > to know that everybody complains about it. Yup. I hold on to the hope that, because it's so egregiously, painfully broken and braindead and it stands out so badly in comparison to the rest of github (which is brilliant), that it won't be too long before this improves. Granted, we can't know what's on their internal todo list, but those guys are obviously good and listen to feedback (from what I've seen elsewhere on the site), and their bug tracker has become something of a laughing stock, so I can only imagine that they're actually working on it. In the meantime, Min recently pointed out this interesting alternative: http://githubissues.heroku.com/#darrendale/mpl-issues You can point it to any repository you want, and it makes interacting with the issue list far, far saner than via github itself. We're using now that interface ourselves for IPython: http://githubissues.heroku.com/#ipython/ipython and I have to say that I like it quite a bit. For those on OSX, this can even be installed to run locally, with the feel of a native app (it's still a webkit app, but it launches like a local app). Something to keep in mind as you make the decision... In the end, in IPython we decided to move to github in order to benefit from the close integration between pull requests, bugs and commits. Pull requests automatically create an issue, one can close bugs automatically from the commit message, etc. I figured these things would be nice to have for an everyday workflow, and that eventually github itself would improve its native bug system. Cheers, f
On 02/26/2011 01:44 PM, Fernando Perez wrote: > On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale<dsd...@gm...> wrote: >> >> I agree that the github interface is not great. The github devs seem >> to know that everybody complains about it. > > Yup. I hold on to the hope that, because it's so egregiously, > painfully broken and braindead and it stands out so badly in > comparison to the rest of github (which is brilliant), that it won't > be too long before this improves. Granted, we can't know what's on > their internal todo list, but those guys are obviously good and listen > to feedback (from what I've seen elsewhere on the site), and their bug > tracker has become something of a laughing stock, so I can only > imagine that they're actually working on it. > > In the meantime, Min recently pointed out this interesting alternative: > > http://githubissues.heroku.com/#darrendale/mpl-issues It is impressive, and improves some aspects, but I don't see that it makes the github tracker usable for new tickets. I don't see any facility for attaching a file--is this correct? We really want users with problems and suggestions to attach minimal example files, patches, whatever--as downloadable files, not pasted into the comment box. My inclination would be to keep using the SF tracker exclusively until the github tracker improves substantially, and then switch. Eric > > You can point it to any repository you want, and it makes interacting > with the issue list far, far saner than via github itself. > > We're using now that interface ourselves for IPython: > > http://githubissues.heroku.com/#ipython/ipython > > and I have to say that I like it quite a bit. For those on OSX, this > can even be installed to run locally, with the feel of a native app > (it's still a webkit app, but it launches like a local app). > > Something to keep in mind as you make the decision... > > In the end, in IPython we decided to move to github in order to > benefit from the close integration between pull requests, bugs and > commits. Pull requests automatically create an issue, one can close > bugs automatically from the commit message, etc. I figured these > things would be nice to have for an everyday workflow, and that > eventually github itself would improve its native bug system. > > Cheers, > > f > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search& Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Sat, Feb 26, 2011 at 6:14 PM, Eric Firing <ef...@ha...> wrote: > It is impressive, and improves some aspects, but I don't see that it > makes the github tracker usable for new tickets. I don't see any > facility for attaching a file--is this correct? We really want users > with problems and suggestions to attach minimal example files, patches, > whatever--as downloadable files, not pasted into the comment box. No, that's a current limitation of the github tracker. As a poor man's attachment system, github does have the gist system: https://gist.github.com/ that makes it easy to drop any file (small or large) and have it permanently stored on GH with a stable url. But I agree that the tracker should have proper file attachments built-in, using gist is just a workaround, and one most people won't necessarily know about gist or think of it as a way to attach files to the tracker. > My inclination would be to keep using the SF tracker exclusively until > the github tracker improves substantially, and then switch. Since we did switch for ipython, here's me keeping my fingers painfully crossed for that day to come earlier rather than later... Cheers, f
Darren Dale <dsd...@gm...> writes: > On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote: >> On 02/26/2011 10:54 AM, Darren Dale wrote: >> >> The submitter info is lost? >> And when it was originally submitted? > > No, I can improve it so this information is included. That's clearly in the xml file, except that I don't know if we can map sourceforge userids to email addresses - that sounds like something that spammers would want to do. One thing that I think is missing in the xml file are the attachment contents. There are filenames and some kind of ids that presumably can be used to get the files via the sf bug pages, but this information only occurs in the artifact_history subsection. To get the correct files you'll have to first parse this to figure out that file 396374 was added but then deleted and then file 396688 was added: <field name="artifact_history"> <history> <field name="field_name">File Added</field> <field name="old_value">396688: set_verts_cleanup_2.patch</field> <field name="entrydate">1293000689</field> <field name="mod_by">notmuchtotell</field> </history> <history> <field name="field_name">File Deleted</field> <field name="old_value">396374: </field> <field name="entrydate">1293000467</field> <field name="mod_by">notmuchtotell</field> </history> <history> <field name="field_name">File Added</field> <field name="old_value">396374: set_verts_cleanup.patch</field> <field name="entrydate">1292605835</field> <field name="mod_by">notmuchtotell</field> </history> > 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. Does anyone have experience with other trackers? bugs.python.org seems to be using Roundup - any experiences with that? -- Jouni K. Seppänen http://www.iki.fi/jks