Python to use a non open source bug tracker?

[skip]

Paul> How often should a tracker freeze anyway? People with no
Paul> technical knowledge at all run BBS systems that almost never
Paul> freeze. Is a tracker somehow more failure-prone? It's just a
Paul> special purpose BBS, I'd have thought.

And when those BBS systems get hacked they can be down for extended periods
of time. I have an old Porsche and participate in the discussion forums at
914club.com. There is a team of admins to moderate the discussion forums,
but just one guy to do the technical work. The site is powered by some
common forum software package (really a modern day bbs). It gets hacked
from time-to-time. When that happens, we're all left with the DTs while the
board gets put back together.

As for this question from Giovanni:

Giovanni> Are bug-tracker configuration issues so critical that having
Giovanni> to wait 48-72hrs to have them fixed is absolutely unacceptable
Giovanni> for Python development?

Yes, I think that would put a crimp in things. The downtimes we see for the
SourceForge tracker tend to be of much shorter duration than that (typically
a few hours) and cause usually minor problems when they occur. For the
tracker to be down for 2-3 days would make the developers temporarily blind
to all outstanding bug reports and patches during that time and prevent
non-developers from submitting new bugs, patches and comments. Those people
might well forget about their desired submission altogether and not return
to submit them once the tracker was back up.

Skip

 

[Phillip J. Eby]

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.

The goal of the selection process is to support the work of the Python
developers who have to actually *use* the bug tracking system, and
support its upkeep. In accordance with the Zen of Python, Practicality
beats purity.

P.S. The Sourceforge tracker being used now and for the past several
years isn't open source, either, so it's hardly an emergency to have an
open source tracker *now*.

 

[Terry Reedy]

(e-mail address removed) wrote:
Are bug-tracker configuration issues so critical that having to wait
48-72hrs
to have them fixed is absolutely unacceptable for Python development? It
looks
like an overexaggeration. People easily cope with 2-3 days of SVN
freezing,
when they are politically (rather than technically) stopped from
committing to
SVN. I guess they can wait 48 hrs to be able to close that bug, or open
that
other one, or run that query.

I think tracker downtime is quite possibly worse than repository downtime.
The small group of developers with SVN commit privileges are committed
enough to come back and commit their code a couple of days later. A member
of the community wanting to make a bug report is less likely too. As it
is, when SF is up, people think having to register or even log in is too
much of a burden. When SF is down, people sometimes send tracker items to
the pydev list instead, when means someone else (who?) has to put in the
tracker or it gets lost.

 

[Paul Boddie]

When SF is down, people sometimes send tracker items to
the pydev list instead, when means someone else (who?) has to put in the
tracker or it gets lost.

According to Harald Armin Massa's PostgreSQL talk at EuroPython, the
PostgreSQL people manage all their bugs via mailing lists. Given that
trends in revision control point towards completely decentralised
solutions, I wonder whether there's anything to learn from less
centralised (or more flexible) approaches to bug management.

Paul

 

[Ilias Lazaridis]

Hmm, this number does not say much. It really depends on the required
service level and how much time these two people can spend for
maintaining the tracker service.

that was not the essence of the sentence, see full context:

[REQUOTE]
You need just 2 active contributors - and the python community, not
more (it's open source - so do some plumbing yourself, even if you are
the Python Foundation).

Alternatively, why don't you place an requirement "active open source
project which can process request from the foundation"?

Because this could have a negative influence on selecting Roundup?

(this is the reverse selection process. Select the candidate and adjust
the requirements).
[/REQUOTE]

 

[proteusguy]

