Python to use a non open source bug tracker?

[Paul Rubin]

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

Steve Holden <steve@holdenwe b.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.

[Harry George]

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

"Fredrik Lundh" <fredrik@python ware.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

[Steve Holden]

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

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

[Steve Holden]

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

Valentino Volonghi aka Dialtone wrote:

Terry Reedy <tjreedy@udel.e duwrote:
>
>

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

[Valentino Volonghi aka Dialtone]

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

Steve Holden <steve@holdenwe b.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

[Fredrik Lundh]

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

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.

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

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

Fredrik Lundh wrote:

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]

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

Giovanni Bajo wrote:

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

[skip@pobox.com]

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


GiovanniIn fact, are you absolutely positive that you need so much
Giovannieffort 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

[skip@pobox.com]

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


IstvanI think you are missing the point. Switching to a different
Istvantracker is not such a big deal. Having a really good tracker is
Istvana 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]

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

skip@pobox.com wrote:

GiovanniIn fact, are you absolutely positive that you need so
much Giovannieffort 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.

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]

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

Steve Holden wrote:

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]

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


Giovanni Bajo wrote:

Hello,
>
I just read this mail by Brett Cannon:

http://mail.python.org/pipermail/python-dev/2006-October/069139.html

where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
>
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
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]

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

On 04 Oct 2006 06:44:24 -0700,
Paul Rubin <wrote:

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]

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

Giovanni Bajo wrote:

>
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.pytho n/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