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 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. Paul [1] http://www.artima.com/forums/flat.jsp?forum=106&thread=150515 [2] http://wiki.python.org/moin/WebFrameworks -- http://mail.python.org/mailman/listinfo/python-list