Python to use a non open source bug tracker?

[Giovanni Bajo]

Hello,

I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/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

[Steve Holden]

Ben Finney wrote:

Steve Holden <st***@holdenweb.comwrites:

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

In case readers are puzzled by the absence of the message to which Ben
replies above I should perhaps explain that I cancelled it having
decided that its language was immoderate and unfair to Ben.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Georg Brandl]

Ilias Lazaridis wrote:

Giovanni Bajo wrote:

>Hello,

I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/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.

Actually, it suggests two bugtracking tools, one of them written in
Python.

It's like saying: "The python community is not able to produce the
tools needed to drive development of python forward."

No, it's saying: "if the Python community is able to provide the
required amount of time to do the admin work, we'll use the
tool written in Python."

Anyway. The whole selection process is intransparent.

Steve has already pointed you to the wiki page.

Georg

[Fredrik Lundh]

Georg Brandl wrote:

>The python foundation suggests a non-python non-open-source bugtracking
tool for python.

Actually, it suggests two bugtracking tools, one of them written in
Python.

the announcemant's subject line said "recommendation for a new issue
tracker", though; not "we need the community's help before we can make a
final recommendation".

in fact, only 20% of the announcement talked about Python; the rest was
something that looked a lot like a press release from the non-python
hosting company, so it's not that strange that people missed the few
sentences in the middle that explained that the subject line wasn't
entirely accurate.

</F>

[Georg Brandl]

Fredrik Lundh wrote:

Georg Brandl wrote:

>>The python foundation suggests a non-python non-open-source bugtracking
tool for python.

Actually, it suggests two bugtracking tools, one of them written in
Python.

the announcemant's subject line said "recommendation for a new issue
tracker", though; not "we need the community's help before we can make a
final recommendation".

Granted.

in fact, only 20% of the announcement talked about Python; the rest was
something that looked a lot like a press release from the non-python
hosting company, so it's not that strange that people missed the few
sentences in the middle that explained that the subject line wasn't
entirely accurate.

I actually stopped reading after Brett's signature, so I didn't have the
20% figure in my mind :)

Georg

[Giovanni Bajo]

Martin v. Löwis wrote:

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

Martin, I am by no means understimating Daniel's work. I am just noting that
the spare-time work he did is, by definition, much much lower than the "6-10
people" that the PSF infrastructure committee is calling for. I would like this
statement to be officially reduced to "2-3 people", since it is *really* not
required much more than that to setup a bug tracker installation, and no more
than 1 person to maintain it afterwards. *IF* there are more volunteers, that's
good, they can offload the maintenance work from a single maintainer; but I
think it's unfair to put such a high *requisite*.

We do not have 6-10 people maintaining SVN afterall, even if you wish we had :)
--
Giovanni Bajo

[skip]

BenThis thread was started on the shock of realising that a non-free
Bentool was even being *considered* for the new Python bug
Bentracker. Those are the terms on which I've been arguing.

Of course, the candidate trackers have been known for months. Messages have
been posted to both this list and python-dev asking for inputs.

Skip

[Michael Ströder]

Giovanni Bajo wrote:

Martin, I am by no means understimating Daniel's work. I am just noting that
the spare-time work he did is, by definition, much much lower than the "6-10
people" that the PSF infrastructure committee is calling for. I would like this
statement to be officially reduced to "2-3 people", since it is *really* not
required much more than that to setup a bug tracker installation, and no more
than 1 person to maintain it afterwards.

Glancing over this thread I wonder what these people are supposed to do.
Any list of requirements available?

Ciao, Michael.

[Fredrik Lundh]

Michael Ströder wrote:

Glancing over this thread I wonder what these people are supposed to do.
Any list of requirements available?

from the original announcement (linked from the first post in this thread):

"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. /.../

If people want Roundup to be considered the tracker we go with by
volunteering to be an admin, please email infrastructure at python.org
and state your time commitment, the timezone you would be working
from, and your level of Roundup knowledge. Please email the committee
by October 16."