Jira is a remarkably well done product. We've adopted it internally and
use it for project planning (we're doing Agile) as well as defect
tracking. The plugin support and user interface just can't be touched
by the competition and I've been looking. I'd prefer an open source
python based system and maybe one day someone will make such a thing on
top of django, turbo gears, or quixote but they're gonna have a lot of
catching up to do.

-- Ben

Istvan Albert wrote:

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.

<snip>

 

[Giovanni Bajo]

Giovanni> Are bug-tracker configuration issues so critical that
having Giovanni> to wait 48-72hrs to have them fixed is
absolutely unacceptable Giovanni> for Python development?

Yes, I think that would put a crimp in things. The downtimes we see
for the SourceForge tracker tend to be of much shorter duration than
that (typically a few hours) and cause usually minor problems when
they occur. For the tracker to be down for 2-3 days would make the

I was actually thinking of 48-72hrs to do regulard admin work like installing
latest security patch or actrivate a new account.

developers temporarily blind to all outstanding bug reports and
patches during that time and prevent non-developers from submitting
new bugs, patches and comments. Those people might well forget about
their desired submission altogether and not return to submit them
once the tracker was back up.

I understand your concerns, but I have to remember you that most bug reports
submitted by users go totally ignored for several years, or, better, forever. I
do not have a correct statistic for this, but I'm confident that at least 80%
of the RFE or patches filed every week is totally ignored, and probably at
least 50% of the bugs too. I think there is a much bigger problem here wrt QOS.

So, you might prefer 6-10 people to activate a new tracker account faster than
light. I'd rather have 3-days delay in administrative issues because our single
administrator is sleeping or whatever, and then have 2-3 people doing regular
bug processing.

 

[Steve Holden]

Giovanni Bajo wrote:
[...]

I understand your concerns, but I have to remember you that most bug reports
submitted by users go totally ignored for several years, or, better, forever. I
do not have a correct statistic for this, but I'm confident that at least 80%
of the RFE or patches filed every week is totally ignored, and probably at
least 50% of the bugs too. I think there is a much bigger problem here wrt QOS.

So, you might prefer 6-10 people to activate a new tracker account faster than
light. I'd rather have 3-days delay in administrative issues because our single
administrator is sleeping or whatever, and then have 2-3 people doing regular
bug processing.

.... and if wishes were horses then beggars would ride.

regards
Steve

 

[Robert Hicks]

Moreover, this looked like a very good chance to have this nuisance sorted out.
Too bad some people don't value free software enough.

Nuisance? I never heard a peep from anyone until this thread on c.l.p.!
This is just a rediculous thing to be arguing over, really it is.

Robert

 

[Robert Hicks]

Steve Holden wrote:

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.

Hey, that is how this whole thread started! Good observation.

Robert

 

[Robert Hicks]

Giovanni Bajo wrote:

You might also be understimating how negative could be the reaction from the
open-source community to such a move.

That is simply rediculous. Step away from the kool-aid.

Robert

 

[James Graham]

Giovanni Bajo wrote:
[...]

I understand your concerns, but I have to remember you that most bug
reports
submitted by users go totally ignored for several years, or, better,
forever. I
do not have a correct statistic for this, but I'm confident that at
least 80%
of the RFE or patches filed every week is totally ignored, and
probably at
least 50% of the bugs too. I think there is a much bigger problem here
wrt QOS.

So, you might prefer 6-10 people to activate a new tracker account
faster than
light. I'd rather have 3-days delay in administrative issues because
our single
administrator is sleeping or whatever, and then have 2-3 people doing
regular
bug processing.

... and if wishes were horses then beggars would ride.

FWIW, this situation (few administrators compared to the number of
community members involved in triage) is basically the situation for the
Mozilla project's bug database (which is a bugzilla install, of course),
This was the case even before the corporation was founded so it's not a
funding issue. My impression has always been that people who kept the
bug database clean (moving things to the right component, hunting out
duplicates, verifying fixes, and so on) are seen as vital and accorded
appropriate respect by the Mozilla development community.

I don't think I have any specific point to make except, perhaps, that by
making the right noises, it is quite possible to get a useful number of
people helping with bug processing work.

 

[Giovanni Bajo]

... and if wishes were horses then beggars would ride.

Are you ever going to try and make a point which is not "you are not entitled
to have opinions because you do not act"? Your sarcasm is getting annoying. And
since I'm not trolling nor flaming, I think I deserve a little bit more of
respect.

 

[Tim Peters]

[Giovanni Bajo]

I understand your concerns, but I have to remember you that most bug reports
submitted by users go totally ignored for several years, or, better, forever. I
do not have a correct statistic for this,

Indeed you do not.

but I'm confident that at least 80% of the RFE or patches filed every week
is totally ignored, and probably at least 50% of the bugs too.

None are /totally ignored/ -- indeed, at least I see every one as it
comes in. You might want to change your claim to that no work
obviously visible to you is done on them. That would be better. But,
in fact, most bugs and patches are eventually closed, and many that
stay open involve such obscure platform-dependent mysteries that
nobody with sufficient platform expertise to resolve them appears to
exist. For example, if you'd prefer, I'll assign all bugs and patches
involving threads on HP-UX to you from now on ;-)

