Python to use a non open source bug tracker?

[Giovanni Bajo]

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

[Robert Kern]

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?

No.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Fredrik Lundh]

Re: Python to use a non open source bug tracker?

Giovanni Bajo wrote:

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?

not necessarily (and good support for data export is high on the
requirements list), but for those of us who's been following the
committee's work, there has indeed been a disturbing amount of
"free as in - oh shiny!" from the very beginning.

however, note that the committee do realize that using a Python-
powered tool for Python is a good thing in itself; they are asking
for volunteers that can keep a roundup instance running, and fix
any issues that arises. python.org has plenty of hardware, but not
enough manpower to do everything that could be done. see brett's
post for details.

</F>

[Paul Rubin]

Re: Python to use a non open source bug tracker?

"Giovanni Bajo" <noway@sorry.co mwrites:

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?

Sounds crazy, what's wrong with bugzilla?

[Fredrik Lundh]

Re: Python to use a non open source bug tracker?

Robert Kern wrote:

>Does this smell "Bitkeeper fiasco" to anyone else than me?

>
No.

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.

if they hadn't done so, there probably wouldn't have been an evaluation
period in the first place.

</F>

[Steve Holden]

Re: Python to use a non open source bug tracker?

Paul Rubin wrote:

"Giovanni Bajo" <noway@sorry.co mwrites:
>

>>I just read this mail by Brett Cannon:
>>http://mail.python.org/pipermail/pyt...er/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?

>
>
Sounds crazy, what's wrong with bugzilla?

Much the same as is wrong with the existing SourceForge system, 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

[lbolognini@gmail.com]

Re: Python to use a non open source bug tracker?

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.

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

And BTW BitKeeper failed because Linus wanted to stop Tridge reverse
engineering BitKeeper, not because BK wasn't good.

Lorenzo

[Paul Boddie]

Re: Python to use a non open source bug tracker?

Paul Rubin wrote:

"Giovanni Bajo" <noway@sorry.co mwrites:

Does this smell "Bitkeeper fiasco" to anyone else than me?

I probably said as much before, possibly to the distaste of some
individuals. Still, the BitKeeper story should serve as a reminder
about relinquishing control of infrastructure to some seemingly
benevolent third party with their own separate interests. It should
especially be a reminder to those who deem Torvalds-style "overt
pragmatism" to be virtuous in the face of supposedly ideological
realism.

Of course, there's presumably a huge gulf between the vendor in this
case and the vendor in the BitKeeper case, especially with respect to
draconian non-compete clauses and threats to sue one's own customers.
However, it's certainly not some kind of heresy to at least question
the wisdom of moving community resources and services around in such a
way. After all, this situation has been brought about because of a
dependence on a supposedly unreliable commercial third party.

Sounds crazy, what's wrong with bugzilla?

Well, Bugzilla is a bit of a monster. ;-) Seriously, having installed
it, it seems like a relic of the early CGI period with a bunch of files
that you're supposed to throw in a CGI directory before performing
..htaccess surgery, which they admittedly do for you if you choose to
trust that particular method of deployment. Contrast that with various
other common Web applications which only put actual CGI programs within
the CGI directory, making the whole deployment much cleaner and easier
to troubleshoot/maintain, and you can see that there's a serious need
for some repackaging work.

Sure, there are scripts to help check dependencies, which meant a trip
to CPAN (not as joyous as its advocates would have you believe), and
there is a nice configuration system in Bugzilla's own Web interface
which helps you finish the job off (providing you don't forget
something in the 16 pages of settings), but there's always this nasty
suspicion that something somewhere probably isn't configured properly.
Finally, on the subject of the inner workings of Bugzilla, one is
presented with the amusement of diving into Perl to fix stuff:
something that not everyone is enthusiastic about.

As for Bugzilla's interface, it is telling that some open source
projects actually put a layer on top of Bugzilla in order to avoid the
complexity of the search interface, although it must be said that
recent versions don't seem to immediately throw up the page with 40 or
so controls on it, just to search for a bug. That said, the fact that
many open source projects continue to use Bugzilla would suggest that
they're either not interested in or aware of alternatives (quite
possible), or they're reasonably happy with it (also quite possible).

Paul

[Ben Finney]

Re: Python to use a non open source bug tracker?

Steve Holden <steve@holdenwe b.comwrites:

Paul Rubin wrote:

"Giovanni Bajo" <noway@sorry.co mwrites:

>I just read this mail by Brett Cannon:
>http://mail.python.org/pipermail/pyt...er/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?

Sounds crazy, what's wrong with bugzilla?

>
Much the same as is wrong with the existing SourceForge system, I'd say.

