Python to use a non open source bug tracker?

[skip@pobox.com]

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


PaulHow often should a tracker freeze anyway? People with no
Paultechnical knowledge at all run BBS systems that almost never
Paulfreeze. Is a tracker somehow more failure-prone? It's just a
Paulspecial 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:

GiovanniAre bug-tracker configuration issues so critical that having
Giovannito wait 48-72hrs to have them fixed is absolutely unacceptable
Giovannifor 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]

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

Giovanni Bajo 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.

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]

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


"Giovanni Bajo" <noway@sorry.co mwrote in message
news:YzoVg.1370 36$zy5.1843214@ twister1.libero .it...

skip@pobox.com 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 overexaggeratio n. 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]

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

Terry Reedy wrote:

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

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


Michael Ströder wrote:

Ilias Lazaridis wrote:

You need just 2 active contributors - and the python community, not
more

>
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@gmail.com]

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

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

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]

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

skip@pobox.com wrote:

GiovanniAre bug-tracker configuration issues so critical that
having Giovannito wait 48-72hrs to have them fixed is
absolutely unacceptable Giovannifor 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.
--
Giovanni Bajo

[Steve Holden]

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

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

[Robert Hicks]

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


Giovanni Bajo wrote:

Paul Rubin wrote:
>

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.

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]

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


Steve Holden wrote:
<snip>

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]

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


Giovanni Bajo wrote:
<snip>

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

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

Robert

[James Graham]

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

Steve Holden wrote:

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
>administrato r 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]

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

Steve Holden 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.

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.
--
Giovanni Bajo

[Tim Peters]

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

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

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

In article <0BQVg.138807$z y5.1859480@twis ter1.libero.it> ,
Giovanni Bajo <noway@sorry.co mwrote:

>
>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?
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra