Python to use a non open source bug tracker?

[skip@pobox.com]

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


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]

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

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]

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

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]

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

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]

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

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 "requiremen ts" 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 "intranspar ent 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@pobox.com]

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


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]

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

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]

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

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]

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

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]

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

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

[Paul Rubin]

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

"Giovanni Bajo" <noway@sorry.co mwrites:

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.

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]

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

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

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

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]

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

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]

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

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