The existing SourceForge system runs on non-free software, which is a
significant differentiator from Bugzilla.

I would be greatly dismayed to see the PSF choosing to move critical
Python development data into a non-free system. I hope this
recommendation from the "PSF infrastructure committee" is rejected.

--
\ "There is no reason anyone would want a computer in their |
`\ home." -- Ken Olson, president, chairman and founder of |
_o__) Digital Equipment Corp., 1977 |
Ben Finney

[Oliver Andrich]

Re: Python to use a non open source bug tracker?

Hi,

On 10/3/06, Giovanni Bajo <noway@sorry.co mwrote:

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?

No, this doesn't smell like the BK fiasco, it is just the decision to
use a certain tool. But it is easy to change or influence this
recommondation. Step up as an admin for Roundup. :)

Best regards,
Oliver
--
Oliver Andrich <oliver.andrich @gmail.com--- http://roughbook.de/

[Paul Boddie]

Re: Python to use a non open source bug tracker?

lbolognini@gmai l.com 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.

Because people care about it, I guess.

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.
>
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

Perhaps, although I imagine that Trac would have a lot more uptake if
it handled more than just Subversion repositories. I don't know whether
Trac is monolithic or not, but there is a need for a wider range of
modular tools operating in the following areas:

* Web-based source code browsing and searching for many repository
types; perhaps one per type, all providing a similar interface.
Currently, there's ViewVC which does CVS and Subversion browsing
(and limited searching), LXR which does CVS, Subversion and Git
searching (with arguably more limited browsing), OpenGrok which
seems to provide CVS, Subversion, RCS and SCCS browsing and
searching. Perhaps ViewVC just needs more attention.

* Issue tracking: a huge area in which Trac, Bugzilla, Roundup and a
bunch of proprietary tools exist.

* Documentation or content management: whilst arguably non-essential
to the management of a software project, I can see the benefit of
integrating documentation with the source code browser, especially.
And it's convenient if providing a service to users as well as
developers if things like downloadable files can be managed in a
way that is compatible with the rest of the solution.

* Mailing list management/administration, feeds, summaries, reports.

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.

And BTW BitKeeper failed because Linus wanted to stop Tridge reverse
engineering BitKeeper, not because BK wasn't good.

That's a simplistic view of the situation. The BitKeeper vendor imposes
a non-compete clause on its users, which is in itself pretty
scandalous, and the various attempts to accomplish independent
interoperabilit y with the BitKeeper service led to its proprietor
packing up his toys and going home. You might believe that having some
opportunistic company narrowly define what you can and cannot do,
despite a fairly loose relationship based on you just using their stuff
in your workplace, to be acceptable as long as you get to use such nice
stuff. Others, however, consider implications wider than whether
something is technically good, including whether or not something
brings with it all sorts of unacceptable restrictions on personal
freedoms. Considered through such broader criteria, one can assert that
BitKeeper certainly wasn't good at all.

Paul

[A.M. Kuchling]

Re: Python to use a non open source bug tracker?

On Tue, 03 Oct 2006 08:19:10 GMT,
Giovanni Bajo <noway@sorry.co mwrote:

... 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/ApacheJirafor a partial list, and a
link to the Apache Software Foundation's issue trackers.

Does this smell "Bitkeeper fiasco" to anyone else than me?

The committee did expect this recommendation to be controversial. :)

--amk

[Paul Rubin]

Re: Python to use a non open source bug tracker?

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

The existing SourceForge system runs on non-free software, which is a
significant differentiator from Bugzilla.

The SourceForge software, at least in some versions, is free software.
See for example http://savannah.gnu.org for an instantiation, which
may be a fork. I never followed the saga much.

[Martin v. Löwis]

Re: Python to use a non open source bug tracker?

Giovanni Bajo schrieb:

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?

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.
2. None of these systems require a specialized client. A plain
web browser will do. IIRC, non-availibility of the Bitkeeper
client (or: re-engineering of the existing one) was what really
caused the fiasco. The same fiasco is not possible for the
bug tracker.

Regards,
Martin

[Martin v. Löwis]

Re: Python to use a non open source bug tracker?

Paul Rubin schrieb:

Sounds crazy, what's wrong with bugzilla?

Nobody offers to operate it: that's wrong. We put out a call
for trackers, and nobody (niemand, nirgendwo) was willing
to setup a bugzilla installation, work on an SF data import,
and offered to operate this installation for the period of
testing.

In addition, people expressed deep dislike of Bugzilla
in the early discussions. Some people just hate it, maybe
more so than the SF tracker.

Regards,
Martin