</F>

[Martin v. Löwis]

Michael Ströder schrieb:

>Martin, I am by no means understimating Daniel's work. I am just noting that
the spare-time work he did is, by definition, much much lower than the "6-10
people" that the PSF infrastructure committee is calling for. I would like this
statement to be officially reduced to "2-3 people", since it is *really* not
required much more than that to setup a bug tracker installation, and no more
than 1 person to maintain it afterwards.

Glancing over this thread I wonder what these people are supposed to do.
Any list of requirements available?

Anybody can help who has general experience with "server
administration"; if you do, you know what typical problems are.
In addition, you either should know how roundup works already,
or should be willing to learn it as you go (from the fellow
volunteers who have more insights).

I can't personally anticipate what problems occur; it's only
clear that the volunteers should "just make it work".
The regular admin tasks likely include stuff like this:
- the system is unavailable, bring it back to work
This is really the worst case, and a short response time
is the major factor in how users perceive the service
- the system is responding very slowly
- "when I do this operation, it doesn't work" or
"when I do this operation, I get that error"
- "why does this f*cking system require me to do foo,
I don't want that"

There might also be the need for regular maintenance.
Ad hoc, the only thing that comes to mind is user
account maintenance: what users get what permissions.
Traditionally (because of the SF model), Python committers
get "admin" rights on the tracker, i.e. the right to close
issues they didn't create. Not sure what the best model
is for Roundup (roundup expertise is needed to propose
an appropriate access control model). Other regular
maintenance might involve spam removal; ideally,
this would be minimal due to a well-thought access
control.

Finally, there might be a need for customization,
perhaps by means of implementing new features. Clearly,
whether features can be implemented depends on the
amount of volunteer time available and neede, and also
on the importance of the requested feature. For example,
in SF, we requested that the "Check to upload" button
is removed; it took SF several years to implement that
request.

Regards,
Martin

[Ilias Lazaridis]

Steve Holden wrote:

Ilias Lazaridis wrote:

Giovanni Bajo wrote:

>Hello,

I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/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.

Is there any stick in the known universe that you will grasp the *right*
end of?

http://wiki.python.org/moin/OriginalCallForTrackers

Please have a little bit more precision:

"Because we are not sure exactly what are requirements for a tracker
are we do not have a comprehensive requirements document."
http://wiki.python.org/moin/OriginalCallForTrackers

This document is empty:

http://wiki.python.org/moin/GoodTrackerFeatures

This is what I call "intransparent selection process" or "selectiong by
feelings".

-

The central requirement for a development-infrastructure / Host is
_control_:

http://case.lazaridis.com/wiki/Host

My personal selection for a tracking-system for a python based projects
is Trac:

http://case.lazaridis.com/wiki/Tracking

I context of the python project (which has own wiki), Roundup could
become the No.1 choice.

I am biased towards trac, but to be honest, I've not verified Roundup
deeper (due to the missing wiki-svn-ticket-integration, which is Trac's
major strength).

So, define the Goals, specify the resulting Requirements, and _after_
this, verify the Tools (Trac, Roundup) against those requirements -
otherwise the whole "comitee" thing becomes just a joke.

Another joke is to 'scare' the community with a non-open-source java
tracker, in order to get 6 to 10 contributors.

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

In any way, the 'comitee' should really stop talking about JIRA in
context of python. This sounds really like a joke of bad taste.

btw: If JIRA is selected finally, the I have really to revise my
decision to choose python for my projects. Simply because I would be
afraid that the Python Foundation can't move Python into a leading
position.

http://case.lazaridis.com/wiki/Lang

-

btw: I like both tools, JIRA (nice design) and Roundup (simplicity, db
layer)

..

[skip]

MartinThe regular admin tasks likely include stuff like this:
Martin- the system is unavailable, bring it back to work
Martin This is really the worst case, and a short response time
Martin is the major factor in how users perceive the service
Martin- the system is responding very slowly

