Python to use a non open source bug tracker?
Giovanni Bajo
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
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
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
Sounds crazy, what's wrong with bugzilla?
Fredrik Lundh
>> 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
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
lbolo...@gmail.com
> 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
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
> 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
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....@gmail.com> --- http://roughbook.de/
Paul Boddie
> 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
A.M. Kuchling
Giovanni Bajo <no...@sorry.com> 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/ApacheJira> for 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
> 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"
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"
> 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
"Martin v. Löwis"
> 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
"Martin v. Löwis"
> 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
Robert Kern
> Robert Kern wrote:
>
>>> Does this smell "Bitkeeper fiasco" to anyone else than me?
>
> 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.
Fredrik Lundh
> 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>
Robert Kern
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.
"Martin v. Löwis"
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
> > 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.
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
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.
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.
--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
Ben Finney
Terry Reedy
"Ben Finney" <bignose+h...@benfinney.id.au> wrote in message
news:87ac4ci...@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
"Martin v. Löwis"
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
>> 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
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
Giovanni Bajo
> 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
Giovanni Bajo
>> ... 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/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.
>> 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
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.
--
Giovanni Bajo
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.
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.
A nice extra is that it is written in python.
--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick
Richard Jones
> lbolo...@gmail.com <lbolo...@gmail.com> wrote:
>> 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
Ramon Diaz-Uriarte
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
Steve Holden
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 ....
Paul Boddie
> 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
Fredrik Lundh
> 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>
A.M. Kuchling
Giovanni Bajo <no...@sorry.com> 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; minimal requirements were
specified in the initial message requesting trackers
(http://wiki.python.org/moin/OriginalCallForTrackers).
--amk
Giovanni Bajo
>> 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
Paul Boddie
>
> 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
Steve Holden
*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.
Valentino Volonghi aka Dialtone
> 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
Paul Rubin
> 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.
Harry George
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)
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
Steve Holden
Steve Holden
> Terry Reedy <tjr...@udel.edu> wrote:
>
>
>>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.
>
you really think SQLite would be a suitable platform for it?
Valentino Volonghi aka Dialtone
> > 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.
Fredrik Lundh
> 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.
10k entries shouldn't be much of an issue for sqlite3 either.
(I don't think any of the proposed solutions would have a *capacity* problem.
afaict, the main argument was that trac and launchpad simply isn't quite as con-
figurable as the others. which doesn't have to be a bad thing, really -- effient
bug handling is more about process than technology. the best issue tracking
system I've ever used wasn't even designed for issue tracking...)
</F>
Paul Boddie
> Valentino Volonghi wrote:
>
> > 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.
>
> 10k entries shouldn't be much of an issue for sqlite3 either.
Out of interest, here are some figures:
KDE: 12983 bugs and 11656 wishes
GNOME: 23624 reports
Python: 7159 bugs, 3843 patches, 477 feature requests
The Python figures are totals, whereas I can't be sure whether the KDE
and GNOME figures merely refer to the open issues. Nevertheless, Python
isn't going to be pushing the envelope.
Paul
Istvan Albert
> 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
I think you are missing the point. Switching to a different tracker is
not such a big deal. Having a really good tracker is a big deal.
Trackers are all about usability.
Alas most open source projects suck at that while excel in
implementation and performance.
FWIW I'd rather have the PSF even pay for good quality tracker since
that benefits everyone rather than funding some obscure project that
only 1% of the programmers will use/heard of.
Istvan
sk...@pobox.com
Giovanni> In fact, are you absolutely positive that you need so much
Giovanni> effort to maintain an existing bugtracker installation?
The development group's experience with SF and I think to a lesser extent,
Roundup in its early days, and more generally with other components of the
development toolchain (source code control) and python.org website
maintenance suggests that some human needs to be responsible for each key
piece of technology. Maybe when it's mature it needs very little manpower
to maintain, but a substantial investment is required when the technology is
first installed.
Skip
sk...@pobox.com
Istvan> I think you are missing the point. Switching to a different
Istvan> tracker is not such a big deal. Having a really good tracker is
Istvan> a big deal.
No, actually switching trackers can be one big pain in the ass. You
probably aren't aware of how hard it's been for the Python development team
(I think Martin v. Loewis, mostly) to get tracker data out of SF. An
explicit requirement was that any tool chosen as a SF replacement be able to
easily export its database to avoid this sort of "lock-in" in the future.
Skip
Giovanni Bajo
One thing is asking for a special help during the transition phase and the
"landing" phase (the first few months). Another thing is asking for "roughly
6-10 people" to install and maintain a Roundup installation. This is simply
not going to realistically happen, and I find it incredible for the PSF
committee to ask for such a high request. Damn, we don't have "roughly 6-10
people" in charge of reviewing patches or fixing bugs.
I followed the GNATS -> Bugzilla transition myself closely, and a single
person (Daniel Berlin) was able to setup the Bugzilla server on the
gcc.gnu.org computer, convince everybody that a transition was needed (and
believe me, this was a hard work), patch it as much as needed to face the
needs of the incredibly picky GCC developers (asking for every little
almost-unused-and-obsoleted feature in GNATS to be replicated in Bugzilla),
and later maintain the installation. It took him approximately one year to
do this, and surely it wasn't full time. After that, he maintains and
administer the Bugzilla installation on his own, by providing upgrades when
needed and a few modifications.
I wonder why the PSF infrastructure committee believes that a group of 6-10
people is needed to "install and maintain" Roundup. Let us also consider
that Roundup's lead developer *was* part of the PSF infrastrucutre
committee, and he might be willing to help in the transition (just my very
wild guess), and he obviously knows his stuff. Also, given the requirement
for the selection, there is already a running roundup installation somewhere
(so the whole pipeline export -> import has already been estabilished and
confirmed to work).
My own opinion is that a couple of person can manage the
transition/migration phase to *any* other bug tracking system, and provide
support in the python-dev mailing list. After the whole thing has fully
landed, I'd be really surprised if a single appointed maintainer would not
be enough.
If the PSF committee lowers its requests to a more realistical amount of
effort, I'm sure we will see many more people willing to help. I think many
people (including myself) would be willing to half-half-help with loose
ends, but when faced with an abnormous "6-10 people" request they just shut
up and sit in a corner.
--
Giovanni Bajo
Giovanni Bajo
> 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.
The current request is: "please, readers of python-dev, setup a team of 6-10
people to handle roundup or we'll go to a non-free software for bug
tracking". This is something which I cannot cope with, and I'm *speaking*
up against. Were the request lowered to something more reasonable, I'd be
willing to *act*. I have to speak before acting, so that my acting can
produce a result.
And besides the only thing I'm really sniping the PSF against is about
*ever* having thought of non-FLOSS software. This is something I *really* do
not accept. You have not seen a mail from me with random moaning as "Trac is
better", "Bugzilla is better", "why this was chosen". I do respect the fact
that the PSF committee did a thorough and correct evaluation: I just
disagree with their initial requirements (and I have not raised this point
before because, believe me if you can, I really thought it was obvious and
implicit).
So, if your remarks apply to me, I think you are misrepresenting my mails
and my goals.
--
Giovanni Bajo
fuzzylollipop
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.
>
> Giovanni Bajo
No just ignorance you your part!
Jira is given away for free to open source projects that want to use
it. And it just happens to be one of the best issue trackers on the
market, free or paid or opens source or not.
A.M. Kuchling
> Right now there is not even agreement on what the goal is.
The goal is a new tracker for python.org that the developers like
better; the original call lists 3 reasons (bad interface; lack of
reliability; lack of workflow controls).
> 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.
I don't think Python has ever had this as a goal. Python's license
lets it be embedded in closed-source products; Windows binaries are
built using closed-source tools (MS Visual C), and on some platforms
we use a closed-source system compiler; python.org used to be a
Solaris box, and now uses SourceForge which runs on top of DB/2...
IMHO, using Jira presents risks that are manageable:
* A data export is available if we decide to switch. Writing a script to
take this export and convert to a new tracker is non-trivial, but the
same is true of any other tracker we might choose; switching from
Roundup to Trac or Trac to Launchpad is also going to require some
effort. Therefore, I don't think our data is locked-in any more
than any other tracker.
* The offer of hosting means this won't consume very much
administrative time. Perhaps the hosting offered will be found to be
unreliable. If that's the case, we can reconsider the choice of
tracker, or (less likely) host Jira ourselves.
* There are no Bitkeeper-like licensing issues like the non-compete
clause, so that isn't a factor; Roundup and Trac developers can file
bugs and use the tracker just like anyone else.
* The interface is very flexible and lots of customization can be done
through the web. This means we don't have to hack the code at all,
and upgrades should theoretically go smoothly.
It would be nice to have the additional tick-box feature 'is open
source', but the upsides are large enough that I can let go of
that issue with only slight regret.
--amk
Paul Boddie
>
> The current request is: "please, readers of python-dev, setup a team of 6-10
> people to handle roundup or we'll go to a non-free software for bug
> tracking".
Actually, it would appear that the request goes out to
comp.lang.python/python-list as well (ie. the ungrateful plebs like
myself who supposedly have nothing to contribute to the direction of
the Python project).
[...]
> And besides the only thing I'm really sniping the PSF against is about
> *ever* having thought of non-FLOSS software.
It has already been brought up that Python plays well with everyone and
everything, and thus a closed source tool projects the attitudes of the
core developers. However, in contrast to the use of tools such as
Roundup which have some advocacy value, the adoption of commercial
products often works largely in favour of the vendor: they're seen to
be helpful and charitable (which they may well be), and there's a
certain level of publicity value generated from the transaction (albeit
not as much as if the Bugzilla project switched over to a closed source
issue tracker).
Of course, this message so far probably passes for "being political" in
the eyes of certain people, but I think it's interesting to put such
decisions in the context of the calls to advocacy that people come out
with every now and again. Indeed, I believe that the PSF now have an
advocacy coordinator to lead the onslaught selling Python into
"business" or whatever people regard Python advocacy to be these days.
However, as an open source project it doesn't necessarily send a good
message to "business" that the amazing processes that drive Python
development are powered by closed source software (although they also
have been through the use of SourceForge) and that the developers
passed over a project that they were quite happy to use promotionally
once upon a time.
Indeed, while it was still running, the Software Carpentry competition
(the initiative which led to the development of Roundup) was potent
publicity material showing that Python and open source development
produce great software. The risk is that "business" looks at the level
of self-belief ("don't mention the competition by name" [1], but where
the competition isn't just other languages: it's also other development
methodologies) and wonders whether they wouldn't be better off with
some closed source development environment for their closed source
commercial product instead.
I guess what plebs like myself are supposed to take away from this is
the following: if the core developers are subsequently much more
productive developing the language (which is not exactly the thing
which requires most attention in the Python distribution these days, in
my opinion), then who are we to complain as long as we can still stuff
our bugs into some Web-based interface or other?
Paul
[1]
http://holdenweb.blogspot.com/2006/03/marketing-why-do-you-use-python.html
David Goodger
> The current request is: "please, readers of python-dev, setup a team of 6-10
> people to handle roundup or we'll go to a non-free software for bug
> tracking". This is something which I cannot cope with, and I'm *speaking*
> up against. Were the request lowered to something more reasonable, I'd be
> willing to *act*.
No, the announcement stated the situation in a very different way.
Asking for a group of maintainers to commit to an essential piece of
infrastructure is perfectly reasonable. Brett didn't ask for 6-10 full
time developer/sysadmins. He asked for typical commitment, which is up
to a few hours per week. The initial work will probably be significant,
but will undoubtedly taper off over time.
Go back to the original announcement:
"""
After evaluating the trackers on several points (issue creation,
querying, etc.), we reached a tie between JIRA and Roundup in terms of
pure tracker features.
"""
JIRA gets a leg up because of the hosting and administration also being
offered. But...
"""
If enough people step forward we will notify python-dev that Roundup
should be considered the recommendation of the committee and graciously
turn down Atlassian's offer.
"""
That is a perfectly reasonable offer. Put up or shut up.
> And besides the only thing I'm really sniping the PSF against is about
> *ever* having thought of non-FLOSS software. This is something I *really* do
> not accept. ... I just
> disagree with their initial requirements (and I have not raised this point
> before because, believe me if you can, I really thought it was obvious and
> implicit).
That just shows that you were being naïve. The initial requirements
were published openly and clearly.
> I do respect the fact
> that the PSF committee did a thorough and correct evaluation:
Yes, they did, and you should be thanking them instead of complaining.
If you feel so strongly, please volunteer.
-- David Goodger
Fredrik Lundh
> No, actually switching trackers can be one big pain in the ass. You
> probably aren't aware of how hard it's been for the Python development team
> (I think Martin v. Loewis, mostly) to get tracker data out of SF.
http://effbot.org/zone/sandbox-sourceforge.htm
</F>
"Martin v. Löwis"
>>> 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".
How would "the community" actually reject it? By not using it? Well,
that won't happen: They use the current SF tracker, despite it being
non-free software.
> 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.
You fail to recognize that Python is *already* using a non-free software
for bug tracking, as do thousands of other projects. So from that point
of view, the status wouldn't change.
Regards,
Martin
sk...@pobox.com
>> No, actually switching trackers can be one big pain in the ass. You
>> probably aren't aware of how hard it's been for the Python
>> development team (I think Martin v. Loewis, mostly) to get tracker
>> data out of SF.
Fredrik> http://effbot.org/zone/sandbox-sourceforge.htm
Thanks for the memory jog. Before you wrote your scraper/downloader I seem
to recall there were several only-semi-successful attempts to get SF to
themselves dump the tracker data for us. That was what I was referring to.
Skip
"Martin v. Löwis"
> 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.
Daniel Berlin has put a tremendous amount of work into it. I know,
because I set up the first bug tracker for gcc (using GNATS), and
have been followed the several years of pondering fairly closely.
It was quite some work to set up GNATS, and it was even more work
to setup bugzilla.
For Python, we don't have any person similar to Daniel Berlin
(actually, we have several who *could* have done similar work,
but none that ever volunteered to do it). Don't underestimate
the work of somebody else.
I know that I'm currently putting more time into maintaining the
Subversion installation than I'd like to, despite this being a really
small amount of work per month, and despite others also having been
introduced to the infrastructure necessary for administration.
When I go on vacation, people effectively have to wait until
I return before they can get their write access enabled. I
sometimes defer dealing with admin requests for a few days, and
people start complaining.
Regards,
Martin
"Martin v. Löwis"
> Frankly, I don't give a damn about the language the application is coded in
That's probably one of the reasons why you aren't a member of the Python
Software Foundation. Its mission includes to publicize, promote the
adoption of, and facilitate the ongoing development of Python-related
technology and educational resources. So the tracker being written in
Python is quite of importance.
Regards,
Martin
"Martin v. Löwis"
> 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.
IMO, the biggest concern was that it didn't really "scale". I.e. if you
have a thousand open and several thousand closed reports in the
database, you need excellent support for queries, sorting, and alike.
Trac doesn't quite have the same power that the other tools do.
For example, to save a query/report, you actually have to write it in
SQL. For a complex report (with multiple groups), you cannot change
the order of items returned on the page (for a simple search, clicking
on the headings changes the order).
To see what I mean, please try to find out how many open reports
for the module "report system" are currently entered in the tracker
at
http://trac.edgewall.org/report
How many of these are for 0.9.x?
There is also searching, which doesn't give a tabular view of all
tickets, but instead gives a Web search result page (similar
to what a search engine produces). This makes it difficult to scan
systematically for, say, all titles.
Regards,
Martin
Paul Rubin
> You fail to recognize that Python is *already* using a non-free software
> for bug tracking, as do thousands of other projects.
I don't think that reflects an explicit decision. SF started out as
free software and the software became nonfree after people were
already using it.
"Martin v. Löwis"
> No, actually switching trackers can be one big pain in the ass. You
> probably aren't aware of how hard it's been for the Python development team
> (I think Martin v. Loewis, mostly) to get tracker data out of SF. An
> explicit requirement was that any tool chosen as a SF replacement be able to
> easily export its database to avoid this sort of "lock-in" in the future.
While I put quite some effort into getting data out of SF, it was
Fredrik Lundh who eventually implemented the solution that we'll use:
screen scraping. My efforts to get data out of SF "officially"
were futile.
Regards,
Martin
"Martin v. Löwis"
> Out of interest, here are some figures:
>
> KDE: 12983 bugs and 11656 wishes
> GNOME: 23624 reports
> Python: 7159 bugs, 3843 patches, 477 feature requests
>
> The Python figures are totals, whereas I can't be sure whether the KDE
> and GNOME figures merely refer to the open issues. Nevertheless, Python
> isn't going to be pushing the envelope.
Right: machine power isn't really an issue (although the snappiness
of response does contribute to usability: the various installations
showed noticable differences in response time).
The issue of scalability is really how a large number of reports
can be managed. How can a submitter easily find out whether a report
for some issue already exists, and how can a maintainer easily find
out what needs most attention (where each developer might apply
her own priority system)? For a small number of issues, you can
scan through a list. If the list contains more than 20 entries,
scanning through it becomes tedious.
Regards,
Martin
Giovanni Bajo
So we have a problem between the PSF and the "PSF infrastructure committee",
since the latter did not put "being written in Python" has a requirement for
the tracker.
--
Giovanni Bajo
Giovanni Bajo
>> You fail to recognize that Python is *already* using a non-free
>> software for bug tracking, as do thousands of other projects.
>
> I don't think that reflects an explicit decision. SF started out as
> free software and the software became nonfree after people were
> already using it.
Moreover, this looked like a very good chance to have this nuisance sorted out.
Too bad some people don't value free software enough.
--
Giovanni Bajo
"Martin v. Löwis"
That, in principle, could happen to any other free software as well.
What is critical here is that SF *hosted* the installation. If we would
use a tracker that is free software, yet hosted it elsewhere, the same
thing could happen: the hoster could make modifications to it which
are non-free. Not even the GPL could protect from this case: the
hoster would be required to publish source only if he publishes
binaries, but he wouldn't publish any binaries, so he wouldn't need
to release the source changes, either.
Also, even if it the software is open source and unmodified, there
still wouldn't be a guarantee that you can get the data out of it
if you want to. You *only* get the advantages of free software if
you also run it yourself. Unfortunately, there is a significant
cost associated with running the software yourself.
Despite what other people say, this *is* an issue. On python.org,
things that should get done don't, just because there is no
volunteer doing them. Hosting such a service elsewhere has the
clear advantage that you don't have to worry about most routine
maintenance jobs.
Regards,
Martin
Giovanni Bajo
>> 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.
>
> I don't think Python has ever had this as a goal. Python's license
> lets it be embedded in closed-source products; Windows binaries are
> built using closed-source tools (MS Visual C), and on some platforms
> we use a closed-source system compiler; python.org used to be a
> Solaris box, and now uses SourceForge which runs on top of DB/2...
Notice that there is a different between "allowing/helping/supporting non-free
software" and "avoid reliance on non-free software". The fact that Python
license allows it to be used in non-free products falls in the former, while
the usage of Jira is part of the latter. Distributing binaries compiled with
closed-source tools is not a problem since people can still compile it with
different free compilers.
> IMHO, using Jira presents risks that are manageable:
> [...]
>
> * A data export is available if we decide to switch. [...]
Out of curiosity, how is this obtained? Is this any plan to take a daily export
or so?
--
Giovanni Bajo
Giovanni Bajo
> Go back to the original announcement:
>
> """
> After evaluating the trackers on several points (issue creation,
> querying, etc.), we reached a tie between JIRA and Roundup in terms of
> pure tracker features.
> """
>
> JIRA gets a leg up because of the hosting and administration also
> being offered. But...
>
> """
> If enough people step forward we will notify python-dev that Roundup
> should be considered the recommendation of the committee and
> graciously
> turn down Atlassian's offer.
> """
>
> That is a perfectly reasonable offer. Put up or shut up.
You're cherry picking your quotes:
"""
In order for Roundup to be considered equivalent in terms of an overall
tracker package there needs to be a sufficient number of volunteer admins
(roughly 6 - 10 people) who can help set up and maintain the Roundup
installation.
"""
This is *NOT* a perfectly reasonable offer, because you do not see 6-10 people
stepping up at the same time for almost *anything* in the open source world.
--
Giovanni Bajo
Fredrik Lundh
>> 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).
what I was trying to say (between the lines) was that not only have
the people on that list worked hard to do the evaluation (not to mention
all the developers around the world that has worked even harder to set
up test trackers), there's also been a good community response to the
committee's call for "6-10 volunteers".
</F>
Paul Rubin
> That, in principle, could happen to any other free software as well.
> What is critical here is that SF *hosted* the installation. If we would
> use a tracker that is free software, yet hosted it elsewhere, the same
> thing could happen: the hoster could make modifications to it which
> are non-free. Not even the GPL could protect from this case: the
> hoster would be required to publish source only if he publishes
> binaries, but he wouldn't publish any binaries, so he wouldn't need
> to release the source changes, either.
True, though GPL 3 tries to address that. Most important is to figure
out the underlying attitude of the host. I realize it's the same
crufty software (or worse) as SF and therefore maybe not so attractive
on those grounds already, but did you think about migrating to
Savannah?
> Also, even if it the software is open source and unmodified, there
> still wouldn't be a guarantee that you can get the data out of it
> if you want to. You *only* get the advantages of free software if
> you also run it yourself. Unfortunately, there is a significant
> cost associated with running the software yourself.
Well, if the cash is available, there's always the possibility of
using free software and paying someone to host it. Anyway, I wouldn't
have expected running a tracker to be that significant a task compared
with the rest of the web site, the mailing lists, the Subversion
server, the codebase itself, etc. etc. But Paul Boddie explained some
of the issues pretty well.
> Despite what other people say, this *is* an issue. On python.org,
> things that should get done don't, just because there is no
> volunteer doing them. Hosting such a service elsewhere has the
> clear advantage that you don't have to worry about most routine
> maintenance jobs.
I have to wonder too why Jira is so sure to be more reliable than SF.
David Goodger
> So we have a problem between the PSF and the "PSF infrastructure committee",
> since the latter did not put "being written in Python" has a requirement for
> the tracker.
There was no problem. The committee had their mandate, to find the best
candidate for a tracker for Python. The quality of the tracker was felt
to be more important than the language it was written in or the license
it uses. The committee members worked hard to fulfill their mandate,
and they deserve the gratitude and appreciation of all of us.
I know for a fact (having raised this very issue with the committee
myself) that they took "written in Python" into consideration. Not as a
requirement though -- the requirement was simply to decide on the best
tracker, regardless of language or license.
Look at the results again. Jira and RoundUp tied for functionality, but
Jira has a hosting/admin offer behind it. That's huge. But rather than
declaring Jira the outright winner, which they could have done, the
committee has allowed the community to decide the matter. If enough
admins come forward, RoundUp will win.
I read that as a big push for "written in Python".
David Goodger
David Goodger
> You're cherry picking your quotes:
>
> """
> In order for Roundup to be considered equivalent in terms of an overall
> tracker package there needs to be a sufficient number of volunteer admins
> (roughly 6 - 10 people) who can help set up and maintain the Roundup
> installation.
> """
>
> This is *NOT* a perfectly reasonable offer,
Yes it is:
Jira = 1st place functionality + hosting/admin provided
RoundUp = 1st place functionality
Jira wins. But the offer is to allow the community to make up the
difference. If anything, that's unfair to Jira. So why are you
complaining?
> because you do not see 6-10 people
> stepping up at the same time for almost *anything* in the open source world.
Then that's a failure of the open source world.
But I *do* see it happening right now. People *are* stepping up.
David Goodger
"Martin v. Löwis"
> True, though GPL 3 tries to address that. Most important is to figure
> out the underlying attitude of the host. I realize it's the same
> crufty software (or worse) as SF and therefore maybe not so attractive
> on those grounds already, but did you think about migrating to
> Savannah?
We had a very clear procedure. We (the committee) didn't want to
manage the installation ourselves, or figure out how to set up
the software, or get the data into it. Instead, we sent out a call
to the community to come up with a demo installation for evaluation
purposes. Nobody offered to migrate the data into Savannah, so
we didn't consider it (nobody actually offered to show-case
Savannah for us, period).
There were several reasons to get off SF; it not being open
source was never a reason. Instead, ongoing complaints about
service level, and the UI were the main complaints. Savannah
is IMO worse than SF wrt. user interface, so it would have
lost in the evaluation even if a demo installation was provided.
We want to improve with that switch, not decrease usability.
>> Despite what other people say, this *is* an issue. On python.org,
>> things that should get done don't, just because there is no
>> volunteer doing them. Hosting such a service elsewhere has the
>> clear advantage that you don't have to worry about most routine
>> maintenance jobs.
>
> I have to wonder too why Jira is so sure to be more reliable than SF.
It may change as time evolves, but at the moment, they are *pretty*
responsive to our inquiries. Atlassian (the company behind it) uses
the same infrastructure for their commercial offerings, as well;
this might mean that we get the same availability (it might also
mean that paying customers get more attention than non-paying ones
in the long term).
With any kind of partner, there is always the risk that they don't
deliver, and you always have to invest some trust in the beginning.
It was this way when Guido moved Python to SF, and indeed, SF did
a very good job for several years (IMO). They only went unreliable
when they grow beyond expectations. The same could happen to
Atlassian, of course, in which case we would have to move again.
OTOH, the same could also happen with a group of volunteers.
It's always possible that they all run away (like that distutils
is unmaintained, and PyXML is unmaintained). Volunteers are actually
unlikely to persist in their efforts over a period of 10 years,
as their lifes and priorities change over time. If you trust
such a service to a single volunteer, you might find that the
service can become very unusable very quickly. For example, the
Python Job Board was in a very bad shape for several months,
until we managed to find Peter Kropf to take it over (who
does a very good job ever since he started).
Regards,
Martin
"Martin v. Löwis"
>> * A data export is available if we decide to switch. [...]
>
> Out of curiosity, how is this obtained? Is this any plan to take a daily export
> or so?
Exactly so. Atlassian would generate a daily dump, and we would copy it
to a machine on python.org with a cron job.
Regards,
Martin
"Martin v. Löwis"
> what I was trying to say (between the lines) was that not only have
> the people on that list worked hard to do the evaluation (not to mention
> all the developers around the world that has worked even harder to set
> up test trackers)
That cannot be praised enough. Special thanks to Jonathan Nolen from
Atlassian to set up the Jira installation, Stefan Seefeld to set up
the Roundup installation, Alec Thomas for the Trac installation,
and James Henstridge for adding Python to the Launchpad.
To all those who complain that their favorite software XYZ wasn't
considered: apparently, nobody in the community bothered enough to
respond to the call for trackers. If nobody experienced with the
software thinks it is worthwhile to set up a demo it,
why should we review it?
Regards,
Martin
Ben Finney
> Giovanni Bajo wrote:
> > 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?
>
> Jira is given away for free to open source projects that want to use
> it.
Just as Bitkeeper was.
"Given away for free" has nothing to do with the criteria being
discussed here.
--
\ "My, your, his, hers, ours, theirs, its. I'm, you're, he's, |
`\ she's, we're, they're, it's." -- Anonymous, |
_o__) alt.sysadmin.recovery |
Ben Finney
Ben Finney
> Giovanni Bajo schrieb:
> > 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.
>
> You fail to recognize that Python is *already* using a non-free software
> for bug tracking, as do thousands of other projects. So from that point
> of view, the status wouldn't change.
The whole point of moving *from* SF *to* another bug tracker is to
improve the situation, surely.
You already seem to acknowledge that using free-software tools to
develop Python is desirable. I don't see why you're being so obtuse in
this sub-thread on *why* it's desirable.
--
\ "The Stones, I love the Stones; I can't believe they're still |
`\ doing it after all these years. I watch them whenever I can: |
_o__) Fred, Barney, ..." -- Steven Wright |
Ben Finney
Ben Finney
> Look at the results again. Jira and RoundUp tied for functionality,
> but Jira has a hosting/admin offer behind it. That's huge. But
> rather than declaring Jira the outright winner, which they could
> have done, the committee has allowed the community to decide the
> matter. If enough admins come forward, RoundUp will win.
>
> I read that as a big push for "written in Python".
I prefer to read it as a big push for "not dependent on non-free
tools".
--
\ "To me, boxing is like a ballet, except there's no music, no |
`\ choreography, and the dancers hit each other." -- Jack Handey |
_o__) |
Ben Finney
Ilias Lazaridis
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.
-
http://case.lazaridis.com/wiki/Tracking
.
Terry Reedy
"Ben Finney" <bignose+h...@benfinney.id.au> wrote in message
news:87lknve...@benfinney.id.au...
> The whole point of moving *from* SF *to* another bug tracker is to
> improve the situation, surely.
The current situation is that the limitations and intermittant failures of
the SF tracker sufficiently impede the Python development process that some
people were motivated to do the work to find a better alternative.
> You already seem to acknowledge that using free-software tools to
> develop Python is desirable.
The committee already said so by saying that with other things equal, it
would choose Roundup.
> I don't see why you're being so obtuse
I think name calling is out of line here.
Terry Jan Reedy
Robert Hicks
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
No.
Robert
Ben Finney
> "Ben Finney" <bignose+h...@benfinney.id.au> wrote:
> > I don't see why you're being so obtuse
> I think name calling is out of line here.
So do I, which is why I addressed observed actions instead.
--
\ "I got a postcard from my best friend, it was a satellite |
`\ picture of the entire Earth. On the back he wrote, 'Wish you |
_o__) were here'." -- Steven Wright |
Ben Finney
Aahz
Giovanni Bajo <raN...@deveSPAMler.com> wrote:
>
>I wonder why the PSF infrastructure committee believes that a group of 6-10
>people is needed to "install and maintain" Roundup.
Because Roundup has been "the answer" for at least two or three years,
but somehow it never has gotten enough concerted attention to make it
happen. I'm sure that experience informed much of the Infrastructure
Committee's work.
I suspect in the end that if four or five people who are known to follow
through on their commitments volunteered that probably would be enough.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"LL YR VWL R BLNG T S" -- www.nancybuttons.com
Ilias Lazaridis
?? how do you know the answer??
anyway.
-
I don't think that a non-open-source system will be selected by the
responsible people.
Most possibly, they are aware about the basic requirements of an
infrastructure - which is control:
http://case.lazaridis.com/wiki/Host
.
"Martin v. Löwis"
>> Giovanni Bajo schrieb:
>>> 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.
>> You fail to recognize that Python is *already* using a non-free software
>> for bug tracking, as do thousands of other projects. So from that point
>> of view, the status wouldn't change.
>
> The whole point of moving *from* SF *to* another bug tracker is to
> improve the situation, surely.
>
> You already seem to acknowledge that using free-software tools to
> develop Python is desirable. I don't see why you're being so obtuse in
> this sub-thread on *why* it's desirable.
I don't deny it's desirable; I deny it's a indispensable requirement.
I truly believe that Jira would be a useful bug tracker and improve
the situation, despite it being non-free software. This really is no
source of worry for me. I'm feeling more uneasy about the fact that
it is written in Java (but still, this wouldn't stop me from
recommending it as it is a useful and well-engineered piece of
software).
In this sub-thread, I complain about this FUD "Python is moving
to a non-free bug tracker" (suggesting that it is moving away
from a free bug tracker).
Regards,
Martin
Steve Holden
> "David Goodger" <dgoo...@gmail.com> writes:
>
>
>>Look at the results again. Jira and RoundUp tied for functionality,
>>but Jira has a hosting/admin offer behind it. That's huge. But
>>rather than declaring Jira the outright winner, which they could
>>have done, the committee has allowed the community to decide the
>>matter. If enough admins come forward, RoundUp will win.
>>
>>I read that as a big push for "written in Python".
>
>
> tools".
>
new to say, kindly leave it. You have made your opinion known, as you
are fully entitled to do. Frankly I am getting less interested in your
opinion with each new post.
You appear to be prepared to go to any length short of providing effort
to support the open source tracker.
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
Fredrik Lundh
> You appear to be prepared to go to any length short of providing effort
> to support the open source tracker.
http://www.userland.com/whatIsStopEnergy
</F>
Steve Holden
> "Ben Finney" <bignose+h...@benfinney.id.au> wrote in message
> news:87lknve...@benfinney.id.au...
>
>>improve the situation, surely.
>
>
> the SF tracker sufficiently impede the Python development process that some
> people were motivated to do the work to find a better alternative.
>
>
>>develop Python is desirable.
>
>
> would choose Roundup.
>
>
>
>
>
desirability of using open source software when in fact they are mostly
disagreeing about the *practicality* in this particular instance.
Compellingly absent from most critics' output is a statement to the
effect that they will volunteer their time to encourage the adoption of
Roundup, which is excluded only by the absence of a support infrastructure.
Time to shit or get off the pot, I'd say.
Steve Holden
> Steve Holden wrote:
>
>
>>>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).
>
>
> the people on that list worked hard to do the evaluation (not to mention
> all the developers around the world that has worked even harder to set
> committee's call for "6-10 volunteers".
>
dissenting didn't appear to want to rectify the situation by offering
their time. It would be nice to be wrong about that.
Steve Holden
end of?
http://wiki.python.org/moin/OriginalCallForTrackers
Fredrik Lundh
> Excellent. I've just complained elsewhere in this thread that those
> dissenting didn't appear to want to rectify the situation by offering
> their time. It would be nice to be wrong about that.
the dissenting won't contribute a thing, of course. they never ever do.
but not everyone is wired that way.
</F>
Ben Finney
> And I'd prefer it if you'd drop this subject. So, if you have
> nothing new to say, kindly leave it.
I'm happy to, but:
> You appear to be prepared to go to any length short of providing
> effort to support the open source tracker.
This was addressed in a previous post. I don't have the skills nor the
resources to do this. Yes, as has been pointed out, it actually *is*
far less effort to point out problems, than to solve them. That
doesn't detract from the value of pointing out problems.
This thread was started on the shock of realising that a non-free tool
was even being *considered* for the new Python bug tracker. Those are
the terms on which I've been arguing.
Apparently there are some people who *have* put themselves forward to
support a free-software tool. Great! My point all along has been that
Python's developers are well advised to consider *only* free-software
tools for supporting development of Python, and that from among those
the best tool for the job should be chosen.
As you say, nothing new has been said now for a while, so in the
absence of that I'm happy to leave it here.
--
\ "Why, I'd horse-whip you if I had a horse." -- Groucho Marx |
`\ |
_o__) |
Ben Finney
Tim Peters
>> I don't see why you're being so obtuse
[Terry Reedy]
> I think name calling is out of line here.
Name calling is always out of line on comp.lang.python. Unless it's
done by Guido. Then it's OK. Anyone else, just remind them that even
Hitler had better manners. That always calms things down again.
loving-usenet-despite-that-it's-usenet-ly y'rs - tim