I'm not getting email from SF when assigned a bug/patch
Folks, When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) Since I don't monitor my SF personal page regularly any more, that means that the issue will remain in limbo forever or until someone points me to it. So if you want me to take any particular action (even rejecting something) please send me a separate email! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?)
I believe it broke at some point, I'm pretty certain it used to work. Regards, Martin
On 3/27/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Guido van Rossum wrote:
When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?)
I believe it broke at some point, I'm pretty certain it used to work.
More reason to move away from SF ASAP. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
>> When you assign a bug/patch to me, somehow SourceForge doesn't send >> me an email. (Is this understood behavior? Can it be changed?) Martin> I believe it broke at some point, I'm pretty certain it used to Martin> work. I would expect that if it broke for Guido it broke for everybody. While we consider him to be the BDFL I suspect the accolades are lost on the SF folks. Skip
skip@pobox.com wrote:
Martin> I believe it broke at some point, I'm pretty certain it used to Martin> work.
I would expect that if it broke for Guido it broke for everybody. While we consider him to be the BDFL I suspect the accolades are lost on the SF folks.
Indeed, it broke for me as well. I didn't notice until Guido's post that this is what happened - I had assumed I had filtered out/deleted these messages. Regards, Martin
On 3/27/06, Guido van Rossum <guido@python.org> wrote:
Folks,
When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) Since I don't monitor my SF personal page regularly any more, that means that the issue will remain in limbo forever or until someone points me to it. So if you want me to take any particular action (even rejecting something) please send me a separate email!
Ah, glad to hear I wasn't the only one bitten by that. For a while, I thought I was going senile :-P Speaking of which, perhaps we should designate the running roundup instance on python.org as the issuetracker for py3k ? Gives us a good chance to evaluate, and if it doesn't work out, it wouldn't matter too much. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters <thomas@python.org> wrote:
Ah, glad to hear I wasn't the only one bitten by that. For a while, I thought I was going senile :-P Speaking of which, perhaps we should designate the running roundup instance on python.org as the issuetracker for py3k ? Gives us a good chance to evaluate, and if it doesn't work out, it wouldn't matter too much.
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath). -- Giovanni Bajo
On Tuesday 28 March 2006 19:13, Giovanni Bajo wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
Please god no. No bugzilla, no no no. Please!
Anthony Baxter <anthony@interlink.com.au> wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
Please god no. No bugzilla, no no no. Please!
Care to elaborate? -- Giovanni Bajo
On Tuesday 28 March 2006 19:35, Giovanni Bajo wrote:
Anthony Baxter <anthony@interlink.com.au> wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
Please god no. No bugzilla, no no no. Please!
Care to elaborate?
Unbelievably complicated to setup and run. Awful default user interface (how many form fields can you get??) Awful code. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Hello, what about trac: http://www.edgewall.com/trac/ It is based on python and has a very good svn integration. -- bye by Wolfgang
On 3/28/06, Wolfgang Langner <tds333+pydev@gmail.com> wrote:
what about trac:
It is based on python and has a very good svn integration.
Sorry, I should have realized more than half of python-dev lacked the context in which I made my suggestion. At PyCon and in a few other select groups, there's been talk about swapping SF for 'something else'. (Actually, there's been a lot of talk about that everywhere, but I'm talking about concrete proposals ;) The problem is 'which 'something else''. There is a PSF committee that is charged with proposing and trying out, but it got somewhat stuck at trying to get information from SourceForge. My suggestion is to use the existing, installed, configured roundup installation so we can give it a whirl. Obviously, we will also want to give trac and jira and any other serious alternatives a try. (But Bugzilla and RT have already been veto'd.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Wolfgang Langner wrote:
what about trac:
It is based on python and has a very good svn integration.
We started using it recently and so far it's working really well. I love the svn (and wiki!) integration. However, I have no idea how well it scales to a project the size of Python. Just
Just van Rossum <just@letterror.com> wrote:
It is based on python and has a very good svn integration.
We started using it recently and so far it's working really well. I love the svn (and wiki!) integration. However, I have no idea how well it scales to a project the size of Python.
Having extensively used both Trac and Bugzilla, let me say that the ticket tracker in Trac is a child-play version of Bugzilla. It might be enough for Python, though, if SF was enough till now. I thought that a large project like Python required something more advanced. Anyway, I'll shut up as I see there is a committee for this decision. The integration between tickets/svn/wiki in Trac is cute though, even if, after a while, you'd really want that mailman parsed that syntax as well (and maybe your MUA too :) -- Giovanni Bajo
Anthony Baxter wrote:
On Tuesday 28 March 2006 19:35, Giovanni Bajo wrote:
Anthony Baxter <anthony@interlink.com.au> wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
Please god no. No bugzilla, no no no. Please!
Care to elaborate?
Unbelievably complicated to setup and run. Awful default user interface (how many form fields can you get??) Awful code.
Perl. Georg ;)
Anthony Baxter <anthony@interlink.com.au> wrote:
On Tuesday 28 March 2006 19:13, Giovanni Bajo wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
Please god no. No bugzilla, no no no. Please!
I second the "god no. No bugzilla" sentiment. - Josiah
On Tue, 2006-03-28 at 10:13 +0200, Giovanni Bajo wrote:
Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath).
The infrastructure committee (of which I'm a member but not the chair) is examining the alternatives and trying to put up some live demos for people to check out. Getting the data out of SourceForge has been the sticky issue though, and last I recall, we were waiting for some response from them about export bugs we'd encountered. -Barry
Barry> The infrastructure committee (of which I'm a member but not the Barry> chair) is examining the alternatives and trying to put up some Barry> live demos for people to check out. Roundup is there now, right (sans SF export)? Trac is being used by the folks doing the new website. What other candidates are being considered? Based on my brief experience as a Bugzilla user (just trying to be a good citizen and report Mozilla bugs a few years ago), I would vote -1. I'd hate to think the bug reporting interface was *so* bad that it alone would discourage people from reporting bugs. Still, I gave up reporting Mozilla bugs because of it. Skip
Op di, 28-03-2006 te 09:23 -0600, schreef skip@pobox.com:
Based on my brief experience as a Bugzilla user (just trying to be a good citizen and report Mozilla bugs a few years ago), I would vote -1. I'd hate to think the bug reporting interface was *so* bad that it alone would discourage people from reporting bugs. Still, I gave up reporting Mozilla bugs because of it.
GNOME uses a Bugzilla "fork" that's more user-friendly... (But other people say Bugzilla is also difficult for admins, so that's probably not the only important thing.) -- Jan Claeys
skip@pobox.com wrote:
Roundup is there now, right (sans SF export)?
Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment.
Trac is being used by the folks doing the new website. What other candidates are being considered?
My view is that nothing should be "considered" unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. Regards, Martin
Martin v. Löwis wrote:
skip@pobox.com wrote:
Roundup is there now, right (sans SF export)?
Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment.
Trac is being used by the folks doing the new website. What other candidates are being considered?
My view is that nothing should be "considered" unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide.
There exists a Trac importer for SF data at http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py though I don't know which format it does expect. Generally, I like Trac very much, especially for its interconnected subsystems. I've used it with smaller projects, and there it works perfectly. Having said that, I don't know if the Trac ticket system (which would be the most important subsystem for us) scales up well enough. Of course, if there are only a few bits missing, instead of paying someone to operate a complicated tracker, perhaps the money could be used to pay someone to improve Trac... Georg
Georg Brandl wrote:
Generally, I like Trac very much, especially for its interconnected subsystems. I've used it with smaller projects, and there it works perfectly.
Having said that, I don't know if the Trac ticket system (which would be the most important subsystem for us) scales up well enough.
I'm completely fail to see why a Trac server shouldn't scale up at least as well as the SF-hosted Python tracker... (I mean, we're talking about one project, not 116,757 ...)
Of course, if there are only a few bits missing, instead of paying someone to operate a complicated tracker, perhaps the money could be used to pay someone to improve Trac...
I cannot find the message right now, but I'm quite sure that someone recently suggested that the right way to try out a new tracker was to use it for the Python 3000 activity. my suggestion is to ask the python-hosting folks if they're willing to set up a free pyk3 account: http://www.python-hosting.com/freetrac if this works well for Python 3000, the next step would be to ask them if they're willing to host the 2.X tracker as well (and optionally the SVN archive, as well). PSF might not be the Mozilla Foundation, but I'm sure there's enough funds to pay for suitably large commercial account. </F>
On Wed, 2006-03-29 at 17:52 +0200, Fredrik Lundh wrote:
if this works well for Python 3000, the next step would be to ask them if they're willing to host the 2.X tracker as well (and optionally the SVN archive, as well). PSF might not be the Mozilla Foundation, but I'm sure there's enough funds to pay for suitably large commercial account.
I'll just point out that Atlassian has offered us free hosting for a Jira/Confluence solution (plus svn and other stuff we may or may not want). I personally support this option, but I know (and accept!) that there are differing opinions. -Barry
Hello,
I'll just point out that Atlassian has offered us free hosting for a Jira/Confluence solution (plus svn and other stuff we may or may not want). I personally support this option, but I know (and accept!) that there are differing opinions.
It is a Java system. Why promote Java solutions for python ? I think there are good python solutions for a bug tracker and we should prefer them. -- bye by Wolfgang
Wolfgang Langner wrote:
It is a Java system. Why promote Java solutions for python ? I think there are good python solutions for a bug tracker and we should prefer them.
It is an application. Why worry about its implementation language? If there are good Python solutions they should be used, if not it's better to use something that works well regardless of what it's written in. (Not that I qualify to have an opinion. I don't have time to contribute to Python, other than with snarky emails.) -- Benji York
On 3/29/06, Wolfgang Langner <tds333+pydev@gmail.com> wrote: [Barry]
I'll just point out that Atlassian has offered us free hosting for a Jira/Confluence solution (plus svn and other stuff we may or may not want). I personally support this option, but I know (and accept!) that there are differing opinions.
It is a Java system. Why promote Java solutions for python ? I think there are good python solutions for a bug tracker and we should prefer them.
Watch out for the parochialism! I like Python as much as the next guy (probably more :-) but I'm sensitive to choosing the best solution. In this case I think the criteria should be saving volunteer sysadmin time in maintenance, conveniece for users, and convenience in developer time (not necessarily in that order). I don't know any of the suggested systems well enough to know how they score, so I don't want to side any particular proposal; but I think we should not base our argument on "it's written in competing language X". Beware NIH. Also, we're supposed to be friendly with Java, as we have a major product in that arena. What if Java folks were to reject a Python solution because it's not written in Python? Wouldn't we be upset about the parochialism? The language choice should only be used as an argument if all else is equal. Of course, "hackability" of a particular solution may be a criterion too, and there the language choice could matter. But the above response sounded like a knee-jerk to me, and IMO needs to be rebutted. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Watch out for the parochialism! I like Python as much as the next guy (probably more :-) but I'm sensitive to choosing the best solution.
you better make that "good enough", or we'll be stuck with SF for an- other hundred years.
The language choice should only be used as an argument if all else is equal.
since it's a lot easier to get Pythoneers to volunteer time to work on (develop, hack, keep running, create add-ons for) a solution written in Python, the criteria ought to be "the language choice is only irrelevant if there's no Python solution that's good enough". it's also a marketing thing; if the developers don't want to eat Python dogfood, why should anyone else do that ? </F>
On 3/29/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Guido van Rossum wrote:
Watch out for the parochialism! I like Python as much as the next guy (probably more :-) but I'm sensitive to choosing the best solution.
you better make that "good enough", or we'll be stuck with SF for an- other hundred years.
Fair enough. I like "good enough" as a criterion; it's served me well in real life for many years, since it reduces the time I waste pondering decisions. Unlike language design issues, tool selection choices aren't forever.
The language choice should only be used as an argument if all else is equal.
since it's a lot easier to get Pythoneers to volunteer time to work on (develop, hack, keep running, create add-ons for) a solution written in Python, the criteria ought to be "the language choice is only irrelevant if there's no Python solution that's good enough".
it's also a marketing thing; if the developers don't want to eat Python dogfood, why should anyone else do that ?
Sure. There are plenty of reasons to prefer Python, making all else "not equal". I was just warning against knee-jerk parochialism, which I don't think will serve us well. There's Perl code in the Python source tree, and the only reason to get rid of it IMO should be if it no longer serves our purpose. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
The language choice should only be used as an argument if all else is equal. Of course, "hackability" of a particular solution may be a criterion too, and there the language choice could matter. But the above response sounded like a knee-jerk to me, and IMO needs to be rebutted.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Include in "hackability" the ability to get all ticket data out accurately in a reasonable format to auto-import into a different system 5 years from now when the new one, whatever it may be, is deemed annoying. :) i like the idea of trac. i like the experience of jira/confluence. anything beats sourceforge.
Hello, On 3/29/06, Guido van Rossum <guido@python.org> wrote:
On 3/29/06, Wolfgang Langner <tds333+pydev@gmail.com> wrote:
It is a Java system. Why promote Java solutions for python ? I think there are good python solutions for a bug tracker and we should prefer them.
...
Also, we're supposed to be friendly with Java, as we have a major product in that arena. What if Java folks were to reject a Python solution because it's not written in Python? Wouldn't we be upset about the parochialism?
I have no problem with Java, neither with other languages. Most time I have to program in C++ and sometimes in Java. I only suggest to give python solutions a try even if they are not yet equal in quality. But they should be better than SF.
The language choice should only be used as an argument if all else is equal. Of course, "hackability" of a particular solution may be a criterion too, and there the language choice could matter. But the above response sounded like a knee-jerk to me, and IMO needs to be rebutted.
I think there are good python solutions and please don't underrate the marketing effect. My opinion is only subjective and to choose one system we must define some criteria's to decide the "best" one. But something other :-) Even Ruby on Rails uses Trac: http://dev.rubyonrails.org/wiki -- bye by Wolfgang
On 3/29/06, Barry Warsaw <barry@python.org> wrote:
I'll just point out that Atlassian has offered us free hosting for a Jira/Confluence solution (plus svn and other stuff we may or may not want). I personally support this option, but I know (and accept!) that there are differing opinions.
I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation. If we did this, we should also try to ensure we can get all the data out, just in case we want to preserve any of it. Most of my time will probably be spent cleaning up 2.5 for the next couple of weeks at least. So I'm not going to have time to rip out more stuff from 3k. coerce is almost gone. Low hanging fruit for someone interested in helping out: * find warnings with icc that are important to fix * remove unnecessary casts for PyMethodDefs The first item requires icc obviously. I haven't had time to set up my version yet. The second item could be done by anyone. There may be some issues resulting from the ssize_t merge that are being masked due to casting. If we remove the unnecessary casts (e.g., PyCFunction, unaryfunc, binaryfunc, ternaryfunc), we may find some things to cleanup. We still need builbots for: FreeBSD, AIX, HP-UX, and NetBSD. n
Neal Norwitz wrote:
I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation.
so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ? from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. I'm obviously missing something here. </F>
On 3/29/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Neal Norwitz wrote:
I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation.
so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ?
Someone else's time to setup and maintain it. In particular, it won't take any time away from any python developer. Plus it's just a chance for me to learn.
from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac.
If someone setups and maintains an instance of Trac, I'd use that too. I suppose I could use Roundup on python.org, but I don't know if it's working. I've used Roundup before, but it was an old version and obviously not tailored to python's setup. Like I said, I won't be prepared to use any new tracker for some time, at least a couple of weeks. If people want to setup systems for me to test out, I'm willing to be a guinea pig. The only thing I really care about is what makes my life the easiest. n
Fredrik Lundh wrote:
Neal Norwitz wrote:
I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation.
so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ?
from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac.
I'm obviously missing something here.
Perhaps that Jira is commercial, so it is out of the question for most open-source Python applications. Georg
On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote:
Perhaps that Jira is commercial, so it is out of the question for most open-source Python applications.
Sorry, I don't follow. Why is a commercial product out of the question for Python? -Barry
Barry Warsaw wrote:
On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote:
Perhaps that Jira is commercial, so it is out of the question for most open-source Python applications.
Sorry, I don't follow. Why is a commercial product out of the question for Python?
What I answered to was: """ from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. I'm obviously missing something here. """ I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers. Georg
Georg Brandl wrote:
What I answered to was:
""" from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac.
I'm obviously missing something here. """
I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers.
Like most commercial tool providers that complete on a market full of open source tools of various quality, Atlassian offers free licenses to non-profits and established open source projects: http://www.atlassian.com/software/jira/pricing.jsp#nonprofit Perforce (who makes an excellent version management system) is another example. We went through very similar discussions back when we moved python from cvs to svn, and ended up picking an open source system that was good enough over a better commercial product, despite the fact that several key developers had extensive experiences of using perforce for large-scale projects. And that's the whole point, of course: if something is widely used by others and is good enough, a project needs very good reasons to pick another tool. </F>
Fredrik Lundh wrote:
Georg Brandl wrote:
What I answered to was:
""" from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac.
I'm obviously missing something here. """
I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers.
Like most commercial tool providers that complete on a market full of open source tools of various quality, Atlassian offers free licenses to non-profits and established open source projects:
http://www.atlassian.com/software/jira/pricing.jsp#nonprofit
Okay, I wasn't aware of that. Georg
On Thu, 2006-03-30 at 16:20 +0200, Georg Brandl wrote:
I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers.
Gotcha, sorry I misunderstood. BTW, Atlassian does have a program to provide free licenses to open source projects. Here's their FAQ item on it: http://www.atlassian.com/about/licensing/faq.jsp#open_source -Barry
On Thu, 2006-03-30 at 09:55 +0200, Fredrik Lundh wrote:
so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ?
Dunno. I'm sure both will accomplish the job and both will be better than the current situation. I've used Jira and Confluence for almost two years now on a daily basis, and I can personally say that they are among the most intuitive and pleasant to use systems of their kind that I've used.
from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac.
FWIW, Atlassian has made the same generous offer for Mailman, and I am going to accept it (assuming we can ever get the freakin' data out of SF). -Barry
Fredrik Lundh wrote:
so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ?
I'm obviously missing something here.
One thing that you are *obviously* missing (there might be more): Nobody has stepped forward and said "I make trac happen". Without somebody (specific) saying that, all technical arguments in favour of that software are futile. Regards, Martin
Martin v. Löwis wrote:
I'm obviously missing something here.
One thing that you are *obviously* missing (there might be more):
Nobody has stepped forward and said "I make trac happen". Without somebody (specific) saying that, all technical arguments in favour of that software are futile.
I'm quite sure I've already pointed to http://www.python-hosting.com/freetrac which could be used by the Python 3000 activity in order to evaluate Trac, and to http://www.python-hosting.com/shared_hosting plus a small fraction of the PSF budget for the Python code, if Trac is found to be good enough, and provided that the PH folks think that it's a good idea to host core development on their platform (I assume we have pretty good stats for how svn.python.org is being used). I can ask them for a test py3k account, if there's any interest. </F>
Fredrik Lundh wrote:
I can ask them for a test py3k account, if there's any interest.
I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either. As for python-hosting.com: Somebody would *still* have to set this up, manage to import the data, manage accounts, manage to make it known etc. The actual hardware to run it on is the least of my concerns - xs4all provides that very nicely. I don't see anything that could be saved by moving things from xs4all to python-hosting. Regards, Martin
On 3/30/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Fredrik Lundh wrote:
I can ask them for a test py3k account, if there's any interest.
I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either.
Me neither. It's too early. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 3/30/06, Guido van Rossum <guido@python.org> wrote:
On 3/30/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Fredrik Lundh wrote:
I can ask them for a test py3k account, if there's any interest.
I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either.
Me neither. It's too early.
Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use (we need large scale bugs in it to stress it and get a feel for its search abilities, etc.). I am going to be picky about keeping the intfrastructure email traffic focued on the task at hand. Tracker discussions will be mostly ignored by me until I send out the official call for tracker suggestions with volunteer maintainers. At that point we can figure out what trackers to consider and who will be in charge of getting the test setup going. -Brett
Brett Cannon wrote:
Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use
oh, I forgot that the Procrastination & Stop energy Foundation was involved in this. see you all in 2015. </F>
On 3/30/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Brett Cannon wrote:
Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use
oh, I forgot that the Procrastination & Stop energy Foundation was involved in this.
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF if you don't believe SF will cooperate fast enough for your tastes or I am giving them too long to try to fix things on their end (I don't expect they will fix things fast enough either, but because of school ending soon I don't have time right now to start working on a scraper myself plus I am willing to give them a little time to try to fix the XML export so we can minimize headaches on our end). If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help. The tracker will need to be able to import the SF data somehow (probably will require a custom tool so the volunteers need to be aware of this), be able to export data (so we can back it up on a regular basis so we don't have to go through this again), and an email interface for at least replying to tracker items. A community-wide announcement will probably be needed to get a good group of volunteers together for any one non-commercial tracker. But I am not procrastinating. I don't think I have ever come off as a procrastinator on this list and I don't think I deserve the label. I am not putting more time in now because I am near the end of term here at school and thus passing my courses takes precendent over a new bug tracker. I ended up the chairman at the infrastructure committee during one of my busiest school terms I have ever had. But I will see this through and it will be done in a timely manner. -Brett
Brett Cannon wrote:
oh, I forgot that the Procrastination & Stop energy Foundation was involved in this.
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF if you don't believe SF will cooperate fast enough for your tastes or I am giving them too long to try to fix things on their end (I don't expect they will fix things fast enough either, but because of school ending soon I don't have time right now to start working on a scraper myself plus I am willing to give them a little time to try to fix the XML export so we can minimize headaches on our end).
here
If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help. The tracker will need to be able to import the SF data somehow (probably will require a custom tool so the volunteers need to be aware of this), be able to export data (so we can back it up on a regular basis so we don't have to go through this again), and an email interface for at least replying to tracker items. A community-wide announcement will probably be needed to get a good group of volunteers together for any one non-commercial tracker.
But I am not procrastinating. I don't think I have ever come off as a procrastinator on this list and I don't think I deserve the label. I am not putting more time in now because I am near the end of term here at school and thus passing my courses takes precendent over a new bug tracker. I ended up the chairman at the infrastructure committee during one of my busiest school terms I have ever had. But I will see this through and it will be done in a timely manner.
-Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gman...
Brett Cannon wrote:
oh, I forgot that the Procrastination & Stop energy Foundation was involved in this.
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF
challenge accepted ;-) http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ contains three basic tools; getindex to grab index information from a python tracker, getpages to get "raw" xhtml versions of the item pages, and getfiles to get attached files. I'm currently downloading a tracker snapshot that could be useful for testing; it'll take a few more hours before all data are downloaded (provided that SF doesn't ban me, and I don't stumble upon more cases where a certain rhettinger has pasted binary gunk into an iso-8859-1 form ;-). $ python status.py tracker-105470 6681 items 1201 pages (17%) 104 files tracker-305470 3610 items 0 pages (0%) 0 files tracker-355470 430 items 430 pages (100%) 80 files the final step is to finish the "off-line scraper" library (a straightfor- ward ET hack), and make a snapshot archive available to interested parties. (drop me a line if you want a copy)
If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help.
that is what I expected the PSF infrastructure committee to do (I hope you're not the only one in that committee?); it's a bit disappointing to hear that we're still stuck on the SF export issue. (wasn't there someone with backchannel access to the SF data ?)
The tracker will need to be able to import the SF data somehow (probably will require a custom tool so the volunteers need to be aware of this), be able to export data (so we can back it up on a regular basis so we don't have to go through this again), and an email interface for at least replying to tracker items. A community-wide announcement will probably be needed to get a good group of volunteers together for any one non-commercial tracker.
But I am not procrastinating. I don't think I have ever come off as a procrastinator on this list and I don't think I deserve the label.
I wasn't talking about individuals, I was referring to the trend where PSF moves something off a public forum, and the work just ends up going nowhere. </F>
Fredrik Lundh wrote:
If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help.
that is what I expected the PSF infrastructure committee to do (I hope you're not the only one in that committee?); it's a bit disappointing to hear that we're still stuck on the SF export issue.
(wasn't there someone with backchannel access to the SF data ?)
Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML (& is not properly entity-referenced sometimes). Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago. The "backchannel access to SF data" was actually someone different: he experimented with the existing export, confirmed the problem, promised to talk to Paul Moore about that, and referred us to the other XML exporter as a work-around (that one allows to export 500 items at a time). Regards, Martin
Martin v. Löwis wrote:
Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML (& is not properly entity-referenced sometimes).
so why didn't Brett know about this ?
Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago.
the scraper I wrote in response to Brett's post has successfully down- loaded 80% of the data at this very moment (including attachments), so I'll probably keep playing with that one instead... </F>
Fredrik Lundh wrote:
Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML (& is not properly entity-referenced sometimes).
so why didn't Brett know about this ?
I'm not sure; I'm sure I mentioned it. Regards, Martin
On 4/2/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Martin v. Löwis wrote:
Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML (& is not properly entity-referenced sometimes).
so why didn't Brett know about this ?
I knew the export existed, but my understanding was that it was ill-formed as in truncated since it didn't have a close tag on the outermost XML tag. So I thought that the data was incomplete and thus the dump was mostly useless. Martin got another dump, and I asked if it contained all the data but just with a bad format, and he said he wasn't sure. That's why I was still planning on possibly writing a scraper if we didn't validate that the dump had all the tracker items.
Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago.
the scraper I wrote in response to Brett's post has successfully down- loaded 80% of the data at this very moment (including attachments), so I'll probably keep playing with that one instead...
I'll reply to this in the other email you sent. -Brett
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF
challenge accepted ;-)
http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
contains three basic tools; getindex to grab index information from a python tracker, getpages to get "raw" xhtml versions of the item pages, and getfiles to get attached files.
I'm currently downloading a tracker snapshot that could be useful for testing; it'll take a few more hours before all data are downloaded (provided that SF doesn't ban me, and I don't stumble upon more cases where a certain rhettinger has pasted binary gunk into an iso-8859-1 form ;-).
alright, it took my poor computer nearly eight hours to grab all the data, and some tracker items needed special treatment to work around some interesting SF bugs, but I've finally managed to download *all* items available via the SF tracker index, and *all* data files available via the item pages: tracker-105470 (bugs) 6682 items 6682 pages (100%) 1912 files tracker-305470 (patches) 3610 items 3610 pages (100%) 4663 files tracker-355470 (feature requests) 430 items 430 pages (100%) 80 files the complete data set is about 300 megabytes uncompressed, and ~85 megabytes zipped. the scripts are designed to make it easy to update the dataset; adding new items and files only takes a couple of minutes; refreshing the item information may take a few hours. ::: I've also added a basic "extract" module which parses the XHTML pages and the data files. this module can be used by import scripts, or be used to convert the dataset into other formats (e.g. a single XML file) for further processing. the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL). </F>
On 4/2/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF
challenge accepted ;-)
Woohoo!
http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
contains three basic tools; getindex to grab index information from a python tracker, getpages to get "raw" xhtml versions of the item pages, and getfiles to get attached files.
I'm currently downloading a tracker snapshot that could be useful for testing; it'll take a few more hours before all data are downloaded (provided that SF doesn't ban me, and I don't stumble upon more cases where a certain rhettinger has pasted binary gunk into an iso-8859-1 form ;-).
alright, it took my poor computer nearly eight hours to grab all the data, and some tracker items needed special treatment to work around some interesting SF bugs, but I've finally managed to download *all* items available via the SF tracker index, and *all* data files available via the item pages:
tracker-105470 (bugs) 6682 items 6682 pages (100%) 1912 files tracker-305470 (patches) 3610 items 3610 pages (100%) 4663 files tracker-355470 (feature requests) 430 items 430 pages (100%) 80 files
the complete data set is about 300 megabytes uncompressed, and ~85 megabytes zipped.
the scripts are designed to make it easy to update the dataset; adding new items and files only takes a couple of minutes; refreshing the item information may take a few hours.
:::
I've also added a basic "extract" module which parses the XHTML pages and the data files. this module can be used by import scripts, or be used to convert the dataset into other formats (e.g. a single XML file) for further processing.
the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL).
Wonderful, Fredrik! Thank you for doing this! When the data is available I will arrange to get it put on python.org somewhere and then start drafting the tracker announcement with where the data is and how to get at it. -Brett
the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL).
I found some free space on the effbot.org server, so anyone inter- ested can get the current ZIP file here: http://effbot.org/tracker-20060403.zip the zip file is ~85 megabytes, and expands to about 300 megabyte data. there are three tracker directories (for the bugs, patches, and feature re- quest trackers). for each item, there are at least two files: item-NNN.xml (index information, created by getindex.py) item-NNN-page.xml (xhtml pages, created by getpages.py) where NNN is the tracker item identifier. for items that have attached files, there's also one or more item-NNN-data-MMM.dat (data files, created by getfiles.py) where MMM is a file identifier (referred to by the page files). ::: the extract module available here: http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ can be used to extract information from the page.xml files (see the sanity check code at the end of that file for a usage example). to use this, you need ElementTree (a Python 2.5 pre-alpha should work) and/or cElementTree. ::: I'll post an export demo script later. cheers /F
On 4/3/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL).
I found some free space on the effbot.org server, so anyone inter- ested can get the current ZIP file here:
http://effbot.org/tracker-20060403.zip
the zip file is ~85 megabytes, and expands to about 300 megabyte data.
Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server?
there are three tracker directories (for the bugs, patches, and feature re- quest trackers). for each item, there are at least two files:
item-NNN.xml (index information, created by getindex.py)
item-NNN-page.xml (xhtml pages, created by getpages.py)
where NNN is the tracker item identifier.
for items that have attached files, there's also one or more
item-NNN-data-MMM.dat (data files, created by getfiles.py)
where MMM is a file identifier (referred to by the page files).
:::
the extract module available here:
http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
can be used to extract information from the page.xml files (see the sanity check code at the end of that file for a usage example).
to use this, you need ElementTree (a Python 2.5 pre-alpha should work) and/or cElementTree.
:::
I'll post an export demo script later.
OK, great. I will send out an email to start hashing out what we want in the tracker call soon so we can start working on that while you type up the demo script. -Brett
Brett Cannon wrote:
Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server?
Did I ever respond to that? I put the file on http://svn.python.org/snapshots/ Regards, Martin
On 4/10/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Brett Cannon wrote:
Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server?
Did I ever respond to that? I put the file on
Nope. Thanks for doing this. I am in the middle of final projects for school so I probably won't get to writing the rough draft of the call for trackers until after the 23rd. -Brett
http://svn.python.org/snapshots/
Regards, Martin
On 4/2/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Brett Cannon wrote:
oh, I forgot that the Procrastination & Stop energy Foundation was involved in this.
Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF
challenge accepted ;-)
http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
contains three basic tools; getindex to grab index information from a python tracker, getpages to get "raw" xhtml versions of the item pages, and getfiles to get attached files.
I'm currently downloading a tracker snapshot that could be useful for testing; it'll take a few more hours before all data are downloaded (provided that SF doesn't ban me, and I don't stumble upon more cases where a certain rhettinger has pasted binary gunk into an iso-8859-1 form ;-).
$ python status.py tracker-105470 6681 items 1201 pages (17%) 104 files tracker-305470 3610 items 0 pages (0%) 0 files tracker-355470 430 items 430 pages (100%) 80 files
the final step is to finish the "off-line scraper" library (a straightfor- ward ET hack), and make a snapshot archive available to interested parties. (drop me a line if you want a copy)
If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help.
that is what I expected the PSF infrastructure committee to do (I hope you're not the only one in that committee?); it's a bit disappointing to hear that we're still stuck on the SF export issue.
The reason I didn't want to deal with the trackers quite yet was that I could see people getting the trackers up and squared away, and then just get frustrated when we were unable to get the SF data to them quickly. I didn't want other people stuck spinning there wheels waiting on us. -Brett
(wasn't there someone with backchannel access to the SF data ?)
The tracker will need to be able to import the SF data somehow (probably will require a custom tool so the volunteers need to be aware of this), be able to export data (so we can back it up on a regular basis so we don't have to go through this again), and an email interface for at least replying to tracker items. A community-wide announcement will probably be needed to get a good group of volunteers together for any one non-commercial tracker.
But I am not procrastinating. I don't think I have ever come off as a procrastinator on this list and I don't think I deserve the label.
I wasn't talking about individuals, I was referring to the trend where PSF moves something off a public forum, and the work just ends up going nowhere.
</F>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
Guido van Rossum wrote:
I can ask them for a test py3k account, if there's any interest.
I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either.
Me neither. It's too early.
I wasn't really expecting you to start collecting *bug reports* for Py3k at this time; you can use Trac for a lot more than that, if you want (including todo/totry/tothinkabout lists, milestones, pep editing sandboxes, etc). </F>
Martin> Nobody has stepped forward and said "I make trac happen". Hasn't trac already happened in the sense that it's installed (by Tim Parkin on the Pollenation website) and in use by the website maintainers? Seems the only major hurdle is the extraction of history from SF. Skip
skip@pobox.com wrote:
Hasn't trac already happened in the sense that it's installed (by Tim Parkin on the Pollenation website) and in use by the website maintainers? Seems the only major hurdle is the extraction of history from SF.
That isn't actually the case. Test data would be available; somebody would need to import them. Regards, Martin
On Wed, 2006-03-29 at 23:33 -0800, Neal Norwitz wrote:
I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation. If we did this, we should also try to ensure we can get all the data out, just in case we want to preserve any of it.
I'm sure we can get the data out (unlike SF :), and my guess would be that they'd be fine with such an experimental relationship. They're very cool folks. I'll leave it up to Brett to decide though, since he's chair of the infrastructure committee. I'm happy to ask them though. -Barry
On Wed, 29 Mar 2006 17:52:07 +0200, Fredrik Lundh <fredrik@pythonware.com> wrote:
Georg Brandl wrote:
Generally, I like Trac very much, especially for its interconnected subsystems. I've used it with smaller projects, and there it works perfectly.
Having said that, I don't know if the Trac ticket system (which would be the most important subsystem for us) scales up well enough.
I'm completely fail to see why a Trac server shouldn't scale up at least as well as the SF-hosted Python tracker... (I mean, we're talking about one project, not 116,757 ...)
One reason might be the lack of paging for tickets. Viewing ~600 tickets at once (approximately the number of open tickets in Twisted's tracker) serves up a 2MB page. How many open tickets does Python have? :) Another reason is that the currently released version hemorrhage memory pretty badly (sometimes ~30MB for a single HTTP request). This is better in trunk@HEAD, but I don't think it's entirely resolved yet. Not that I am suggesting these and the other problems like them are unfixable, but someone will have to fix them, and whoever is going to have to admin the installation should be aware that there will be some issues. Jean-Paul
On 3/28/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
skip@pobox.com wrote:
Roundup is there now, right (sans SF export)?
Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment.
Trac is being used by the folks doing the new website. What other candidates are being considered?
My view is that nothing should be "considered" unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide.
And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered. Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker. But as of right now the committe just wants to get a clean dump of our SF data to work off of (yes, we could start a tracker from scratch but we want the SF data anyway and so we are going through the hassle of getting it off now and as a test data set for the various trackers). -Brett
Brett Cannon wrote:
On 3/28/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
skip@pobox.com wrote:
Roundup is there now, right (sans SF export)?
Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment.
Trac is being used by the folks doing the new website. What other candidates are being considered?
My view is that nothing should be "considered" unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide.
And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered.
Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker.
But as of right now the committe just wants to get a clean dump of our SF data to work off of (yes, we could start a tracker from scratch but we want the SF data anyway and so we are going through the hassle of getting it off now and as a test data set for the various trackers).
-Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gman...
-- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Brett Cannon wrote:
On 3/28/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
My view is that nothing should be "considered" unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide.
And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered.
Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker.
FWIW: Trac has a Sourceforge bug tracker import script: http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py Apologies: for the other blank reply. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
FWIW: Trac has a Sourceforge bug tracker import script:
http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py
Apologies: for the other blank reply.
That isn't actually worth that much: somebody would need to operate it, too. Mere existence doesn't help. Regards, Martin
Martin v. Löwis wrote:
That isn't actually worth that much: somebody would need to operate it, too. Mere existence doesn't help.
why do you keep repeating this when I've already posted a link to a company that does this for only a few bucks per month ? </F>
Fredrik Lundh wrote:
That isn't actually worth that much: somebody would need to operate it, too. Mere existence doesn't help.
why do you keep repeating this when I've already posted a link to a company that does this for only a few bucks per month ?
Because they don't do that. They won't import the Python SF data on their own: somebody has to tell them. Even then, they won't do that: somebody has to provide them with the data (if for no other reason that SF gives access only to project admins). If you are (still) talking about python-hosting.com: where on their website do they say that they will import SF data into trac when asked to? In short: somebody has to take charge, and make sure the thing is available. Maybe it is as simple as filing a support request, but somebody *still* has to do that (or else they won't guess that something is broken). I haven't heard anybody volunteering to do this specific job, working with this specific company. I don't volunteer to do that (I work with SF on issues with their tracker, but only because nobody else does, and because I believe these things need to be done). My impression of of python-hosting is that they provide the machine, and the initial setup. Then you are mostly on your own. Regards, Martin
participants (19)
-
"Martin v. Löwis" -
Anthony Baxter -
Barry Warsaw -
Benji York -
Brett Cannon -
Fredrik Lundh -
Georg Brandl -
Giovanni Bajo -
Gregory P. Smith -
Guido van Rossum -
Jan Claeys -
Jean-Paul Calderone -
Josiah Carlson -
Just van Rossum -
Neal Norwitz -
Robert Kern -
skip＠pobox.com -
Thomas Wouters -
Wolfgang Langner