To all those people who have been moaning about needing 6-10 people to
administer the system, in my opinion these are the most important reasons to
have more than one person available to help. Python isn't only used in the
USofA. It has been very helpful to have administrators scattered around the
globe who were awake and alert to handle problems with python.org when folks
in the US were asleep. Of course, spreading the load among several people
helps with the other tasks as well.

As Martin pointed out in an earlier post, with only one person actively
administering Subversion (Martin), new requests for access had to wait if he
was away for an extended period of time.

Skip

[Ian Bicking]

Paul Boddie wrote:

Perhaps, although I imagine that Trac would have a lot more uptake if
it handled more than just Subversion repositories.

It handles some other kinds of repositories now (bzr, I think?). From
what I understand fully abstracting out the repository format seems to
still be a work in progress, but it is in progress and you can write
repository plugins right now.

[...]

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.

Trac now includes a WSGI backend, and someone has written a WSGI
backend for ViewVC (though I don't know if it is included with the
project).

Clearly you need to get on the WSGI bandwagon ;)

Ian

[Michael Ströder]

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.

Ciao, Michael.

[Giovanni Bajo]

Martin v. Löwis wrote:

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.

You have many good points here, Martin. Let me notice, though, that people
providing hosting not necessarily want to maintain the software by themselves
alone: some python developers could still have admin access to the boxes so to
double check if weird things are being done behind the curtain. I think the
point of uncertainty araises only if you totally trust someone else to do the
job for you.
--
Giovanni Bajo

[Giovanni Bajo]

sk**@pobox.com wrote:

MartinThe regular admin tasks likely include stuff like this:
Martin- the system is unavailable, bring it back to work
Martin This is really the worst case, and a short response time
Martin is the major factor in how users perceive the service
Martin- the system is responding very slowly

To all those people who have been moaning about needing 6-10 people to
administer the system, in my opinion these are the most important
reasons to have more than one person available to help. Python isn't
only used in the USofA. It has been very helpful to have
administrators scattered around the globe who were awake and alert to
handle problems with python.org when folks in the US were asleep. Of
course, spreading the load among several people helps with the other
tasks as well.

As Martin pointed out in an earlier post, with only one person
actively administering Subversion (Martin), new requests for access
had to wait if he was away for an extended period of time.

This is true of many open source projects. I don't dispute that having 6-10
people to administer Roundup would not be good. I dispute that it is the
minimum requirement to make a Roundup installation acceptable for Python
development.

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

[Paul Rubin]

"Giovanni Bajo" <no***@sorry.comwrites:

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.

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

[Paul Boddie]

Ian Bicking wrote:

>
It handles some other kinds of repositories now (bzr, I think?). From
what I understand fully abstracting out the repository format seems to
still be a work in progress, but it is in progress and you can write
repository plugins right now.

That covers Trac, but other projects probably need to get up to speed
with providing similar functionality, too. This is another case where
people should work together rather than developing an interoperability
layer specific to their own project. Certainly, the Bazaar APIs looked
like some kind of promising umbrella project for that kind of thing.

Trac now includes a WSGI backend, and someone has written a WSGI
backend for ViewVC (though I don't know if it is included with the
project).

Clearly you need to get on the WSGI bandwagon ;)

Hey, WebStack supports WSGI, too, you know. ;-)

Paul

[Martin v. Löwis]

Paul Rubin schrieb:

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

For whatever reason, the SF bug tracker is often down, or not
responding. I'm uncertain why that is, but it's a matter of
fact that this was one of the driving forces in moving away
from SF (so it is a real problem).

Regards,
Martin

[Paul Boddie]

Martin v. Löwis wrote:

>
For whatever reason, the SF bug tracker is often down, or not
responding. I'm uncertain why that is, but it's a matter of
fact that this was one of the driving forces in moving away
from SF (so it is a real problem).