These are the actual stats as of a few minutes ago:

Bugs: 938 open of 7169 total ~= 87% closed
Patches: 429 open of 3846 total ~= 89% closed
Feature Requests: 240 open of 479 total ~= 50% closed

I think there is a much bigger problem here wrt QOS.

Well, you're confident that 80% of patches are ignored. In reality,
89% of all patches ever submitted have been pursued to final
resolution. Call me a stickler for detail, but something just doesn't
jibe there to my eyes ;-)

There's an easy way to improve these percentages dramatically,
although they're not bad as-is: run thru them and close every one
that isn't entirely clear. For example, reject every feature request,
close every patch that changes visible behavior not /clearly/ fixing a
bona fide bug, and close every "bug report" that's really a feature
request or random "but Perl/Ruby/PHP doesn't do it this way" complaint
in disguise.

The Python developers tend to keep a report open if there's a scant
non-zero chance that somebody, someday, might appear who's motivated
enough to make something of it. If the goal was instead to make the
percentages "look good", they could easily and justifiably be
dramatically "improved" before today ends.

For example, the oldest patch open today is a speculative
implementation of rational numbers for Python. This is really a
feature request in disguise, and has very little chance-- but not /no/
chance --of ever being accepted. The oldest bug open today is from 6
years ago, and looks like an easy-to-answer /question/ about the
semantics of regular expressions in Python 1.6. I could take time to
close that one now, but is that a /good/ use of time? Yes, but, at
the moment, even finishing this reply seems to be a /better/ use of my
time -- and after that, I'm going to get something to eat ;-)

Note that I don't mean to claim that turnaround time on bugs and
patches is ideal. To the contrary, if it's /my/ bug or patch I'm
looking at it, turnaround time sucks, and if you're looking at yours,
likewise for you. That's what happens when there are thousands of
"you"s and a handful of "them"s, all of the latter volunteering "spare
time".

OTOH, turnaround time on Python bugs classified as critical is superb.

 

[Aahz]

Are you ever going to try and make a point which is not "you are not
entitled to have opinions because you do not act"? Your sarcasm is
getting annoying. And since I'm not trolling nor flaming, I think I
deserve a little bit more of respect.

IMO, regardless of whether you are trolling or flaming, you are certainly
being disrespectful. Why should we treat you with any more respect than
you give others?

 

[Giovanni Bajo]

IMO, regardless of whether you are trolling or flaming, you are
certainly being disrespectful. Why should we treat you with any more
respect than you give others?

Disrespectful? Because I say that I don't agree with some specific requirement,
trying to discuss and understand the rationale behind it?

 

[Giovanni Bajo]

None are /totally ignored/ -- indeed, at least I see every one as it
comes in. You might want to change your claim to that no work
obviously visible to you is done on them. That would be better.

Please notice that my mail was in the context of "user satisfaction with the
bug tracker". I was claiming that it is useless to provide a blazingly fast
support turnaround for technical issue, when there is "no visibile work" being
done on most bugs that are submitted. And, in turn, this was in the context of
hiring 6-10 people as the only acceptable minimum to maintain and admin a bug
tracker. I was claiming that, if such a group was ever formed, it was better
spent on bug triage rather than keeping their keys ready all day long to
quick-fix any server breakage in minutes.

These are the actual stats as of a few minutes ago:

Bugs: 938 open of 7169 total ~= 87% closed
Patches: 429 open of 3846 total ~= 89% closed
Feature Requests: 240 open of 479 total ~= 50% closed

