By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,984 Members | 2,615 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,984 IT Pros & Developers. It's quick & easy.

Python to use a non open source bug tracker?

P: n/a
Hello,

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?
--
Giovanni Bajo
Oct 3 '06 #1
Share this Question
Share on Google+
158 Replies


P: n/a
Giovanni Bajo wrote:
Hello,

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

Oct 3 '06 #2

P: n/a
Giovanni Bajo wrote:
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?
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>

Oct 3 '06 #3

P: n/a
"Giovanni Bajo" <no***@sorry.comwrites:
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?
Oct 3 '06 #4

P: n/a
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>

Oct 3 '06 #5

P: n/a
Paul Rubin wrote:
"Giovanni Bajo" <no***@sorry.comwrites:
>>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

Oct 3 '06 #6

P: n/a
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

Oct 3 '06 #7

P: n/a
Paul Rubin wrote:
"Giovanni Bajo" <no***@sorry.comwrites:

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

Oct 3 '06 #8

P: n/a
Steve Holden <st***@holdenweb.comwrites:
Paul Rubin wrote:
"Giovanni Bajo" <no***@sorry.comwrites:
>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

Oct 3 '06 #9

P: n/a
Hi,

On 10/3/06, Giovanni Bajo <no***@sorry.comwrote:
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?
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 <ol************@gmail.com--- http://roughbook.de/
Oct 3 '06 #10

P: n/a
lb********@gmail.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
interoperability 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

Oct 3 '06 #11

P: n/a
On Tue, 03 Oct 2006 08:19:10 GMT,
Giovanni Bajo <no***@sorry.comwrote:
... 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
Oct 3 '06 #12

P: n/a
Ben Finney <bi****************@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.
Oct 3 '06 #13

P: n/a
Giovanni Bajo schrieb:
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?
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
Oct 3 '06 #14

P: n/a
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
Oct 3 '06 #15

P: n/a
Ben Finney schrieb:
I would be greatly dismayed to see the PSF choosing to move critical
Python development data into a non-free system.
Then volunteer to help operating the Roundup installation. It will
become reality if there are enough volunteers to keep it running.
I hope this
recommendation from the "PSF infrastructure committee" is rejected.
That is very very unlikely. Who would reject it, and why?

Regards,
Martin
Oct 3 '06 #16

P: n/a
Ben Finney schrieb:
I would be greatly dismayed to see the PSF choosing to move critical
Python development data into a non-free system.
Then volunteer to help operating the Roundup installation. It will
become reality if there are enough volunteers to keep it running.
I hope this
recommendation from the "PSF infrastructure committee" is rejected.
That is very very unlikely. Who would reject it, and why?

Regards,
Martin
Oct 3 '06 #17

P: n/a
Fredrik Lundh wrote:
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.
Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?
There's no silly non-compete agreement. The client is a generic web browser so
everyone can play. One of the charges of the committee was to make sure that the
data could be extracted easily (something the semi-open Sourceforge didn't do so
well) such that moving would be reasonable should the JIRA folks decided to take
their ball away.

I didn't mean to trivialize concerns about about JIRA in particular or
proprietary systems in general, but using poor analogies as a rhetorical club
seems ill-advised.

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

Oct 3 '06 #18

P: n/a
Robert Kern wrote:
Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?
depends on what you consider being the cause of that fiasco. I'm not
sure it was quite as simple as people are trying to make it sound...

(and your assertion that nobody but giovanni has made that connection is
simply wrong)

</F>

Oct 3 '06 #19

P: n/a
Fredrik Lundh wrote:
Robert Kern wrote:
>Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?

depends on what you consider being the cause of that fiasco. I'm not
sure it was quite as simple as people are trying to make it sound...

(and your assertion that nobody but giovanni has made that connection is
simply wrong)
You're right. It was. I was intentionally flip; partly to goad people into
making an actual case for Giovanni's fears, partly because I was tired and
wanted to go to bed, and partly for my own entertainment.

I promise to contain my flipness if anyone will make a real case that the two
situations are comparable. Surely, "this smells like the BitKeeper fiasco," is
rather more simplistic than how others are trying to make it sound. My Googling
brings up no argument more robust than that, either for the PSF or the ASF, and
the infrastructure list's archives are closed.

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

Oct 3 '06 #20

P: n/a
Paul Rubin schrieb:
Ben Finney <bi****************@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.
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.

It would have been different if we had used the open source version
*and* hosted that ourselves. You only have a 100% guarantee that
you get the data out of the tracker if the data live on your own
disks (and you have good backup of these disks).

Regards,
Martin
Oct 3 '06 #21

P: n/a
Giovanni Bajo wrote:
Does this smell "Bitkeeper fiasco" to anyone else than me?
well, no company will spend money/effort/resources unless it benefits
them some way. Once that benefit (or the perception of it) disappears
the company will cut the lifeline. It's just common business sense.

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.

So what if in three years (again worst case scenario) they need to
change trackers? It is not such a big deal and the benefits over these
two years might have balanced out the troubles of switching.

