Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: Fredrik you need tools to help you track the bugs and their status, but Fredrik you can handle issue registration, discussion, and most Fredrik maintenance stuff using good old mail just fine. Which is something SourceForge has yet to learn. At work we use a system called RT (http://www.bestpractical.com/rt/). While it's not perfect, it does allow submissions and responses via email. That feature alone puts it miles ahead of SF in my mind. I'd also prefer to at least be able to respond to tracker items via e-mail. I'm traveling a lot by train working off-line most times. An e-mail spool is unbeatable in this situation. So it's ok for me to add an issue to a tracker while being online. But the follow-ups should be possible via e-mail. SF pretty much sucks in this regard (and has other issues too). The main reason why I'm following this discussion is that I'd also prefer to move away from SF for python-ldap. One reason is availability and the other one is the really bad user interface. I could imagine to spend some spare time when this infrastructure can also be used for python-ldap. And pydns would be another candidate to be moved away from SF. Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Rubin wrote: [EMAIL PROTECTED] writes: Which is something SourceForge has yet to learn. At work we use a system called RT (http://www.bestpractical.com/rt/). While it's not perfect, it does allow submissions and responses via email. That feature alone puts it miles ahead of SF in my mind. I'm on the other side--I think spam has destroyed the usefulness of email as a communications medium and I don't want to depend on anything having to do with email any more. E-mail spam is an issue but the python.org infrastructure already has to do spam filtering for mailing lists. Or does it simply resend all mail? Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Michael Ströder [EMAIL PROTECTED] writes: E-mail spam is an issue but the python.org infrastructure already has to do spam filtering for mailing lists. Or does it simply resend all mail? The problem is that the lists (or at least the pypy list) got mirrored somewhere without having the addresses obscured. Spam robots found the mirrors and scanned for email addresses as they usually do. The addresses then circulate between the spammers and get on more and more lists. It doesn't matter whether the list reflectors forward spam or not. Spammers send crap to the addresses directly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: you're not on the infrastructure list, I hear. I tried to figure out where that list is, so I could have a look at the archives, but I didn't find it in the (for me) obvious places. Could someone please provide a link to the archives for this mailing list, or aren't there any public archives of them? Only for PSF members? python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to contribute manhours. don't underestimate the community. So, how many have offered to help? Is this information available in some public repository? I don't know how much work it actually takes to maintain a roundup installation for the Python project, but I know that in general, not all people manage to follow through on everything they commit to do, even if they have good intentions, so I'd be a bit worried to move to roundup if only two or three people had offered to run it, even if that might nominally be enough. Of course, this depends on who those people would be... Ten seems like a bit too many though. I somehow suspect that less work would get done in a group of ten than in a group of six people... It seems to me that an obvious advantage with either Roundup or Trac, is that if the Python project used it, the Python project would have a significant impact on how this product developed. Even if the Jira people seem eager to please us, I'm pretty convinced that it will be easier to get Roundup or Trac improved to fit our particular needs. That's valuable in two ways: 1) The Python project would get a bug tracker which is developed with the needs of the Python project as a prime concern. (Being the major customer of a product has benefits. Jira on the other hand, might get more and more integrated with other Java stuff that we don't really care about. 2) We'd help making a good Python product even better, and probably more widely used, thus spreading the use of Python even further. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Magnus Lycka wrote: Fredrik Lundh wrote: you're not on the infrastructure list, I hear. I tried to figure out where that list is, so I could have a look at the archives, but I didn't find it in the (for me) obvious places. Could someone please provide a link to the archives for this mailing list, or aren't there any public archives of them? Only for PSF members? The archives are viewable for list members. The list info is at http://mail.python.org/mailman/listinfo/infrastructure python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to contribute manhours. don't underestimate the community. So, how many have offered to help? Is this information available in some public repository? Not yet, as it seems. Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Michael E-mail spam is an issue but the python.org infrastructure Michael already has to do spam filtering for mailing lists. Or does it Michael simply resend all mail? Email sent to most mailing lists hosted on mail.python.org are passed through a SpamBayes instance before being forwarded to the list's members. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Magnus Lycka wrote: It seems to me that an obvious advantage with either Roundup or Trac, is that if the Python project used it, the Python project would have a significant impact on how this product developed. Even if the Jira people seem eager to please us, I'm pretty convinced that it will be easier to get Roundup or Trac improved to fit our particular needs. Yes, because Roundup and Trac are open source projects: there is no barrier to prevent the users taking the code in a direction appropriate to their own needs. And just to make it clear that I'm not picking on Jira, it should be noted that even with their apparent willingness to make a useful community product (and their otherwise remarkable open source credentials), the Launchpad developers can't offer the kinds of assurances implicitly provided by Roundup, Trac or any of their open source brethren. That's valuable in two ways: 1) The Python project would get a bug tracker which is developed with the needs of the Python project as a prime concern. (Being the major customer of a product has benefits. Jira on the other hand, might get more and more integrated with other Java stuff that we don't really care about. As has been said already, there's supposedly no guarantee that people will want to develop Roundup at a hectic tempo in order to satisfy the needs/desires of the Python developers. But then again, other pieces of infrastructure have a high community investment, notably Mailman (which uses Jira as its issue tracker, as it turns out). 2) We'd help making a good Python product even better, and probably more widely used, thus spreading the use of Python even further. It seems to me that with all the fuss about marketing Python [1], instead of ranting about how other products and technologies are stealing all the thunder, one might instead want to start closer to home. In this respect, several opportunities are being missed or squandered either because people think marketing is all about press releases, or they want Python to retain its stealth label (the competitive advantage people mention constantly). Take python.org as the place to start. One can claim all one likes about how Web applications aren't special enough to warrant special mentions or coverage in the context of persuading people about Python's advantages, but many people presumably visit python.org and wonder... * How they can develop Web applications using Python in a way they recognise either from intuition or previous experience. Where can they find a good solution and get started quickly? * Whether python.org, as some kind of content platform, is some kind of convenient answer to their own Internet/intranet site project. Can they download the code and run the same kind of thing themselves? The answers aren't too clear to these questions. I've revisited some of the material available via python.org [2] in order to attempt to provide clearer answers to the first question, but the topic of standardisation is currently stagnant (so it's every framework for itself), and the community is split between hyping the most popular frameworks whilst emphasizing the modest achievements that led to WSGI (which doesn't really answer the first question entirely). Meanwhile, despite the python.org codebase presumably running various commercial sites, it would surprise me if there would ever be a convenient downloadable package of that codebase available prominently from python.org itself (even though the components are all openly available). So the Python project - the power behind content management solutions like Zope, Plone and (at a different angle) MoinMoin - offers an incoherent response to the second question. Then, there are the other recommendations under the Using Python For... heading - advocacy points to show how Python can be really useful - which mentions under Software Development the following: Buildbot, Trac, Roundup and IDEs. If one ignores the current issue tracker debate for a moment and follows the Software Development link, one reaches a general Python applications page which mentions amongst other choices for web development the CPS project, and following the provided link swiftly delivers another advocacy own-goal: We're switching to JAVA! state the CPS people proudly, still blissfully unaware that Java isn't an acronym; Read why they suggest. It's tempting to label what I've written above as just some opportunistic criticism of the maintenance level of the python.org content, that the core developers should just choose their tools and get on with things, and that this thread has attempted to politicize the decision under discussion from the start. Indeed, as someone who merely browses python-dev, perhaps I shouldn't care how the core developers track their bugs: if they struggle to manage that information in future, why should I care? Well, the reason I should care is related to the reason
Re: Python to use a non open source bug tracker?
On 9 Oct 2006 06:36:30 -0700, Paul Boddie [EMAIL PROTECTED] wrote: ... Meanwhile, despite the python.org codebase presumably running various commercial sites, ... Nothing should have given you this impression! python.org's formatting is handled through a custom script called Pyramid, and if you poke around with enough determination you can find the SVN repository's URL. But it's never been released as a tarball, and isn't used by any other sites. As an experiment I tried formatting the python.org site using rest2web; that looks promising, if I ever figure out how sidebars work, and may someday replace Pyramid. --amk -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
A.M. Kuchling wrote: On 9 Oct 2006 06:36:30 -0700, Paul Boddie [EMAIL PROTECTED] wrote: ... Meanwhile, despite the python.org codebase presumably running various commercial sites, ... Nothing should have given you this impression! python.org's formatting is handled through a custom script called Pyramid, and if you poke around with enough determination you can find the SVN repository's URL. But it's never been released as a tarball, and isn't used by any other sites. I believed that Pollenation had deployed other sites using the same technology. Certainly, they appear to be members of the Nevow community on which Pyramid somehow seems to be based. Once upon a time, I did promise to try and make Debian packages available for Pyramid so that people might be more inclined to use the toolchain and thus contribute python.org content, but given the complexity of the dependencies (Twisted 2, some YAML parser that conflicts with the Python bindings of the most widely-deployed YAML parser, Nevow, other stuff) I decided that my time was arguably better spent elsewhere, unfortunately. As an experiment I tried formatting the python.org site using rest2web; that looks promising, if I ever figure out how sidebars work, and may someday replace Pyramid. The python.org redesign was another matter of major community controversy, of course, although I don't have as much to say on that matter. One day, the python.org Wiki may have invaded enough of the visible reference space on the site to make the façade so thin as to be dispensible, although I'm certainly not compaigning for such a thing to happen. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie [EMAIL PROTECTED] writes: Indeed, as someone who merely browses python-dev, perhaps I shouldn't care how the core developers track their bugs: if they struggle to manage that information in future, why should I care? Well, the reason I should care is related to the reason why the core developers should care about more than purely technical issues: the wider community and the core developers do not exist by themselves in isolation; the well-being of the community is related to how Python is managed and portrayed by the custodians of the language, and the well-being of the development effort is related to how much community effort can be directed towards improving the language and its image. If this were not so, Python would have vanished like many of its contemporaries. Perhaps the decision makers evaluated the above and much more in depth, although us outsiders are not in a position to say, but perhaps the discussion around the decision wouldn't have been so inflammatory in places if there had been an acknowledgement of this bigger picture of the community, its influences and that in a large open source project no moderately significant decision is without a political dimension. Thank you. -- \ It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__) will play itself. -- Johann Sebastian Bach | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ben Finney wrote: Ilias Lazaridis [EMAIL PROTECTED] writes: As for Mr. Holden... it's not a matter of not respecting you. It is in his nature to babble in this way. Sometimes it's even funny! Oh my. You have *seriously* misjudged this group if you think that comment will give you any net gain in discussions here. I'm not interested in any gain (except within the systems that I produce). My intention was mainly to place myself on the side of the OP, before the 'Herd of Savages' (the 'Regular Posters') get's out of control and eat's him. . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] tracker. I was claiming that, if such a group was ever formed, it was better spent on bug triage rather than keeping their keys ready all day long to quick-fix any server breakage in minutes. This could be made into an argument for accepting the Jira offer so we don't 'waste' *any* more Python-knowledgable volunteer time on admin. However, thinking about it more, I think that wrestling with a software system like Roundup and interacting with sometimes naive and non-responsive bug submitters are two different skills and likely to attract different volunteers. [snip] Either close directly any nonsense, or ask for more feedback to the poster, until the bug/patch/rfe is sufficiently clear to be handled, or 3 months are passed and you close the bug for no further feedback from the poster. If this would dramatically reduce the number of open bugs, then yes, Python really needs someone to do bug triaging. I have thought this for some time based on my occasional efforts at 'first-response' reviewing. But I have not tried to do anything because of the difficulty of working with the SF tracker. Perhaps submissions by new submitters should start in 'limbo' until rejected or accepted into active open status. I hope that whichever new tracker we get will allow for automated followups at determined intervals, such as 3 mos or whatever. It might be not a good use of your time at all, since you are a developer. But having a database with 938 open bugs most of which are incomplete/nonsense/unconfirmed is much less useful than it could be. Perhaps when the new tracker is set up, you can help scratch the 'too many open bugs' itch. It also raises the bar for new developers: it's much harder to just pick one and fix it. I know because I tried sometimes, and after half an hour I couldn't find any bug that was interesting to me and complete enough to work on it. I also noticed that most bugs are totally uncommented like nobody cared at all. This is where my thought about Python missing bug triaging started. s/most/some/ When I read a bug with no comment I sometimes put extra energy into thinking of something to say or ask just so the reporter will know the report has been read. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo schrieb: So, you might prefer 6-10 people to activate a new tracker account faster than light. I'd rather have 3-days delay in administrative issues because our single administrator is sleeping or whatever, and then have 2-3 people doing regular bug processing. Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. You seem to imply that people who are willing to do roundup admin could regularly, easily do bug triage, and also would be willing to do so. I can attest that this assumption is sooo remote from the truth that I can't really believe you really meant it. I have called for people doing bug review and providing patches many many times, and most of these calls got unheard. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie schrieb: When SF is down, people sometimes send tracker items to the pydev list instead, when means someone else (who?) has to put in the tracker or it gets lost. According to Harald Armin Massa's PostgreSQL talk at EuroPython, the PostgreSQL people manage all their bugs via mailing lists. Given that trends in revision control point towards completely decentralised solutions, I wonder whether there's anything to learn from less centralised (or more flexible) approaches to bug management. From my experience with GCC, I can only report that this is definitely not working. There used to be a mailing list [EMAIL PROTECTED], and reports got either answered immediately, or not at all. People who thought they were responsible put the mails in some folder, and then never found the time to come back. This is why I set up a bug tracker for GCC. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: From my experience with GCC, I can only report that this is definitely not working. There used to be a mailing list [EMAIL PROTECTED], and reports got either answered immediately, or not at all. People who thought they were responsible put the mails in some folder, and then never found the time to come back. you need tools to help you track the bugs and their status, but you can handle issue registration, discussion, and most maintenance stuff using good old mail just fine. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik you need tools to help you track the bugs and their status, but Fredrik you can handle issue registration, discussion, and most Fredrik maintenance stuff using good old mail just fine. Which is something SourceForge has yet to learn. At work we use a system called RT (http://www.bestpractical.com/rt/). While it's not perfect, it does allow submissions and responses via email. That feature alone puts it miles ahead of SF in my mind. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] writes: Which is something SourceForge has yet to learn. At work we use a system called RT (http://www.bestpractical.com/rt/). While it's not perfect, it does allow submissions and responses via email. That feature alone puts it miles ahead of SF in my mind. I'm on the other side--I think spam has destroyed the usefulness of email as a communications medium and I don't want to depend on anything having to do with email any more. I hate the way SF requires registering an email address and then it emails you every update to your SF issues. As a low-intensity user, I sort of tolerate it. But if I used SF more, I'd have to direct all the SF email to a spam bucket and never look at it. At most I'd want it to send about one email per week. But I'd much rather have a personalized RSS feed that delivers updates about the bugs that I'm following. I also notice that the PyPy mailing list now delivers mostly spam, so I've had to direct that to a spam bucket. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: Giovanni Are bug-tracker configuration issues so critical that having Giovanni to wait 48-72hrs to have them fixed is absolutely unacceptable Giovanni for Python development? Yes, I think that would put a crimp in things. The downtimes we see for the SourceForge tracker tend to be of much shorter duration than that (typically a few hours) and cause usually minor problems when they occur. For the tracker to be down for 2-3 days would make the I was actually thinking of 48-72hrs to do regulard admin work like installing latest security patch or actrivate a new account. developers temporarily blind to all outstanding bug reports and patches during that time and prevent non-developers from submitting new bugs, patches and comments. Those people might well forget about their desired submission altogether and not return to submit them once the tracker was back up. I understand your concerns, but I have to remember you that most bug reports submitted by users go totally ignored for several years, or, better, forever. I do not have a correct statistic for this, but I'm confident that at least 80% of the RFE or patches filed every week is totally ignored, and probably at least 50% of the bugs too. I think there is a much bigger problem here wrt QOS. So, you might prefer 6-10 people to activate a new tracker account faster than light. I'd rather have 3-days delay in administrative issues because our single administrator is sleeping or whatever, and then have 2-3 people doing regular bug processing. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: [...] I understand your concerns, but I have to remember you that most bug reports submitted by users go totally ignored for several years, or, better, forever. I do not have a correct statistic for this, but I'm confident that at least 80% of the RFE or patches filed every week is totally ignored, and probably at least 50% of the bugs too. I think there is a much bigger problem here wrt QOS. So, you might prefer 6-10 people to activate a new tracker account faster than light. I'd rather have 3-days delay in administrative issues because our single administrator is sleeping or whatever, and then have 2-3 people doing regular bug processing. ... and if wishes were horses then beggars would ride. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: Paul Rubin wrote: You fail to recognize that Python is *already* using a non-free software for bug tracking, as do thousands of other projects. I don't think that reflects an explicit decision. SF started out as free software and the software became nonfree after people were already using it. Moreover, this looked like a very good chance to have this nuisance sorted out. Too bad some people don't value free software enough. Nuisance? I never heard a peep from anyone until this thread on c.l.p.! This is just a rediculous thing to be arguing over, really it is. Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: snip Perhaps what I *should* have written was Sadly *many* people spend too much time bitching and moaning about those that roll their sleeves up, and not enough rolling their own sleeves up and pitching in. Sniping from the sidelines is far easier than hard work towards a goal. Hey, that is how this whole thread started! Good observation. Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: snip You might also be understimating how negative could be the reaction from the open-source community to such a move. -- Giovanni Bajo That is simply rediculous. Step away from the kool-aid. Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: Giovanni Bajo wrote: [...] I understand your concerns, but I have to remember you that most bug reports submitted by users go totally ignored for several years, or, better, forever. I do not have a correct statistic for this, but I'm confident that at least 80% of the RFE or patches filed every week is totally ignored, and probably at least 50% of the bugs too. I think there is a much bigger problem here wrt QOS. So, you might prefer 6-10 people to activate a new tracker account faster than light. I'd rather have 3-days delay in administrative issues because our single administrator is sleeping or whatever, and then have 2-3 people doing regular bug processing. ... and if wishes were horses then beggars would ride. FWIW, this situation (few administrators compared to the number of community members involved in triage) is basically the situation for the Mozilla project's bug database (which is a bugzilla install, of course), This was the case even before the corporation was founded so it's not a funding issue. My impression has always been that people who kept the bug database clean (moving things to the right component, hunting out duplicates, verifying fixes, and so on) are seen as vital and accorded appropriate respect by the Mozilla development community. I don't think I have any specific point to make except, perhaps, that by making the right noises, it is quite possible to get a useful number of people helping with bug processing work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: I understand your concerns, but I have to remember you that most bug reports submitted by users go totally ignored for several years, or, better, forever. I do not have a correct statistic for this, but I'm confident that at least 80% of the RFE or patches filed every week is totally ignored, and probably at least 50% of the bugs too. I think there is a much bigger problem here wrt QOS. So, you might prefer 6-10 people to activate a new tracker account faster than light. I'd rather have 3-days delay in administrative issues because our single administrator is sleeping or whatever, and then have 2-3 people doing regular bug processing. ... and if wishes were horses then beggars would ride. Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[Giovanni Bajo] I understand your concerns, but I have to remember you that most bug reports submitted by users go totally ignored for several years, or, better, forever. I do not have a correct statistic for this, Indeed you do not. but I'm confident that at least 80% of the RFE or patches filed every week is totally ignored, and probably at least 50% of the bugs too. None are /totally ignored/ -- indeed, at least I see every one as it comes in. You might want to change your claim to that no work obviously visible to you is done on them. That would be better. But, in fact, most bugs and patches are eventually closed, and many that stay open involve such obscure platform-dependent mysteries that nobody with sufficient platform expertise to resolve them appears to exist. For example, if you'd prefer, I'll assign all bugs and patches involving threads on HP-UX to you from now on ;-) These are the actual stats as of a few minutes ago: Bugs: 938 open of 7169 total ~= 87% closed Patches: 429 open of 3846 total ~= 89% closed Feature Requests: 240 open of 479 total ~= 50% closed I think there is a much bigger problem here wrt QOS. Well, you're confident that 80% of patches are ignored. In reality, 89% of all patches ever submitted have been pursued to final resolution. Call me a stickler for detail, but something just doesn't jibe there to my eyes ;-) There's an easy way to improve these percentages dramatically, although they're not bad as-is: run thru them and close every one that isn't entirely clear. For example, reject every feature request, close every patch that changes visible behavior not /clearly/ fixing a bona fide bug, and close every bug report that's really a feature request or random but Perl/Ruby/PHP doesn't do it this way complaint in disguise. The Python developers tend to keep a report open if there's a scant non-zero chance that somebody, someday, might appear who's motivated enough to make something of it. If the goal was instead to make the percentages look good, they could easily and justifiably be dramatically improved before today ends. For example, the oldest patch open today is a speculative implementation of rational numbers for Python. This is really a feature request in disguise, and has very little chance-- but not /no/ chance --of ever being accepted. The oldest bug open today is from 6 years ago, and looks like an easy-to-answer /question/ about the semantics of regular expressions in Python 1.6. I could take time to close that one now, but is that a /good/ use of time? Yes, but, at the moment, even finishing this reply seems to be a /better/ use of my time -- and after that, I'm going to get something to eat ;-) Note that I don't mean to claim that turnaround time on bugs and patches is ideal. To the contrary, if it's /my/ bug or patch I'm looking at it, turnaround time sucks, and if you're looking at yours, likewise for you. That's what happens when there are thousands of yous and a handful of thems, all of the latter volunteering spare time. OTOH, turnaround time on Python bugs classified as critical is superb. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
In article [EMAIL PROTECTED], Giovanni Bajo [EMAIL PROTECTED] wrote: Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. IMO, regardless of whether you are trolling or flaming, you are certainly being disrespectful. Why should we treat you with any more respect than you give others? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Aahz wrote: Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. IMO, regardless of whether you are trolling or flaming, you are certainly being disrespectful. Why should we treat you with any more respect than you give others? Disrespectful? Because I say that I don't agree with some specific requirement, trying to discuss and understand the rationale behind it? -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Tim Peters wrote: None are /totally ignored/ -- indeed, at least I see every one as it comes in. You might want to change your claim to that no work obviously visible to you is done on them. That would be better. Please notice that my mail was in the context of user satisfaction with the bug tracker. I was claiming that it is useless to provide a blazingly fast support turnaround for technical issue, when there is no visibile work being done on most bugs that are submitted. And, in turn, this was in the context of hiring 6-10 people as the only acceptable minimum to maintain and admin a bug tracker. I was claiming that, if such a group was ever formed, it was better spent on bug triage rather than keeping their keys ready all day long to quick-fix any server breakage in minutes. These are the actual stats as of a few minutes ago: Bugs: 938 open of 7169 total ~= 87% closed Patches: 429 open of 3846 total ~= 89% closed Feature Requests: 240 open of 479 total ~= 50% closed I claimed different numbers based on personal perception; I stand corrected, and apologize for this. I could just say that my perception was wrong, but I guess there's something in it that could be further analyzed. For instance, I would be really curious to see how these figures look like if you consider only bugs/patches/rfe *NOT* submitted by python committers. I don't think Sourceforge can ever compute this number for us, so I'll wait to ask Roundup about it (or, uh, Jira...). There's an easy way to improve these percentages dramatically, although they're not bad as-is: run thru them and close every one that isn't entirely clear. For example, reject every feature request, close every patch that changes visible behavior not /clearly/ fixing a bona fide bug, and close every bug report that's really a feature request or random but Perl/Ruby/PHP doesn't do it this way complaint in disguise. Either close directly any nonsense, or ask for more feedback to the poster, until the bug/patch/rfe is sufficiently clear to be handled, or 3 months are passed and you close the bug for no further feedback from the poster. If this would dramatically reduce the number of open bugs, then yes, Python really needs someone to do bug triaging. For example, the oldest patch open today is a speculative implementation of rational numbers for Python. This is really a feature request in disguise, and has very little chance-- but not /no/ chance --of ever being accepted. The oldest bug open today is from 6 years ago, and looks like an easy-to-answer /question/ about the semantics of regular expressions in Python 1.6. I could take time to close that one now, but is that a /good/ use of time? Yes, but, at the moment, even finishing this reply seems to be a /better/ use of my time -- and after that, I'm going to get something to eat ;-) It might be not a good use of your time at all, since you are a developer. But having a database with 938 open bugs most of which are incomplete/nonsense/unconfirmed is much less useful than it could be. It also raises the bar for new developers: it's much harder to just pick one and fix it. I know because I tried sometimes, and after half an hour I couldn't find any bug that was interesting to me and complete enough to work on it. I also noticed that most bugs are totally uncommented like nobody cared at all. This is where my thought about Python missing bug triaging started. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni And, in turn, this was in the context of hiring 6-10 people as Giovanni the only acceptable minimum to maintain and admin a bug Giovanni tracker. Who said anything about hiring? I don't believe anyone expects any of the 6-10 people to work full-time (well, except for you it would appear). I help moderate a number of Python-related mailing lists hosted on mail.python.org. I also do a microscopic amount of bug triage for a couple smallish modules in the standard distribution, have pitched in a bit to help with the website (though don't anymore) and used to help a little bit with administration of the various python.org machines. I certainly have never spent anything approaching full-time for any of these tasks, not even when measured over short time periods. A few minutes here. An hour there. Many people contribute way more time to the overall endeavor than I do, and I applaud them for their dedication. I haven't ever been paid nor have I ever expected to be paid. It's a spare time activity, a way to contribute to Python even when I can't do more. At times I have come and gone as well, mostly depending on the constraints of work and family obligations and my instantaneous enthusiasm for the project. If I'd rather read a book, work on my car or watch TV, that's ok. I don't feel guilty for the idle time I don't spend working on Python. I know there are many other people there to cover for what little bit of work I am not doing. I suspect that is how most people approach any of the myriad tasks involved with getting Python out the door and keeping it current. I think that was also the intent of the 6-10 people phrase. If you have lots of people available to pitch in, no one person's absence is a show stopper. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: Aahz wrote: Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. IMO, regardless of whether you are trolling or flaming, you are certainly being disrespectful. Why should we treat you with any more respect than you give others? Disrespectful? Because I say that I don't agree with some specific requirement, trying to discuss and understand the rationale behind it? there's really not much to understand, just one thing: There are no rationales. This is a 'decision by feeling': http://groups.google.com/group/comp.lang.python/msg/0334d6ff60a48991 As for Mr. Holden... it's not a matter of not respecting you. It is in his nature to babble in this way. Sometimes it's even funny! . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ilias Lazaridis [EMAIL PROTECTED] writes: As for Mr. Holden... it's not a matter of not respecting you. It is in his nature to babble in this way. Sometimes it's even funny! Oh my. You have *seriously* misjudged this group if you think that comment will give you any net gain in discussions here. -- \ I think there is a world market for maybe five computers. -- | `\ Thomas Watson, chairman of IBM, 1943 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
In article [EMAIL PROTECTED], Giovanni Bajo [EMAIL PROTECTED] wrote: Aahz wrote: Giovanni removed his own attribution: Are you ever going to try and make a point which is not you are not entitled to have opinions because you do not act? Your sarcasm is getting annoying. And since I'm not trolling nor flaming, I think I deserve a little bit more of respect. IMO, regardless of whether you are trolling or flaming, you are certainly being disrespectful. Why should we treat you with any more respect than you give others? Disrespectful? Because I say that I don't agree with some specific requirement, trying to discuss and understand the rationale behind it? *snort* Now you're trying to dodge responsibility for your own words. Normally I'd be inclined to cut you some slack because English isn't your native language, but it's clear that you're deliberately trying to write emotionally to encourage other people to flail around. Here are again some of the things you've written in this thread: Does this smell Bitkeeper fiasco to anyone else than me? I am impressed you do not want to understand the why most bug reports submitted by users go totally ignored for several years, That adds up to a clear summation of disprespect in my view. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ilias Lazaridis wrote: You need just 2 active contributors - and the python community, not more Hmm, this number does not say much. It really depends on the required service level and how much time these two people can spend for maintaining the tracker service. Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: That, in principle, could happen to any other free software as well. What is critical here is that SF *hosted* the installation. If we would use a tracker that is free software, yet hosted it elsewhere, the same thing could happen: the hoster could make modifications to it which are non-free. Not even the GPL could protect from this case: the hoster would be required to publish source only if he publishes binaries, but he wouldn't publish any binaries, so he wouldn't need to release the source changes, either. Also, even if it the software is open source and unmodified, there still wouldn't be a guarantee that you can get the data out of it if you want to. You *only* get the advantages of free software if you also run it yourself. Unfortunately, there is a significant cost associated with running the software yourself. You have many good points here, Martin. Let me notice, though, that people providing hosting not necessarily want to maintain the software by themselves alone: some python developers could still have admin access to the boxes so to double check if weird things are being done behind the curtain. I think the point of uncertainty araises only if you totally trust someone else to do the job for you. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: Martin The regular admin tasks likely include stuff like this: Martin - the system is unavailable, bring it back to work Martin This is really the worst case, and a short response time Martin is the major factor in how users perceive the service Martin - the system is responding very slowly To all those people who have been moaning about needing 6-10 people to administer the system, in my opinion these are the most important reasons to have more than one person available to help. Python isn't only used in the USofA. It has been very helpful to have administrators scattered around the globe who were awake and alert to handle problems with python.org when folks in the US were asleep. Of course, spreading the load among several people helps with the other tasks as well. As Martin pointed out in an earlier post, with only one person actively administering Subversion (Martin), new requests for access had to wait if he was away for an extended period of time. This is true of many open source projects. I don't dispute that having 6-10 people to administer Roundup would not be good. I dispute that it is the minimum requirement to make a Roundup installation acceptable for Python development. Are bug-tracker configuration issues so critical that having to wait 48-72hrs to have them fixed is absolutely unacceptable for Python development? It looks like an overexaggeration. People easily cope with 2-3 days of SVN freezing, when they are politically (rather than technically) stopped from committing to SVN. I guess they can wait 48 hrs to be able to close that bug, or open that other one, or run that query. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo [EMAIL PROTECTED] writes: Are bug-tracker configuration issues so critical that having to wait 48-72hrs to have them fixed is absolutely unacceptable for Python development? It looks like an overexaggeration. People easily cope with 2-3 days of SVN freezing, when they are politically (rather than technically) stopped from committing to SVN. I guess they can wait 48 hrs to be able to close that bug, or open that other one, or run that query. How often should a tracker freeze anyway? People with no technical knowledge at all run BBS systems that almost never freeze. Is a tracker somehow more failure-prone? It's just a special purpose BBS, I'd have thought. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ian Bicking wrote: It handles some other kinds of repositories now (bzr, I think?). From what I understand fully abstracting out the repository format seems to still be a work in progress, but it is in progress and you can write repository plugins right now. That covers Trac, but other projects probably need to get up to speed with providing similar functionality, too. This is another case where people should work together rather than developing an interoperability layer specific to their own project. Certainly, the Bazaar APIs looked like some kind of promising umbrella project for that kind of thing. Trac now includes a WSGI backend, and someone has written a WSGI backend for ViewVC (though I don't know if it is included with the project). Clearly you need to get on the WSGI bandwagon ;) Hey, WebStack supports WSGI, too, you know. ;-) Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Rubin schrieb: How often should a tracker freeze anyway? People with no technical knowledge at all run BBS systems that almost never freeze. Is a tracker somehow more failure-prone? It's just a special purpose BBS, I'd have thought. For whatever reason, the SF bug tracker is often down, or not responding. I'm uncertain why that is, but it's a matter of fact that this was one of the driving forces in moving away from SF (so it is a real problem). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: For whatever reason, the SF bug tracker is often down, or not responding. I'm uncertain why that is, but it's a matter of fact that this was one of the driving forces in moving away from SF (so it is a real problem). As I asked before, did anyone look into asking large-scale users of the various considered products about their experiences with regard to reliability, scalability, and so on? Obviously, SourceForge is a special case since it's a closed service with a code base divergent from the last open source release (and possibly from commercial deployments of the code), whereas the other contenders except for Launchpad, along with non-considered but widely-deployed products, presumably contribute to a certain amount of public experience that can be drawn upon. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie schrieb: As I asked before, did anyone look into asking large-scale users of the various considered products about their experiences with regard to reliability, scalability, and so on? I didn't ask anyone, primarily because of lack of time. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul How often should a tracker freeze anyway? People with no Paul technical knowledge at all run BBS systems that almost never Paul freeze. Is a tracker somehow more failure-prone? It's just a Paul special purpose BBS, I'd have thought. And when those BBS systems get hacked they can be down for extended periods of time. I have an old Porsche and participate in the discussion forums at 914club.com. There is a team of admins to moderate the discussion forums, but just one guy to do the technical work. The site is powered by some common forum software package (really a modern day bbs). It gets hacked from time-to-time. When that happens, we're all left with the DTs while the board gets put back together. As for this question from Giovanni: Giovanni Are bug-tracker configuration issues so critical that having Giovanni to wait 48-72hrs to have them fixed is absolutely unacceptable Giovanni for Python development? Yes, I think that would put a crimp in things. The downtimes we see for the SourceForge tracker tend to be of much shorter duration than that (typically a few hours) and cause usually minor problems when they occur. For the tracker to be down for 2-3 days would make the developers temporarily blind to all outstanding bug reports and patches during that time and prevent non-developers from submitting new bugs, patches and comments. Those people might well forget about their desired submission altogether and not return to submit them once the tracker was back up. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: I am seriously concerned that the PSF infrastructure committee EVER considered non open-source applications for this. In fact, I thought that was an implicit requirement in the selection. The goal of the selection process is to support the work of the Python developers who have to actually *use* the bug tracking system, and support its upkeep. In accordance with the Zen of Python, Practicality beats purity. P.S. The Sourceforge tracker being used now and for the past several years isn't open source, either, so it's hardly an emergency to have an open source tracker *now*. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are bug-tracker configuration issues so critical that having to wait 48-72hrs to have them fixed is absolutely unacceptable for Python development? It looks like an overexaggeration. People easily cope with 2-3 days of SVN freezing, when they are politically (rather than technically) stopped from committing to SVN. I guess they can wait 48 hrs to be able to close that bug, or open that other one, or run that query. I think tracker downtime is quite possibly worse than repository downtime. The small group of developers with SVN commit privileges are committed enough to come back and commit their code a couple of days later. A member of the community wanting to make a bug report is less likely too. As it is, when SF is up, people think having to register or even log in is too much of a burden. When SF is down, people sometimes send tracker items to the pydev list instead, when means someone else (who?) has to put in the tracker or it gets lost. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Terry Reedy wrote: When SF is down, people sometimes send tracker items to the pydev list instead, when means someone else (who?) has to put in the tracker or it gets lost. According to Harald Armin Massa's PostgreSQL talk at EuroPython, the PostgreSQL people manage all their bugs via mailing lists. Given that trends in revision control point towards completely decentralised solutions, I wonder whether there's anything to learn from less centralised (or more flexible) approaches to bug management. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Michael Ströder wrote: Ilias Lazaridis wrote: You need just 2 active contributors - and the python community, not more Hmm, this number does not say much. It really depends on the required service level and how much time these two people can spend for maintaining the tracker service. that was not the essence of the sentence, see full context: [REQUOTE] You need just 2 active contributors - and the python community, not more (it's open source - so do some plumbing yourself, even if you are the Python Foundation). Alternatively, why don't you place an requirement active open source project which can process request from the foundation? Because this could have a negative influence on selecting Roundup? (this is the reverse selection process. Select the candidate and adjust the requirements). [/REQUOTE] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Jira is a remarkably well done product. We've adopted it internally and use it for project planning (we're doing Agile) as well as defect tracking. The plugin support and user interface just can't be touched by the competition and I've been looking. I'd prefer an open source python based system and maybe one day someone will make such a thing on top of django, turbo gears, or quixote but they're gonna have a lot of catching up to do. -- Ben Istvan Albert wrote: snip But this will definitely not happen over a short period of time and even in the worst case scenario there will be a few years in which the development can take place in an awesome environment. I've looked at the JIRA demo, and wow, it really seems like an amazingly cool way to do software development. snip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ben Finney wrote: David Goodger [EMAIL PROTECTED] writes: Look at the results again. Jira and RoundUp tied for functionality, but Jira has a hosting/admin offer behind it. That's huge. But rather than declaring Jira the outright winner, which they could have done, the committee has allowed the community to decide the matter. If enough admins come forward, RoundUp will win. I read that as a big push for written in Python. I prefer to read it as a big push for not dependent on non-free tools. And I'd prefer it if you'd drop this subject. So, if you have nothing new to say, kindly leave it. You have made your opinion known, as you are fully entitled to do. Frankly I am getting less interested in your opinion with each new post. You appear to be prepared to go to any length short of providing effort to support the open source tracker. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: You appear to be prepared to go to any length short of providing effort to support the open source tracker. http://www.userland.com/whatIsStopEnergy /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Terry Reedy wrote: Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The whole point of moving *from* SF *to* another bug tracker is to improve the situation, surely. The current situation is that the limitations and intermittant failures of the SF tracker sufficiently impede the Python development process that some people were motivated to do the work to find a better alternative. You already seem to acknowledge that using free-software tools to develop Python is desirable. The committee already said so by saying that with other things equal, it would choose Roundup. I don't see why you're being so obtuse I think name calling is out of line here. Correct, besides which Ben seems to feel people are disagreeing on the desirability of using open source software when in fact they are mostly disagreeing about the *practicality* in this particular instance. Compellingly absent from most critics' output is a statement to the effect that they will volunteer their time to encourage the adoption of Roundup, which is excluded only by the absence of a support infrastructure. Time to shit or get off the pot, I'd say. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: Steve Holden wrote: you're not on the infrastructure list, I hear. python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to con- tribute manhours. don't underestimate the community. No, I'm not on the infrastructure list, but I know that capable people *are*: and you know I am quite capable of donating my time to the cause, when I have it to spare (and sometimes even when I don't). what I was trying to say (between the lines) was that not only have the people on that list worked hard to do the evaluation (not to mention all the developers around the world that has worked even harder to set up test trackers), there's also been a good community response to the committee's call for 6-10 volunteers. Excellent. I've just complained elsewhere in this thread that those dissenting didn't appear to want to rectify the situation by offering their time. It would be nice to be wrong about that. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ilias Lazaridis wrote: Giovanni Bajo wrote: Hello, I just read this mail by Brett Cannon: http://mail.python.org/pipermail/python-dev/2006-October/069139.html where the PSF infrastracture committee, after weeks of evaluation, recommends using a non open source tracker (called JIRA - never heard before of course) for Python itself. Does this smell Bitkeeper fiasco to anyone else than me? -- Giovanni Bajo Fascinating. The python foundation suggests a non-python non-open-source bugtracking tool for python. It's like saying: The python community is not able to produce the tools needed to drive development of python forward. Anyway. The whole selection process is intransparent. The commitee should have stated goals and requirements with a public verification of the tools against them. Is there any stick in the known universe that you will grasp the *right* end of? http://wiki.python.org/moin/OriginalCallForTrackers regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: Excellent. I've just complained elsewhere in this thread that those dissenting didn't appear to want to rectify the situation by offering their time. It would be nice to be wrong about that. the dissenting won't contribute a thing, of course. they never ever do. but not everyone is wired that way. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden [EMAIL PROTECTED] writes: And I'd prefer it if you'd drop this subject. So, if you have nothing new to say, kindly leave it. I'm happy to, but: You appear to be prepared to go to any length short of providing effort to support the open source tracker. This was addressed in a previous post. I don't have the skills nor the resources to do this. Yes, as has been pointed out, it actually *is* far less effort to point out problems, than to solve them. That doesn't detract from the value of pointing out problems. This thread was started on the shock of realising that a non-free tool was even being *considered* for the new Python bug tracker. Those are the terms on which I've been arguing. Apparently there are some people who *have* put themselves forward to support a free-software tool. Great! My point all along has been that Python's developers are well advised to consider *only* free-software tools for supporting development of Python, and that from among those the best tool for the job should be chosen. As you say, nothing new has been said now for a while, so in the absence of that I'm happy to leave it here. -- \Why, I'd horse-whip you if I had a horse. -- Groucho Marx | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[Ben Finney] I don't see why you're being so obtuse [Terry Reedy] I think name calling is out of line here. Name calling is always out of line on comp.lang.python. Unless it's done by Guido. Then it's OK. Anyone else, just remind them that even Hitler had better manners. That always calms things down again. loving-usenet-despite-that-it's-usenet-ly y'rs - tim -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ben Finney wrote: Steve Holden [EMAIL PROTECTED] writes: And I'd prefer it if you'd drop this subject. So, if you have nothing new to say, kindly leave it. I'm happy to, but: You appear to be prepared to go to any length short of providing effort to support the open source tracker. This was addressed in a previous post. I don't have the skills nor the resources to do this. Yes, as has been pointed out, it actually *is* far less effort to point out problems, than to solve them. That doesn't detract from the value of pointing out problems. This thread was started on the shock of realising that a non-free tool was even being *considered* for the new Python bug tracker. Those are the terms on which I've been arguing. Apparently there are some people who *have* put themselves forward to support a free-software tool. Great! My point all along has been that Python's developers are well advised to consider *only* free-software tools for supporting development of Python, and that from among those the best tool for the job should be chosen. As you say, nothing new has been said now for a while, so in the absence of that I'm happy to leave it here. In case readers are puzzled by the absence of the message to which Ben replies above I should perhaps explain that I cancelled it having decided that its language was immoderate and unfair to Ben. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ilias Lazaridis wrote: Giovanni Bajo wrote: Hello, I just read this mail by Brett Cannon: http://mail.python.org/pipermail/python-dev/2006-October/069139.html where the PSF infrastracture committee, after weeks of evaluation, recommends using a non open source tracker (called JIRA - never heard before of course) for Python itself. Does this smell Bitkeeper fiasco to anyone else than me? -- Giovanni Bajo Fascinating. The python foundation suggests a non-python non-open-source bugtracking tool for python. Actually, it suggests two bugtracking tools, one of them written in Python. It's like saying: The python community is not able to produce the tools needed to drive development of python forward. No, it's saying: if the Python community is able to provide the required amount of time to do the admin work, we'll use the tool written in Python. Anyway. The whole selection process is intransparent. Steve has already pointed you to the wiki page. Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Georg Brandl wrote: The python foundation suggests a non-python non-open-source bugtracking tool for python. Actually, it suggests two bugtracking tools, one of them written in Python. the announcemant's subject line said recommendation for a new issue tracker, though; not we need the community's help before we can make a final recommendation. in fact, only 20% of the announcement talked about Python; the rest was something that looked a lot like a press release from the non-python hosting company, so it's not that strange that people missed the few sentences in the middle that explained that the subject line wasn't entirely accurate. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: Georg Brandl wrote: The python foundation suggests a non-python non-open-source bugtracking tool for python. Actually, it suggests two bugtracking tools, one of them written in Python. the announcemant's subject line said recommendation for a new issue tracker, though; not we need the community's help before we can make a final recommendation. Granted. in fact, only 20% of the announcement talked about Python; the rest was something that looked a lot like a press release from the non-python hosting company, so it's not that strange that people missed the few sentences in the middle that explained that the subject line wasn't entirely accurate. I actually stopped reading after Brett's signature, so I didn't have the 20% figure in my mind :) Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: In fact, are you absolutely positive that you need so much effort to maintain an existing bugtracker installation? I know for sure that GCC's Bugzilla installation is pretty much on its own; Daniel Berlin does some maintainance every once in a while (upgrading when new versions are out, applying or writing some patches for most requested features in the community, or sutff like that), but it's surely not his job, not even part-time. Daniel Berlin has put a tremendous amount of work into it. I know, because I set up the first bug tracker for gcc (using GNATS), and have been followed the several years of pondering fairly closely. It was quite some work to set up GNATS, and it was even more work to setup bugzilla. For Python, we don't have any person similar to Daniel Berlin (actually, we have several who *could* have done similar work, but none that ever volunteered to do it). Don't underestimate the work of somebody else. Martin, I am by no means understimating Daniel's work. I am just noting that the spare-time work he did is, by definition, much much lower than the 6-10 people that the PSF infrastructure committee is calling for. I would like this statement to be officially reduced to 2-3 people, since it is *really* not required much more than that to setup a bug tracker installation, and no more than 1 person to maintain it afterwards. *IF* there are more volunteers, that's good, they can offload the maintenance work from a single maintainer; but I think it's unfair to put such a high *requisite*. We do not have 6-10 people maintaining SVN afterall, even if you wish we had :) -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Ben This thread was started on the shock of realising that a non-free Ben tool was even being *considered* for the new Python bug Ben tracker. Those are the terms on which I've been arguing. Of course, the candidate trackers have been known for months. Messages have been posted to both this list and python-dev asking for inputs. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: Martin, I am by no means understimating Daniel's work. I am just noting that the spare-time work he did is, by definition, much much lower than the 6-10 people that the PSF infrastructure committee is calling for. I would like this statement to be officially reduced to 2-3 people, since it is *really* not required much more than that to setup a bug tracker installation, and no more than 1 person to maintain it afterwards. Glancing over this thread I wonder what these people are supposed to do. Any list of requirements available? Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Michael Ströder wrote: Glancing over this thread I wonder what these people are supposed to do. Any list of requirements available? from the original announcement (linked from the first post in this thread): In order for Roundup to be considered equivalent in terms of an overall tracker package there needs to be a sufficient number of volunteer admins (roughly 6 - 10 people) who can help set up and maintain the Roundup installation. /.../ If people want Roundup to be considered the tracker we go with by volunteering to be an admin, please email infrastructure at python.org and state your time commitment, the timezone you would be working from, and your level of Roundup knowledge. Please email the committee by October 16. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Michael Ströder schrieb: Martin, I am by no means understimating Daniel's work. I am just noting that the spare-time work he did is, by definition, much much lower than the 6-10 people that the PSF infrastructure committee is calling for. I would like this statement to be officially reduced to 2-3 people, since it is *really* not required much more than that to setup a bug tracker installation, and no more than 1 person to maintain it afterwards. Glancing over this thread I wonder what these people are supposed to do. Any list of requirements available? Anybody can help who has general experience with server administration; if you do, you know what typical problems are. In addition, you either should know how roundup works already, or should be willing to learn it as you go (from the fellow volunteers who have more insights). I can't personally anticipate what problems occur; it's only clear that the volunteers should just make it work. The regular admin tasks likely include stuff like this: - the system is unavailable, bring it back to work This is really the worst case, and a short response time is the major factor in how users perceive the service - the system is responding very slowly - when I do this operation, it doesn't work or when I do this operation, I get that error - why does this f*cking system require me to do foo, I don't want that There might also be the need for regular maintenance. Ad hoc, the only thing that comes to mind is user account maintenance: what users get what permissions. Traditionally (because of the SF model), Python committers get admin rights on the tracker, i.e. the right to close issues they didn't create. Not sure what the best model is for Roundup (roundup expertise is needed to propose an appropriate access control model). Other regular maintenance might involve spam removal; ideally, this would be minimal due to a well-thought access control. Finally, there might be a need for customization, perhaps by means of implementing new features. Clearly, whether features can be implemented depends on the amount of volunteer time available and neede, and also on the importance of the requested feature. For example, in SF, we requested that the Check to upload button is removed; it took SF several years to implement that request. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: Ilias Lazaridis wrote: Giovanni Bajo wrote: Hello, I just read this mail by Brett Cannon: http://mail.python.org/pipermail/python-dev/2006-October/069139.html where the PSF infrastracture committee, after weeks of evaluation, recommends using a non open source tracker (called JIRA - never heard before of course) for Python itself. Does this smell Bitkeeper fiasco to anyone else than me? -- Giovanni Bajo Fascinating. The python foundation suggests a non-python non-open-source bugtracking tool for python. It's like saying: The python community is not able to produce the tools needed to drive development of python forward. Anyway. The whole selection process is intransparent. The commitee should have stated goals and requirements with a public verification of the tools against them. Is there any stick in the known universe that you will grasp the *right* end of? http://wiki.python.org/moin/OriginalCallForTrackers Please have a little bit more precision: Because we are not sure exactly what are requirements for a tracker are we do not have a comprehensive requirements document. http://wiki.python.org/moin/OriginalCallForTrackers This document is empty: http://wiki.python.org/moin/GoodTrackerFeatures This is what I call intransparent selection process or selectiong by feelings. - The central requirement for a development-infrastructure / Host is _control_: http://case.lazaridis.com/wiki/Host My personal selection for a tracking-system for a python based projects is Trac: http://case.lazaridis.com/wiki/Tracking I context of the python project (which has own wiki), Roundup could become the No.1 choice. I am biased towards trac, but to be honest, I've not verified Roundup deeper (due to the missing wiki-svn-ticket-integration, which is Trac's major strength). So, define the Goals, specify the resulting Requirements, and _after_ this, verify the Tools (Trac, Roundup) against those requirements - otherwise the whole comitee thing becomes just a joke. Another joke is to 'scare' the community with a non-open-source java tracker, in order to get 6 to 10 contributors. You need just 2 active contributors - and the python community, not more (it's open source - so do some plumbing yourself, even if you are the Python Foundation). Alternatively, why don't you place an requirement active open source project which can process request from the foundation? Because this could have a negative influence on selecting Roundup? (this is the reverse selection process. Select the candidate and adjust the requirements). In any way, the 'comitee' should really stop talking about JIRA in context of python. This sounds really like a joke of bad taste. btw: If JIRA is selected finally, the I have really to revise my decision to choose python for my projects. Simply because I would be afraid that the Python Foundation can't move Python into a leading position. http://case.lazaridis.com/wiki/Lang - btw: I like both tools, JIRA (nice design) and Roundup (simplicity, db layer) . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin The regular admin tasks likely include stuff like this: Martin - the system is unavailable, bring it back to work Martin This is really the worst case, and a short response time Martin is the major factor in how users perceive the service Martin - the system is responding very slowly To all those people who have been moaning about needing 6-10 people to administer the system, in my opinion these are the most important reasons to have more than one person available to help. Python isn't only used in the USofA. It has been very helpful to have administrators scattered around the globe who were awake and alert to handle problems with python.org when folks in the US were asleep. Of course, spreading the load among several people helps with the other tasks as well. As Martin pointed out in an earlier post, with only one person actively administering Subversion (Martin), new requests for access had to wait if he was away for an extended period of time. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie wrote: Perhaps, although I imagine that Trac would have a lot more uptake if it handled more than just Subversion repositories. It handles some other kinds of repositories now (bzr, I think?). From what I understand fully abstracting out the repository format seems to still be a work in progress, but it is in progress and you can write repository plugins right now. [...] I did briefly look at Trac to see whether I could hack in a WebStack backend, and I'd do the same for ViewVC if I had the time, mostly because such projects already duplicate a lot of effort just to permit the deployment of the software on incompatible server solutions. There's certainly a lot these solutions could learn from each other and from lesser known solutions. Trac now includes a WSGI backend, and someone has written a WSGI backend for ViewVC (though I don't know if it is included with the project). Clearly you need to get on the WSGI bandwagon ;) Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Rubin schrieb: Martin v. Löwis [EMAIL PROTECTED] writes: It is a fork of an old version. Existence of this version hasn't helped a bit when we tried to get our data out of sf.net. Yeah, I'd guessed it might be a fork. Is there stuff in sf.net that a web robot can't retrieve? We ended up getting the data with a web robot. There were two problems: 1. SF times out all the time, and fetching the data takes quite some time (not sure how long Fredrik Lundh needed, but I recall that Richard Jones once needed several days to get all data). There is also the theory that SF will lock out clients that fetch data at a too-high rate, so when you get locked out, you need to wait some time until you can continue; what rate is acceptable is not documented. 2. The web view gets HTML wrong in many places; things are rendered as HTML entity references when really the character should be displayed itself; non-ASCII characters don't work well. It might be that having the raw data would allow for better quality. There used to be another problem that SF was inconsistent on displaying user names (sometimes, account names were displayed, and sometimes real names), but that seems not to be a problem anymore. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: I hope this recommendation from the PSF infrastructure committee is rejected. That is very very unlikely. Who would reject it, and why? The community, and I am impressed you do not want to understand the why. It is an extremely bad picture for an open source flag like Python to go to a vendor for such an easy requirement as a bug database. I am seriously concerned that the PSF infrastructure committee EVER considered non open-source applications for this. In fact, I thought that was an implicit requirement in the selection. There are many open source applications around. They might not be the best, but at least they are yours, and not of some third party software vendors with its own interests. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: that's just not true. lots of people have voiced concerns over using closed-sourced stuff originally designed for enterprise-level Java users for an application domain where Python has several widely used agile alternatives to chose from. Frankly, I don't give a damn about the language the application is coded in, as long as it is OUR application and not an application of a private company which we do not own. Even though you are totally right. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: Giovanni Bajo wrote: Does this smell Bitkeeper fiasco to anyone else than me? I can't understand why people waste time arguing this stuff. Use whatever tool is best at it's job... if it's not written in Python it doesn't mean that Python is not good for the task, only that there hasn't been any Python programmer that applied himself to the problem hard enough. This is not against using a tool not written in Java. This is against using a tool which is not FLOSS. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
A.M. Kuchling wrote: ... using a non open source tracker (called JIRA - never heard before of course) for Python itself. Other projects do use it; see http://wiki.apache.org/general/ApacheJira for a partial list, and a link to the Apache Software Foundation's issue trackers. which, in my humble opinion, is just a list of other examples of projects which are misguided. People seem to have no idea when a company is sold, when a CEO is changed, or something like that. Hhistory's repeating, but hackers are not learning. Does this smell Bitkeeper fiasco to anyone else than me? The committee did expect this recommendation to be controversial. :) I guess :) In fact, I have a deepest hope that this recommendation was just a fake just to get people setup a roundup installation... -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Martin v. Löwis wrote: It's significantly different from the Bitkeeper fiasco in two important ways: 1. Bitkeeper is a source revisioning system, so it is similar to CVS and Subversion. This project here is just the bug tracker, which is of lesser importance. If we move to a different one some day, a certain amount of data lossage might be acceptable (e.g. we now likely lose the history of status changes and file attachments on each report). An export of all data is high on the requirements list, as Fredrik points out. I understand your point. OTOH, exactly because the tracker system is a far lesser importance, it's amazing there is *ever* a need to evaluate non-FLOSS solutions, when there are so many good free solutions around. Instead of recommending a closed source solution, you could have recommended Roundup *and* explained there is a need for funding and/or volunteers before the migration can happen. You might also be understimating how negative could be the reaction from the open-source community to such a move. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: And i dunno what the case against Trac is (it looks a fine tool for my small projects) but probably it's not good enough for python.org Trac is really good in my experience. http://trac.edgewall.org/ Python.org has already moved to svn so trac is surely the next part of the equation. Having an integrated Bugtracker / Wiki / Svn repository browser is very helpful. We use it for all our commercial work. It is also in use by MythTV which judging by the volume of its mailing lists is about or more active a project than python. http://svn.mythtv.org/trac/ A nice extra is that it is written in python. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Nick Craig-Wood wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: And i dunno what the case against Trac is (it looks a fine tool for my small projects) but probably it's not good enough for python.org Trac is really good in my experience. Trac was considered. A nice extra is that it is written in python. So are Roundup and Launchpad, two of the other three trackers considered. Richard -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
On 10/4/06, Richard Jones [EMAIL PROTECTED] wrote: Nick Craig-Wood wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: And i dunno what the case against Trac is (it looks a fine tool for my small projects) but probably it's not good enough for python.org Trac is really good in my experience. Trac was considered. A nice extra is that it is written in python. So are Roundup and Launchpad, two of the other three trackers considered. So, just out of curiosity, what were the pros/cons of Launchpad, specially compared to Roundup? R. Richard -- http://mail.python.org/mailman/listinfo/python-list -- Ramon Diaz-Uriarte Bioinformatics Unit Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: A.M. Kuchling wrote: ... using a non open source tracker (called JIRA - never heard before of course) for Python itself. Other projects do use it; see http://wiki.apache.org/general/ApacheJira for a partial list, and a link to the Apache Software Foundation's issue trackers. which, in my humble opinion, is just a list of other examples of projects which are misguided. People seem to have no idea when a company is sold, when a CEO is changed, or something like that. Hhistory's repeating, but hackers are not learning. Does this smell Bitkeeper fiasco to anyone else than me? The committee did expect this recommendation to be controversial. :) I guess :) In fact, I have a deepest hope that this recommendation was just a fake just to get people setup a roundup installation... But sadly people are much happier complaining on c.l.py than exerting themselves to support the community with an open source issue tracker. Hello, Jira regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Richard Jones wrote: Nick Craig-Wood wrote: Trac is really good in my experience. Trac was considered. A nice extra is that it is written in python. So are Roundup and Launchpad, two of the other three trackers considered. It should be noted that most skepticism (that I'm aware of) about Launchpad is typically rooted in that service's closed source nature. People voicing such skepticism don't seem to cut it any slack just because it is apparently written in Python. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: But sadly people are much happier complaining on c.l.py than exerting themselves to support the community with an open source issue tracker. you're not on the infrastructure list, I hear. python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to con- tribute manhours. don't underestimate the community. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
On Wed, 04 Oct 2006 07:37:47 GMT, Giovanni Bajo [EMAIL PROTECTED] wrote: I am seriously concerned that the PSF infrastructure committee EVER considered non open-source applications for this. In fact, I thought that was an implicit requirement in the selection. Being open source wasn't a requirement; minimal requirements were specified in the initial message requesting trackers (http://wiki.python.org/moin/OriginalCallForTrackers). --amk -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
A.M. Kuchling wrote: I am seriously concerned that the PSF infrastructure committee EVER considered non open-source applications for this. In fact, I thought that was an implicit requirement in the selection. Being open source wasn't a requirement; which is, indeed, shocking and amazing. minimal requirements were specified in the initial message requesting trackers (http://wiki.python.org/moin/OriginalCallForTrackers). Where does it mention that only trackers which have at least an existing installation and a group of people for maintenance will be considered? It could easily be assumed that PSF had already enough bandwidth, server, manpower to handle any bugtracker installation. In fact, are you absolutely positive that you need so much effort to maintain an existing bugtracker installation? I know for sure that GCC's Bugzilla installation is pretty much on its own; Daniel Berlin does some maintainance every once in a while (upgrading when new versions are out, applying or writing some patches for most requested features in the community, or sutff like that), but it's surely not his job, not even part-time. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: In fact, are you absolutely positive that you need so much effort to maintain an existing bugtracker installation? I wonder what kinds of insights were sought from other open source projects. It's not as if there aren't any big open source projects having approachable community members willing to share their thoughts on running open source (or any other kind of) issue tracking software. KDE and GNOME don't use SourceForge and yet manage their own infrastructure - has anyone asked them how they do it? Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: Steve Holden wrote: But sadly people are much happier complaining on c.l.py than exerting themselves to support the community with an open source issue tracker. you're not on the infrastructure list, I hear. python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to con- tribute manhours. don't underestimate the community. No, I'm not on the infrastructure list, but I know that capable people *are*: and you know I am quite capable of donating my time to the cause, when I have it to spare (and sometimes even when I don't). Perhaps what I *should* have written was Sadly *many* people spend too much time bitching and moaning about those that roll their sleeves up, and not enough rolling their own sleeves up and pitching in. Sniping from the sidelines is far easier than hard work towards a goal. Kindly note that none of the above remarks apply to you. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Terry Reedy [EMAIL PROTECTED] wrote: As I understood B.C.'s announcement, that was one of the judging criteria, and the plan is for PSF to get a daily backup dump of the data. This had nothing to do with the choice of not using Trac or Launchpad. Quoting Brett Cannon from the original mail: As for Trac and Launchpad, both had fundamental issues that led to them not being chosen in the end. Most of the considerations had to do with customization or UI problems. So clearly the 'get a daily backup of the data' is not the reason. Backing up a sqlite database is pretty easy. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden [EMAIL PROTECTED] writes: Sniping from the sidelines is far easier than hard work towards a goal. Right now there is not even agreement on what the goal is. The surprise people are expressing is because they thought one of the goals of a big open source project would be to avoid reliance on closed tools. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker? - Trac?
Fredrik Lundh [EMAIL PROTECTED] writes: Steve Holden wrote: But sadly people are much happier complaining on c.l.py than exerting themselves to support the community with an open source issue tracker. you're not on the infrastructure list, I hear. python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to con- tribute manhours. don't underestimate the community. /F I'm not on the infrastructure list either. But I wonder why it is Roundup or else non-python COTS? I gave up on Roundup a while ago due to too many crashes. I'm now using Trac: a) Open Source b) Python c) Adequate functionality (for me at least) http://trac.edgewall.org/ I'm not trying to sell Trac, but I would like to know what drove the developers away from it. -- Harry George PLM Engineering Architecture -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie wrote: Giovanni Bajo wrote: In fact, are you absolutely positive that you need so much effort to maintain an existing bugtracker installation? I wonder what kinds of insights were sought from other open source projects. It's not as if there aren't any big open source projects having approachable community members willing to share their thoughts on running open source (or any other kind of) issue tracking software. KDE and GNOME don't use SourceForge and yet manage their own infrastructure - has anyone asked them how they do it? Paul Right, we could have asked Linus for advice ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Valentino Volonghi aka Dialtone wrote: Terry Reedy [EMAIL PROTECTED] wrote: As I understood B.C.'s announcement, that was one of the judging criteria, and the plan is for PSF to get a daily backup dump of the data. This had nothing to do with the choice of not using Trac or Launchpad. Quoting Brett Cannon from the original mail: As for Trac and Launchpad, both had fundamental issues that led to them not being chosen in the end. Most of the considerations had to do with customization or UI problems. So clearly the 'get a daily backup of the data' is not the reason. Backing up a sqlite database is pretty easy. Do you have any idea fo the scale of the Python issue (bug) database? Do you really think SQLite would be a suitable platform for it? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden [EMAIL PROTECTED] wrote: So clearly the 'get a daily backup of the data' is not the reason. Backing up a sqlite database is pretty easy. Do you have any idea fo the scale of the Python issue (bug) database? Do you really think SQLite would be a suitable platform for it? Considering that trac can also run on postgres or mysql and also considering that both of these databases have enough tools to deal with backups I think it's a non issue. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Valentino Volonghi wrote: Considering that trac can also run on postgres or mysql and also considering that both of these databases have enough tools to deal with backups I think it's a non issue. 10k entries shouldn't be much of an issue for sqlite3 either. (I don't think any of the proposed solutions would have a *capacity* problem. afaict, the main argument was that trac and launchpad simply isn't quite as con- figurable as the others. which doesn't have to be a bad thing, really -- effient bug handling is more about process than technology. the best issue tracking system I've ever used wasn't even designed for issue tracking...) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: Valentino Volonghi wrote: Considering that trac can also run on postgres or mysql and also considering that both of these databases have enough tools to deal with backups I think it's a non issue. 10k entries shouldn't be much of an issue for sqlite3 either. Out of interest, here are some figures: KDE: 12983 bugs and 11656 wishes GNOME: 23624 reports Python: 7159 bugs, 3843 patches, 477 feature requests The Python figures are totals, whereas I can't be sure whether the KDE and GNOME figures merely refer to the open issues. Nevertheless, Python isn't going to be pushing the envelope. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: I understand your point. OTOH, exactly because the tracker system is a far lesser importance, it's amazing there is *ever* a need to evaluate non-FLOSS solutions, when there are so many good free solutions around. Instead of I think you are missing the point. Switching to a different tracker is not such a big deal. Having a really good tracker is a big deal. Trackers are all about usability. Alas most open source projects suck at that while excel in implementation and performance. FWIW I'd rather have the PSF even pay for good quality tracker since that benefits everyone rather than funding some obscure project that only 1% of the programmers will use/heard of. Istvan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni In fact, are you absolutely positive that you need so much Giovanni effort to maintain an existing bugtracker installation? The development group's experience with SF and I think to a lesser extent, Roundup in its early days, and more generally with other components of the development toolchain (source code control) and python.org website maintenance suggests that some human needs to be responsible for each key piece of technology. Maybe when it's mature it needs very little manpower to maintain, but a substantial investment is required when the technology is first installed. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Istvan I think you are missing the point. Switching to a different Istvan tracker is not such a big deal. Having a really good tracker is Istvan a big deal. No, actually switching trackers can be one big pain in the ass. You probably aren't aware of how hard it's been for the Python development team (I think Martin v. Loewis, mostly) to get tracker data out of SF. An explicit requirement was that any tool chosen as a SF replacement be able to easily export its database to avoid this sort of lock-in in the future. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: Giovanni In fact, are you absolutely positive that you need so much Giovanni effort to maintain an existing bugtracker installation? The development group's experience with SF and I think to a lesser extent, Roundup in its early days, and more generally with other components of the development toolchain (source code control) and python.org website maintenance suggests that some human needs to be responsible for each key piece of technology. Maybe when it's mature it needs very little manpower to maintain, but a substantial investment is required when the technology is first installed. One thing is asking for a special help during the transition phase and the landing phase (the first few months). Another thing is asking for roughly 6-10 people to install and maintain a Roundup installation. This is simply not going to realistically happen, and I find it incredible for the PSF committee to ask for such a high request. Damn, we don't have roughly 6-10 people in charge of reviewing patches or fixing bugs. I followed the GNATS - Bugzilla transition myself closely, and a single person (Daniel Berlin) was able to setup the Bugzilla server on the gcc.gnu.org computer, convince everybody that a transition was needed (and believe me, this was a hard work), patch it as much as needed to face the needs of the incredibly picky GCC developers (asking for every little almost-unused-and-obsoleted feature in GNATS to be replicated in Bugzilla), and later maintain the installation. It took him approximately one year to do this, and surely it wasn't full time. After that, he maintains and administer the Bugzilla installation on his own, by providing upgrades when needed and a few modifications. I wonder why the PSF infrastructure committee believes that a group of 6-10 people is needed to install and maintain Roundup. Let us also consider that Roundup's lead developer *was* part of the PSF infrastrucutre committee, and he might be willing to help in the transition (just my very wild guess), and he obviously knows his stuff. Also, given the requirement for the selection, there is already a running roundup installation somewhere (so the whole pipeline export - import has already been estabilished and confirmed to work). My own opinion is that a couple of person can manage the transition/migration phase to *any* other bug tracking system, and provide support in the python-dev mailing list. After the whole thing has fully landed, I'd be really surprised if a single appointed maintainer would not be enough. If the PSF committee lowers its requests to a more realistical amount of effort, I'm sure we will see many more people willing to help. I think many people (including myself) would be willing to half-half-help with loose ends, but when faced with an abnormous 6-10 people request they just shut up and sit in a corner. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Steve Holden wrote: No, I'm not on the infrastructure list, but I know that capable people *are*: and you know I am quite capable of donating my time to the cause, when I have it to spare (and sometimes even when I don't). Perhaps what I *should* have written was Sadly *many* people spend too much time bitching and moaning about those that roll their sleeves up, and not enough rolling their own sleeves up and pitching in. Sniping from the sidelines is far easier than hard work towards a goal. Kindly note that none of the above remarks apply to you. The current request is: please, readers of python-dev, setup a team of 6-10 people to handle roundup or we'll go to a non-free software for bug tracking. This is something which I cannot cope with, and I'm *speaking* up against. Were the request lowered to something more reasonable, I'd be willing to *act*. I have to speak before acting, so that my acting can produce a result. And besides the only thing I'm really sniping the PSF against is about *ever* having thought of non-FLOSS software. This is something I *really* do not accept. You have not seen a mail from me with random moaning as Trac is better, Bugzilla is better, why this was chosen. I do respect the fact that the PSF committee did a thorough and correct evaluation: I just disagree with their initial requirements (and I have not raised this point before because, believe me if you can, I really thought it was obvious and implicit). So, if your remarks apply to me, I think you are misrepresenting my mails and my goals. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: Hello, I just read this mail by Brett Cannon: http://mail.python.org/pipermail/python-dev/2006-October/069139.html where the PSF infrastracture committee, after weeks of evaluation, recommends using a non open source tracker (called JIRA - never heard before of course) for Python itself. Does this smell Bitkeeper fiasco to anyone else than me? -- Giovanni Bajo No just ignorance you your part! Jira is given away for free to open source projects that want to use it. And it just happens to be one of the best issue trackers on the market, free or paid or opens source or not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
On 04 Oct 2006 06:44:24 -0700, Paul Rubin wrote: Right now there is not even agreement on what the goal is. The goal is a new tracker for python.org that the developers like better; the original call lists 3 reasons (bad interface; lack of reliability; lack of workflow controls). The surprise people are expressing is because they thought one of the goals of a big open source project would be to avoid reliance on closed tools. I don't think Python has ever had this as a goal. Python's license lets it be embedded in closed-source products; Windows binaries are built using closed-source tools (MS Visual C), and on some platforms we use a closed-source system compiler; python.org used to be a Solaris box, and now uses SourceForge which runs on top of DB/2... IMHO, using Jira presents risks that are manageable: * A data export is available if we decide to switch. Writing a script to take this export and convert to a new tracker is non-trivial, but the same is true of any other tracker we might choose; switching from Roundup to Trac or Trac to Launchpad is also going to require some effort. Therefore, I don't think our data is locked-in any more than any other tracker. * The offer of hosting means this won't consume very much administrative time. Perhaps the hosting offered will be found to be unreliable. If that's the case, we can reconsider the choice of tracker, or (less likely) host Jira ourselves. * There are no Bitkeeper-like licensing issues like the non-compete clause, so that isn't a factor; Roundup and Trac developers can file bugs and use the tracker just like anyone else. * The interface is very flexible and lots of customization can be done through the web. This means we don't have to hack the code at all, and upgrades should theoretically go smoothly. It would be nice to have the additional tick-box feature 'is open source', but the upsides are large enough that I can let go of that issue with only slight regret. --amk -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: The current request is: please, readers of python-dev, setup a team of 6-10 people to handle roundup or we'll go to a non-free software for bug tracking. Actually, it would appear that the request goes out to comp.lang.python/python-list as well (ie. the ungrateful plebs like myself who supposedly have nothing to contribute to the direction of the Python project). [...] And besides the only thing I'm really sniping the PSF against is about *ever* having thought of non-FLOSS software. It has already been brought up that Python plays well with everyone and everything, and thus a closed source tool projects the attitudes of the core developers. However, in contrast to the use of tools such as Roundup which have some advocacy value, the adoption of commercial products often works largely in favour of the vendor: they're seen to be helpful and charitable (which they may well be), and there's a certain level of publicity value generated from the transaction (albeit not as much as if the Bugzilla project switched over to a closed source issue tracker). Of course, this message so far probably passes for being political in the eyes of certain people, but I think it's interesting to put such decisions in the context of the calls to advocacy that people come out with every now and again. Indeed, I believe that the PSF now have an advocacy coordinator to lead the onslaught selling Python into business or whatever people regard Python advocacy to be these days. However, as an open source project it doesn't necessarily send a good message to business that the amazing processes that drive Python development are powered by closed source software (although they also have been through the use of SourceForge) and that the developers passed over a project that they were quite happy to use promotionally once upon a time. Indeed, while it was still running, the Software Carpentry competition (the initiative which led to the development of Roundup) was potent publicity material showing that Python and open source development produce great software. The risk is that business looks at the level of self-belief (don't mention the competition by name [1], but where the competition isn't just other languages: it's also other development methodologies) and wonders whether they wouldn't be better off with some closed source development environment for their closed source commercial product instead. I guess what plebs like myself are supposed to take away from this is the following: if the core developers are subsequently much more productive developing the language (which is not exactly the thing which requires most attention in the Python distribution these days, in my opinion), then who are we to complain as long as we can still stuff our bugs into some Web-based interface or other? Paul [1] http://holdenweb.blogspot.com/2006/03/marketing-why-do-you-use-python.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Giovanni Bajo wrote: The current request is: please, readers of python-dev, setup a team of 6-10 people to handle roundup or we'll go to a non-free software for bug tracking. This is something which I cannot cope with, and I'm *speaking* up against. Were the request lowered to something more reasonable, I'd be willing to *act*. No, the announcement stated the situation in a very different way. Asking for a group of maintainers to commit to an essential piece of infrastructure is perfectly reasonable. Brett didn't ask for 6-10 full time developer/sysadmins. He asked for typical commitment, which is up to a few hours per week. The initial work will probably be significant, but will undoubtedly taper off over time. Go back to the original announcement: After evaluating the trackers on several points (issue creation, querying, etc.), we reached a tie between JIRA and Roundup in terms of pure tracker features. JIRA gets a leg up because of the hosting and administration also being offered. But... If enough people step forward we will notify python-dev that Roundup should be considered the recommendation of the committee and graciously turn down Atlassian's offer. That is a perfectly reasonable offer. Put up or shut up. And besides the only thing I'm really sniping the PSF against is about *ever* having thought of non-FLOSS software. This is something I *really* do not accept. ... I just disagree with their initial requirements (and I have not raised this point before because, believe me if you can, I really thought it was obvious and implicit). That just shows that you were being naïve. The initial requirements were published openly and clearly. I do respect the fact that the PSF committee did a thorough and correct evaluation: Yes, they did, and you should be thanking them instead of complaining. If you feel so strongly, please volunteer. -- David Goodger -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
[EMAIL PROTECTED] wrote: No, actually switching trackers can be one big pain in the ass. You probably aren't aware of how hard it's been for the Python development team (I think Martin v. Loewis, mostly) to get tracker data out of SF. http://effbot.org/zone/sandbox-sourceforge.htm /F -- http://mail.python.org/mailman/listinfo/python-list