I claimed different numbers based on personal perception; I stand corrected,
and apologize for this. I could just say that my perception was wrong, but I
guess there's something in it that could be further analyzed. For instance, I
would be really curious to see how these figures look like if you consider only
bugs/patches/rfe *NOT* submitted by python committers. I don't think
Sourceforge can ever compute this number for us, so I'll wait to ask Roundup
about it (or, uh, Jira...).

There's an easy way to improve these percentages dramatically,
although they're not bad as-is: run thru them and close every one
that isn't entirely clear. For example, reject every feature request,
close every patch that changes visible behavior not /clearly/ fixing a
bona fide bug, and close every "bug report" that's really a feature
request or random "but Perl/Ruby/PHP doesn't do it this way" complaint
in disguise.

Either close directly any nonsense, or ask for more feedback to the poster,
until the bug/patch/rfe is sufficiently clear to be handled, or 3 months are
passed and you close the bug for "no further feedback from the poster". If this
would dramatically reduce the number of open bugs, then yes, Python really
needs someone to do bug triaging.

For example, the oldest patch open today is a speculative
implementation of rational numbers for Python. This is really a
feature request in disguise, and has very little chance-- but not /no/
chance --of ever being accepted. The oldest bug open today is from 6
years ago, and looks like an easy-to-answer /question/ about the
semantics of regular expressions in Python 1.6. I could take time to
close that one now, but is that a /good/ use of time? Yes, but, at
the moment, even finishing this reply seems to be a /better/ use of my
time -- and after that, I'm going to get something to eat ;-)

It might be not a good use of your time at all, since you are a developer. But
having a database with 938 open bugs most of which are
incomplete/nonsense/unconfirmed is much less useful than it could be. It also
raises the bar for new developers: it's much harder to just "pick one" and fix
it. I know because I tried sometimes, and after half an hour I couldn't find
any bug that was interesting to me and "complete" enough to work on it. I also
noticed that most bugs are totally uncommented like nobody cared at all. This
is where my thought about Python missing bug triaging started.

 

[skip]

Giovanni> And, in turn, this was in the context of hiring 6-10 people as
Giovanni> the only acceptable minimum to maintain and admin a bug
Giovanni> tracker.

Who said anything about "hiring"? I don't believe anyone expects any of the
6-10 people to work full-time (well, except for you it would appear). I
help moderate a number of Python-related mailing lists hosted on
mail.python.org. I also do a microscopic amount of bug triage for a couple
smallish modules in the standard distribution, have pitched in a bit to help
with the website (though don't anymore) and used to help a little bit with
administration of the various python.org machines. I certainly have never
spent anything approaching full-time for any of these tasks, not even when
measured over short time periods. A few minutes here. An hour there. Many
people contribute way more time to the overall endeavor than I do, and I
applaud them for their dedication. I haven't ever been paid nor have I ever
expected to be paid. It's a spare time activity, a way to contribute to
Python even when I can't do more.

At times I have come and gone as well, mostly depending on the constraints
of work and family obligations and my instantaneous enthusiasm for the
project. If I'd rather read a book, work on my car or watch TV, that's ok.
I don't feel guilty for the idle time I don't spend working on Python. I
know there are many other people there to cover for what little bit of work
I am not doing. I suspect that is how most people approach any of the
myriad tasks involved with getting Python out the door and keeping it
current. I think that was also the intent of the "6-10 people" phrase. If
you have lots of people available to pitch in, no one person's absence is a
show stopper.

Skip

 

[Ilias Lazaridis]

Disrespectful? Because I say that I don't agree with some specific requirement,
trying to discuss and understand the rationale behind it?

there's really not much to understand, just one thing:

There are no rationales.

This is a 'decision by feeling':

http://groups.google.com/group/comp.lang.python/msg/0334d6ff60a48991

As for Mr. Holden... it's not a matter of not respecting you.

It is in his nature to babble in this way.

Sometimes it's even funny!

..

 

[Ben Finney]

As for Mr. Holden... it's not a matter of not respecting you.
It is in his nature to babble in this way.
Sometimes it's even funny!

Oh my. You have *seriously* misjudged this group if you think that
comment will give you any net gain in discussions here.