I.

Oct 3 '06 #22

P: n/a
Fredrik Lundh <fr*****@pythonware.comwrites:
Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?

depends on what you consider being the cause of that fiasco. I'm not
sure it was quite as simple as people are trying to make it sound...
I remember there being some urgency to move away from BitKeeper
because some counter (like a 16-bit file version number that got
incremented on every check-in of the file, or something like that) was
about to overflow, and only the non-free version allocated more bits
for the counter. That was why Git had to be thrown together in just a
few weeks.
Oct 4 '06 #23

P: n/a
"Martin v. Lwis" <ma****@v.loewis.dewrites:
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?
Oct 4 '06 #24

P: n/a
"Istvan Albert" <is***********@gmail.comwrites:
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.
Well, what's so cool about it? Most large free software projects seem
to use Bugzilla. I'd never looked at the Bugzilla code but from
descriptions here it now sounds like the situation with CVS as of a
few years ago. Maybe it's time for a rewrite/replacement, a la
darcs/SVN/whatever.
Oct 4 '06 #25

P: n/a
Paul Rubin wrote:
"Istvan Albert" <is***********@gmail.comwrites:
>>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.


Well, what's so cool about it? Most large free software projects seem
to use Bugzilla. I'd never looked at the Bugzilla code but from
descriptions here it now sounds like the situation with CVS as of a
few years ago. Maybe it's time for a rewrite/replacement, a la
darcs/SVN/whatever.
Please feel free to go right ahead. Should be ready n a month or twelve ...

Like others I have my doubts about using commercial products to support
open source development but the guys who did the evaluation have chosen,
and I'm not about to second guess them.

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

Oct 4 '06 #26

P: n/a
Steve Holden <st***@holdenweb.comwrites:
Like others I have my doubts about using commercial products to
support open source development
I'm all in favour of using commercial products to support Python
development. What I'm not in favour of is using non-free products to
do so.

If we *know* that we can always get all the data out of the product,
and so long as we're constantly aware of any trend to lock in that
data by the proprietary vendor, we can avoid the trap. It's an
additional burden of ongoing diligence that is simply not required
with a free software tool, which is why I'm hoping a free tool can be
chosen instead.
the guys who did the evaluation have chosen, and I'm not about to
second guess them.
Indeed; I'm not wanting to take away the power of those who do the
work to decide how it gets done. I don't have the resources nor the
skills to manage a bug tracker for Python, so my input on this is
merely as a passionate free software user who actually values that
freedom.

--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
Ben Finney

Oct 4 '06 #27

P: n/a

"Ben Finney" <bi****************@benfinney.id.auwrote in message
news:87************@benfinney.id.au...
If we *know* that we can always get all the data out of the product,
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.

tjr

Oct 4 '06 #28

P: n/a
Paul Rubin schrieb:
"Martin v. Lwis" <ma****@v.loewis.dewrites:
>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
Oct 4 '06 #29

P: n/a
Martin v. Lwis 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
Oct 4 '06 #30

P: n/a
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
Oct 4 '06 #31

P: n/a
lb********@gmail.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.

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
Oct 4 '06 #32

P: n/a
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/ApacheJirafor 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
Oct 4 '06 #33

P: n/a
Martin v. Lwis 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
Oct 4 '06 #34

P: n/a
lb********@gmail.com <lb********@gmail.comwrote:
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 <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Oct 4 '06 #35

P: n/a
Nick Craig-Wood wrote:
lb********@gmail.com <lb********@gmail.comwrote:
> 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

Oct 4 '06 #36

P: n/a
On 10/4/06, Richard Jones <ri**********@optushome.com.auwrote:
Nick Craig-Wood wrote:
lb********@gmail.com <lb********@gmail.comwrote:
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
Oct 4 '06 #37

P: n/a
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/ApacheJirafor 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

Oct 4 '06 #38

P: n/a
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

Oct 4 '06 #39

P: n/a
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>

Oct 4 '06 #40

P: n/a
On Wed, 04 Oct 2006 07:37:47 GMT,
Giovanni Bajo <no***@sorry.comwrote:
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
Oct 4 '06 #41

P: n/a
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
Oct 4 '06 #42

P: n/a
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

Oct 4 '06 #43

P: n/a
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

Oct 4 '06 #44

P: n/a
Terry Reedy <tj*****@udel.eduwrote:
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
Oct 4 '06 #45

P: n/a
Steve Holden <st***@holdenweb.comwrites:
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.
Oct 4 '06 #46

P: n/a
"Fredrik Lundh" <fr*****@pythonware.comwrites:
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
Oct 4 '06 #47

P: n/a
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

Oct 4 '06 #48

P: n/a
Valentino Volonghi aka Dialtone wrote:
Terry Reedy <tj*****@udel.eduwrote:

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

Oct 4 '06 #49

P: n/a
Steve Holden <st***@holdenweb.comwrote:
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
Oct 4 '06 #50

158 Replies

This discussion thread is closed

Replies have been disabled for this discussion.