As I asked before, did anyone look into asking large-scale users of the
various considered products about their experiences with regard to
reliability, scalability, and so on? Obviously, SourceForge is a
special case since it's a closed service with a code base divergent
from the last open source release (and possibly from commercial
deployments of the code), whereas the other contenders except for
Launchpad, along with non-considered but widely-deployed products,
presumably contribute to a certain amount of public experience that can
be drawn upon.

Paul

[Martin v. Löwis]

Paul Boddie schrieb:

As I asked before, did anyone look into asking large-scale users of the
various considered products about their experiences with regard to
reliability, scalability, and so on?

I didn't ask anyone, primarily because of lack of time.

Regards,
Martin

[skip]

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]

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]

"Giovanni Bajo" <no***@sorry.comwrote in message
news:Yz**********************@twister1.libero.it.. .

sk**@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 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]

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]

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]

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]

sk**@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]

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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Robert Hicks]

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]

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]

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]

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

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]

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

In article <0B**********************@twister1.libero.it>,
Giovanni Bajo <no***@sorry.comwrote:

>
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 (aa**@pythoncraft.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

[Giovanni Bajo]

Aahz wrote:

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

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

[Giovanni Bajo]

Tim Peters wrote:

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

[skip]

GiovanniAnd, in turn, this was in the context of hiring 6-10 people as
Giovannithe only acceptable minimum to maintain and admin a bug
Giovannitracker.

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]

Giovanni Bajo wrote:

Aahz wrote:

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?

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....34d6ff60a48991

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]

"Ilias Lazaridis" <il***@lazaridis.comwrites:

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.

