Python to use a non open source bug tracker?

Ilias Lazaridis ilias at lazaridis.com
Thu Oct 5 21:06:59 CEST 2006


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)

.




More information about the Python-list mailing list