Python to use a non open source bug tracker?

[Steve Holden]

I'm happy to, but:




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

 

[Georg Brandl]

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]

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]

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]

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

 

[skip]

Ben> This thread was started on the shock of realising that a non-free
Ben> tool was even being *considered* for the new Python bug
Ben> tracker. 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

 

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

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]

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>

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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]

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]

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

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

 

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

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]

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]

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

 

[Paul Rubin]

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]

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

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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]

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

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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