--
\ "I think there is a world market for maybe five computers." -- |
`\ Thomas Watson, chairman of IBM, 1943 |
_o__) |
Ben Finney

[Aahz]

In article <2v*********************@twister2.libero.it>,
Giovanni Bajo <no***@sorry.comwrote:

>Aahz wrote:

>Giovanni removed his own attribution:

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

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

*snort* Now you're trying to dodge responsibility for your own words.
Normally I'd be inclined to cut you some slack because English isn't your
native language, but it's clear that you're deliberately trying to write
emotionally to encourage other people to flail around. Here are again
some of the things you've written in this thread:

Does this smell "Bitkeeper fiasco" to anyone else than me?
I am impressed you do not want to understand the "why"
most bug reports submitted by users go totally ignored for several years,

That adds up to a clear summation of disprespect in my view.
--
Aahz (aa**@pythoncraft.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

[Ilias Lazaridis]

Ben Finney wrote:

"Ilias Lazaridis" <il***@lazaridis.comwrites:

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.

I'm not interested in any gain (except within the systems that I
produce).

My intention was mainly to place myself on the side of the OP, before
the 'Herd of Savages' (the 'Regular Posters') get's out of control and
eat's him.

..

[Terry Reedy]

"Giovanni Bajo" <no***@sorry.comwrote in message
news:nM*********************@twister2.libero.it...

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.

This could be made into an argument for accepting the Jira offer so we
don't 'waste' *any* more Python-knowledgable volunteer time on admin.
However, thinking about it more, I think that wrestling with a software
system like Roundup and interacting with sometimes naive and non-responsive
bug submitters are two different skills and likely to attract different
volunteers.

[snip]

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.

I have thought this for some time based on my occasional efforts at
'first-response' reviewing. But I have not tried to do anything because of
the difficulty of working with the SF tracker. Perhaps submissions by new
submitters should start in 'limbo' until rejected or accepted into active
open status. I hope that whichever new tracker we get will allow for
automated followups at determined intervals, such as 3 mos or whatever.

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.

Perhaps when the new tracker is set up, you can help scratch the 'too many
open bugs' itch.

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.

s/most/some/

When I read a bug with no comment I sometimes put extra energy into
thinking of something to say or ask just so the reporter will know the
report has been read.

Terry Jan Reedy

[Martin v. Löwis]

Giovanni Bajo schrieb:

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

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.

You seem to imply that people who are willing to do roundup admin could
regularly, easily do bug triage, and also would be willing to do so. I
can attest that this assumption is sooooooo remote from the truth that
I can't really believe you really meant it.

I have called for people doing bug review and providing patches many
many times, and most of these calls got unheard.

Regards,
Martin

[Martin v. Löwis]

Paul Boddie schrieb:

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

From my experience with GCC, I can only report that this is definitely
not working. There used to be a mailing list bu**@gcc.gnu.org, and
reports got either answered immediately, or not at all. People who
thought they were responsible put the mails in some folder, and then
never found the time to come back. This is why I set up a bug tracker
for GCC.

Regards,
Martin

[Fredrik Lundh]

Martin v. Löwis wrote:

>>From my experience with GCC, I can only report that this is definitely

not working. There used to be a mailing list bu**@gcc.gnu.org, and
reports got either answered immediately, or not at all. People who
thought they were responsible put the mails in some folder, and then
never found the time to come back.

you need tools to help you track the bugs and their status, but you can
handle issue registration, discussion, and most maintenance stuff using
good old mail just fine.

</F>

[skip]

Fredrikyou need tools to help you track the bugs and their status, but
Fredrikyou can handle issue registration, discussion, and most
Fredrikmaintenance stuff using good old mail just fine.

Which is something SourceForge has yet to learn. At work we use a system
called RT (http://www.bestpractical.com/rt/). While it's not perfect, it
does allow submissions and responses via email. That feature alone puts it
miles ahead of SF in my mind.

Skip

[Paul Rubin]

sk**@pobox.com writes:

Which is something SourceForge has yet to learn. At work we use a system
called RT (http://www.bestpractical.com/rt/). While it's not perfect, it
does allow submissions and responses via email. That feature alone puts it
miles ahead of SF in my mind.

I'm on the other side--I think spam has destroyed the usefulness of
email as a communications medium and I don't want to depend on
anything having to do with email any more. I hate the way SF requires
registering an email address and then it emails you every update to
your SF issues. As a low-intensity user, I sort of tolerate it. But
if I used SF more, I'd have to direct all the SF email to a spam
bucket and never look at it. At most I'd want it to send about one
email per week. But I'd much rather have a personalized RSS feed that
delivers updates about the bugs that I'm following.

I also notice that the PyPy mailing list now delivers mostly spam, so
I've had to direct that to a spam bucket.

[Michael Ströder]

sk**@pobox.com wrote:

Fredrikyou need tools to help you track the bugs and their status, but
Fredrikyou can handle issue registration, discussion, and most
Fredrikmaintenance stuff using good old mail just fine.

Which is something SourceForge has yet to learn. At work we use a system
called RT (http://www.bestpractical.com/rt/). While it's not perfect, it
does allow submissions and responses via email. That feature alone puts it
miles ahead of SF in my mind.

I'd also prefer to at least be able to respond to tracker items via
e-mail. I'm traveling a lot by train working off-line most times. An
e-mail spool is unbeatable in this situation. So it's ok for me to add
an issue to a tracker while being online. But the follow-ups should be
possible via e-mail. SF pretty much sucks in this regard (and has other
issues too).

The main reason why I'm following this discussion is that I'd also
prefer to move away from SF for python-ldap. One reason is availability
and the other one is the really bad user interface.

I could imagine to spend some spare time when this infrastructure can
also be used for python-ldap. And pydns would be another candidate to be
moved away from SF.

Ciao, Michael.

[Michael Ströder]

Paul Rubin wrote:

sk**@pobox.com writes:

>>Which is something SourceForge has yet to learn. At work we use a system
called RT (http://www.bestpractical.com/rt/). While it's not perfect, it
does allow submissions and responses via email. That feature alone puts it
miles ahead of SF in my mind.

I'm on the other side--I think spam has destroyed the usefulness of
email as a communications medium and I don't want to depend on
anything having to do with email any more.

E-mail spam is an issue but the python.org infrastructure already has to
do spam filtering for mailing lists. Or does it simply resend all mail?

Ciao, Michael.