Python to use a non open source bug tracker?

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

 

[Istvan Albert]

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.

 

[Paul Rubin]

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.

 

[Paul Rubin]

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?

 

[Paul Rubin]

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.

 

[Steve Holden]

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

 

[Ben Finney]

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.

 

[Terry Reedy]

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

 

[Harry George]

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.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

 

[Giovanni Bajo]

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]

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]

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]

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.

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]

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.

 

[Nick Craig-Wood]

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.

 

[Richard Jones]

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

 

[Ramon Diaz-Uriarte]

Trac was considered.



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.

 

[Steve Holden]

A.M. Kuchling wrote:




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.




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

 

[Paul Boddie]

Trac was considered.


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