Python to use a non open source bug tracker?

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

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]

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.

 

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

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

Perhaps what I *should* have written was "Sadly *many* people spend too
much time bitching and moaning about those that roll their sleeves up,
and not enough rolling their own sleeves up and pitching in".

Sniping from the sidelines is far easier than hard work towards a goal.

Kindly note that none of the above remarks apply to you.

regards
Steve

 

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

 

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

 

[Steve Holden]

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]

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

 

[Valentino Volonghi aka Dialtone]

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]

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

 

[skip]

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

 

[skip]

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]

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.

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]

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.

 

[fuzzylollipop]

Hello,

I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/python-dev/2006-October/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.

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

No 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