Discussion:
Python to use a non open source bug tracker?
(too old to reply)
Nick Craig-Wood
2006-10-04 09:30:03 UTC
Permalink
lbolognini at gmail.com <lbolognini at gmail.com> wrote:
> And i dunno what the case against Trac is (it looks a fine tool for my
> small projects) but probably it's not good enough for python.org

Trac is really good in my experience.

http://trac.edgewall.org/

Python.org has already moved to svn so trac is surely the next part of
the equation. Having an integrated Bugtracker / Wiki / Svn repository
browser is very helpful.

We use it for all our commercial work.

It is also in use by MythTV which judging by the volume of its mailing
lists is about or more active a project than python.

http://svn.mythtv.org/trac/

A nice extra is that it is written in python.

--
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick
Steve Holden
2006-10-05 07:24:51 UTC
Permalink
Ben Finney wrote:
> Steve Holden <steve at holdenweb.com> writes:
>
>
>>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 +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
Steve Holden
2006-10-05 06:20:35 UTC
Permalink
Terry Reedy wrote:
> "Ben Finney" <bignose+hates-spam at benfinney.id.au> wrote in message
> news:87lknvelb3.fsf at benfinney.id.au...
>
>>The whole point of moving *from* SF *to* another bug tracker is to
>>improve the situation, surely.
>
>
> The current situation is that the limitations and intermittant failures of
> the SF tracker sufficiently impede the Python development process that some
> people were motivated to do the work to find a better alternative.
>
>
>>You already seem to acknowledge that using free-software tools to
>>develop Python is desirable.
>
>
> The committee already said so by saying that with other things equal, it
> would choose Roundup.
>
>
>>I don't see why you're being so obtuse
>
>
> I think name calling is out of line here.
>
Correct, besides which Ben seems to feel people are disagreeing on the
desirability of using open source software when in fact they are mostly
disagreeing about the *practicality* in this particular instance.

Compellingly absent from most critics' output is a statement to the
effect that they will volunteer their time to encourage the adoption of
Roundup, which is excluded only by the absence of a support infrastructure.

Time to shit or get off the pot, I'd say.

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
Harry George
2006-10-04 05:08:28 UTC
Permalink
"Fredrik Lundh" <fredrik at pythonware.com> writes:

> Steve Holden wrote:
>
> > But sadly people are much happier complaining on c.l.py than exerting
> > themselves to support the community with an open source issue tracker.
>
> you're not on the infrastructure list, I hear. python.org could still need a
> few more roundup volunteers, but it's not like nobody's prepared to con-
> tribute manhours. don't underestimate the community.
>
> </F>
>
>
>

I'm not on the infrastructure list either. But I wonder why it is
"Roundup or else non-python COTS"? I gave up on Roundup a while ago
due to too many crashes. I'm now using Trac:

a) Open Source
b) Python
c) Adequate functionality (for me at least)

http://trac.edgewall.org/

I'm not trying to "sell" Trac, but I would like to know what drove the
developers away from it.

--
Harry George
PLM Engineering Architecture
Ben Finney
2006-10-10 01:25:09 UTC
Permalink
Magnus Lycka <lycka at carmen.se> writes:

> Fredrik Lundh wrote:
> > python.org could still need a few more roundup volunteers, but
> > it's not like nobody's prepared to contribute manhours. don't
> > underestimate the community.
>
> So, how many have offered to help? Is this information available in
> some public repository?

I don't yet know of private discussions leading to it, but Brett
Cannon has made an unofficial announcement that Roundup has been
picked:

I am making an unofficial announcement here that it looks like we
will be able to go with Roundup as the issue tracker for
python-dev. Now this does not mean people should stop volunteering
by emailing infrastructure at python.org! We have not finalized
which of the volunteers will be asked to help admin the Roundup
installation so if you want to help please email us with your
timezone, rough amount of time you can donate per week, and your
Roundup experience.

This announcement is unofficial because there has been an offer
for professional Roundup hosting. We are awaiting the details of
the offer before deciding how to proceed. Once we have decided how
we are going to handling hosting there will be an official
announcement with more details.

<URL:http://sayspy.blogspot.com/2006/10/looks-like-we-will-be-going-with.html>

--
\ "The face of a child can say it all, especially the mouth part |
`\ of the face." -- Jack Handey |
_o__) |
Ben Finney
Paul Boddie
2006-10-04 15:22:06 UTC
Permalink
Fredrik Lundh wrote:
> Valentino Volonghi wrote:
>
> > Considering that trac can also run on postgres or mysql and also
> > considering that both of these databases have enough tools to deal with
> > backups I think it's a non issue.
>
> 10k entries shouldn't be much of an issue for sqlite3 either.

Out of interest, here are some figures:

KDE: 12983 bugs and 11656 wishes
GNOME: 23624 reports
Python: 7159 bugs, 3843 patches, 477 feature requests

The Python figures are totals, whereas I can't be sure whether the KDE
and GNOME figures merely refer to the open issues. Nevertheless, Python
isn't going to be pushing the envelope.

Paul
&quot;Martin v. Löwis&quot;
2006-10-04 20:31:48 UTC
Permalink
Paul Boddie schrieb:
> Out of interest, here are some figures:
>
> KDE: 12983 bugs and 11656 wishes
> GNOME: 23624 reports
> Python: 7159 bugs, 3843 patches, 477 feature requests
>
> The Python figures are totals, whereas I can't be sure whether the KDE
> and GNOME figures merely refer to the open issues. Nevertheless, Python
> isn't going to be pushing the envelope.

Right: machine power isn't really an issue (although the snappiness
of response does contribute to usability: the various installations
showed noticable differences in response time).

The issue of scalability is really how a large number of reports
can be managed. How can a submitter easily find out whether a report
for some issue already exists, and how can a maintainer easily find
out what needs most attention (where each developer might apply
her own priority system)? For a small number of issues, you can
scan through a list. If the list contains more than 20 entries,
scanning through it becomes tedious.

Regards,
Martin
&quot;Martin v. Löwis&quot;
2006-10-04 21:13:35 UTC
Permalink
Paul Rubin schrieb:
> "Martin v. L?wis" <martin at v.loewis.de> writes:
>> 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.

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.

Despite what other people say, this *is* an issue. On python.org,
things that should get done don't, just because there is no
volunteer doing them. Hosting such a service elsewhere has the
clear advantage that you don't have to worry about most routine
maintenance jobs.

Regards,
Martin
unknown
2006-10-04 21:25:12 UTC
Permalink
"Martin v. L?wis" <martin at v.loewis.de> writes:
> 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.

True, though GPL 3 tries to address that. Most important is to figure
out the underlying attitude of the host. I realize it's the same
crufty software (or worse) as SF and therefore maybe not so attractive
on those grounds already, but did you think about migrating to
Savannah?

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

Well, if the cash is available, there's always the possibility of
using free software and paying someone to host it. Anyway, I wouldn't
have expected running a tracker to be that significant a task compared
with the rest of the web site, the mailing lists, the Subversion
server, the codebase itself, etc. etc. But Paul Boddie explained some
of the issues pretty well.

> Despite what other people say, this *is* an issue. On python.org,
> things that should get done don't, just because there is no
> volunteer doing them. Hosting such a service elsewhere has the
> clear advantage that you don't have to worry about most routine
> maintenance jobs.

I have to wonder too why Jira is so sure to be more reliable than SF.
&quot;Martin v. Löwis&quot;
2006-10-04 21:57:24 UTC
Permalink
Paul Rubin schrieb:
> True, though GPL 3 tries to address that. Most important is to figure
> out the underlying attitude of the host. I realize it's the same
> crufty software (or worse) as SF and therefore maybe not so attractive
> on those grounds already, but did you think about migrating to
> Savannah?

We had a very clear procedure. We (the committee) didn't want to
manage the installation ourselves, or figure out how to set up
the software, or get the data into it. Instead, we sent out a call
to the community to come up with a demo installation for evaluation
purposes. Nobody offered to migrate the data into Savannah, so
we didn't consider it (nobody actually offered to show-case
Savannah for us, period).

There were several reasons to get off SF; it not being open
source was never a reason. Instead, ongoing complaints about
service level, and the UI were the main complaints. Savannah
is IMO worse than SF wrt. user interface, so it would have
lost in the evaluation even if a demo installation was provided.
We want to improve with that switch, not decrease usability.

>> Despite what other people say, this *is* an issue. On python.org,
>> things that should get done don't, just because there is no
>> volunteer doing them. Hosting such a service elsewhere has the
>> clear advantage that you don't have to worry about most routine
>> maintenance jobs.
>
> I have to wonder too why Jira is so sure to be more reliable than SF.

It may change as time evolves, but at the moment, they are *pretty*
responsive to our inquiries. Atlassian (the company behind it) uses
the same infrastructure for their commercial offerings, as well;
this might mean that we get the same availability (it might also
mean that paying customers get more attention than non-paying ones
in the long term).

With any kind of partner, there is always the risk that they don't
deliver, and you always have to invest some trust in the beginning.
It was this way when Guido moved Python to SF, and indeed, SF did
a very good job for several years (IMO). They only went unreliable
when they grow beyond expectations. The same could happen to
Atlassian, of course, in which case we would have to move again.

OTOH, the same could also happen with a group of volunteers.
It's always possible that they all run away (like that distutils
is unmaintained, and PyXML is unmaintained). Volunteers are actually
unlikely to persist in their efforts over a period of 10 years,
as their lifes and priorities change over time. If you trust
such a service to a single volunteer, you might find that the
service can become very unusable very quickly. For example, the
Python Job Board was in a very bad shape for several months,
until we managed to find Peter Kropf to take it over (who
does a very good job ever since he started).

Regards,
Martin
Giovanni Bajo
2006-10-08 00:38:43 UTC
Permalink
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
2006-10-08 01:13:54 UTC
Permalink
Giovanni> And, in turn, this was in the context of hiring 6-10 people as
Giovanni> the only acceptable minimum to maintain and admin a bug
Giovanni> tracker.

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

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

Skip
Terry Reedy
2006-10-08 20:18:59 UTC
Permalink
"Giovanni Bajo" <noway at sorry.com> wrote in message
news:nMXVg.139289$_J1.908829 at 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
unknown
2006-10-04 13:44:24 UTC
Permalink
Steve Holden <steve at holdenweb.com> writes:
> Sniping from the sidelines is far easier than hard work towards a goal.

Right now there is not even agreement on what the goal is. The
surprise people are expressing is because they thought one of the
goals of a big open source project would be to avoid reliance on
closed tools.
Giovanni Bajo
2006-10-04 21:16:10 UTC
Permalink
A.M. Kuchling wrote:

>> The surprise people are expressing is because they thought one of the
>> goals of a big open source project would be to avoid reliance on
>> closed tools.
>
> I don't think Python has ever had this as a goal. Python's license
> lets it be embedded in closed-source products; Windows binaries are
> built using closed-source tools (MS Visual C), and on some platforms
> we use a closed-source system compiler; python.org used to be a
> Solaris box, and now uses SourceForge which runs on top of DB/2...

Notice that there is a different between "allowing/helping/supporting non-free
software" and "avoid reliance on non-free software". The fact that Python
license allows it to be used in non-free products falls in the former, while
the usage of Jira is part of the latter. Distributing binaries compiled with
closed-source tools is not a problem since people can still compile it with
different free compilers.

> IMHO, using Jira presents risks that are manageable:
> [...]
>
> * A data export is available if we decide to switch. [...]

Out of curiosity, how is this obtained? Is this any plan to take a daily export
or so?
--
Giovanni Bajo
A.M. Kuchling
2006-10-04 17:53:36 UTC
Permalink
On 04 Oct 2006 06:44:24 -0700,
Paul Rubin <> wrote:
> Right now there is not even agreement on what the goal is.

The goal is a new tracker for python.org that the developers like
better; the original call lists 3 reasons (bad interface; lack of
reliability; lack of workflow controls).

> The surprise people are expressing is because they thought one of the
> goals of a big open source project would be to avoid reliance on
> closed tools.

I don't think Python has ever had this as a goal. Python's license
lets it be embedded in closed-source products; Windows binaries are
built using closed-source tools (MS Visual C), and on some platforms
we use a closed-source system compiler; python.org used to be a
Solaris box, and now uses SourceForge which runs on top of DB/2...

IMHO, using Jira presents risks that are manageable:

* A data export is available if we decide to switch. Writing a script to
take this export and convert to a new tracker is non-trivial, but the
same is true of any other tracker we might choose; switching from
Roundup to Trac or Trac to Launchpad is also going to require some
effort. Therefore, I don't think our data is locked-in any more
than any other tracker.

* The offer of hosting means this won't consume very much
administrative time. Perhaps the hosting offered will be found to be
unreliable. If that's the case, we can reconsider the choice of
tracker, or (less likely) host Jira ourselves.

* There are no Bitkeeper-like licensing issues like the non-compete
clause, so that isn't a factor; Roundup and Trac developers can file
bugs and use the tracker just like anyone else.

* The interface is very flexible and lots of customization can be done
through the web. This means we don't have to hack the code at all,
and upgrades should theoretically go smoothly.

It would be nice to have the additional tick-box feature 'is open
source', but the upsides are large enough that I can let go of
that issue with only slight regret.

--amk
Giovanni Bajo
2006-10-04 21:09:04 UTC
Permalink
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.
--
Giovanni Bajo
&quot;Martin v. Löwis&quot;
2006-10-04 22:08:53 UTC
Permalink
Fredrik Lundh schrieb:
> what I was trying to say (between the lines) was that not only have
> the people on that list worked hard to do the evaluation (not to mention
> all the developers around the world that has worked even harder to set
> up test trackers)

That cannot be praised enough. Special thanks to Jonathan Nolen from
Atlassian to set up the Jira installation, Stefan Seefeld to set up
the Roundup installation, Alec Thomas for the Trac installation,
and James Henstridge for adding Python to the Launchpad.

To all those who complain that their favorite software XYZ wasn't
considered: apparently, nobody in the community bothered enough to
respond to the call for trackers. If nobody experienced with the
software thinks it is worthwhile to set up a demo it,
why should we review it?

Regards,
Martin
Robert Kern
2006-10-03 08:33:27 UTC
Permalink
Giovanni Bajo wrote:
> Hello,
>
> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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?

No.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Fredrik Lundh
2006-10-03 09:06:44 UTC
Permalink
Robert Kern wrote:

>> Does this smell "Bitkeeper fiasco" to anyone else than me?
>
> No.

that's just not true. lots of people have voiced concerns over using
closed-sourced stuff originally designed for enterprise-level Java users
for an application domain where Python has several widely used agile
alternatives to chose from.

if they hadn't done so, there probably wouldn't have been an evaluation
period in the first place.

</F>
Fredrik Lundh
2006-10-03 19:12:56 UTC
Permalink
Robert Kern wrote:

> Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?

depends on what you consider being the cause of that fiasco. I'm not
sure it was quite as simple as people are trying to make it sound...

(and your assertion that nobody but giovanni has made that connection is
simply wrong)

</F>
unknown
2006-10-04 01:42:16 UTC
Permalink
Fredrik Lundh <fredrik at pythonware.com> writes:
> > Sure. But what's the similarity to the fiasco part of the BitKeeper fiasco?
>
> depends on what you consider being the cause of that fiasco. I'm not
> sure it was quite as simple as people are trying to make it sound...

I remember there being some urgency to move away from BitKeeper
because some counter (like a 16-bit file version number that got
incremented on every check-in of the file, or something like that) was
about to overflow, and only the non-free version allocated more bits
for the counter. That was why Git had to be thrown together in just a
few weeks.
Giovanni Bajo
2006-10-04 21:06:59 UTC
Permalink
Martin v. L?wis wrote:

>> Frankly, I don't give a damn about the language the application is
>> coded in
>
> That's probably one of the reasons why you aren't a member of the
> Python Software Foundation. Its mission includes to publicize,
> promote the
> adoption of, and facilitate the ongoing development of Python-related
> technology and educational resources. So the tracker being written in
> Python is quite of importance.

So we have a problem between the PSF and the "PSF infrastructure committee",
since the latter did not put "being written in Python" has a requirement for
the tracker.
--
Giovanni Bajo
Ben Finney
2006-10-05 06:33:43 UTC
Permalink
Steve Holden <steve at holdenweb.com> writes:

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

--
\ "Why, I'd horse-whip you if I had a horse." -- Groucho Marx |
`\ |
_o__) |
Ben Finney
Fredrik Lundh
2006-10-05 06:18:33 UTC
Permalink
Steve Holden wrote:

> You appear to be prepared to go to any length short of providing effort
> to support the open source tracker.

http://www.userland.com/whatIsStopEnergy

</F>
Giovanni Bajo
2006-10-04 07:39:56 UTC
Permalink
Fredrik Lundh wrote:

> that's just not true. lots of people have voiced concerns over using
> closed-sourced stuff originally designed for enterprise-level Java
> users for an application domain where Python has several widely used
> agile alternatives to chose from.

Frankly, I don't give a damn about the language the application is coded in, as
long as it is OUR application and not an application of a private company which
we do not own.

Even though you are totally right.
--
Giovanni Bajo
skip
2006-10-08 21:36:02 UTC
Permalink
Fredrik> you need tools to help you track the bugs and their status, but
Fredrik> you can handle issue registration, discussion, and most
Fredrik> maintenance 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
Fredrik Lundh
2006-10-08 21:19:11 UTC
Permalink
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 bugs at 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>
Michael Ströder
2006-10-09 09:23:22 UTC
Permalink
skip at pobox.com wrote:
> Fredrik> you need tools to help you track the bugs and their status, but
> Fredrik> you can handle issue registration, discussion, and most
> Fredrik> maintenance 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.
skip
2006-10-09 12:59:54 UTC
Permalink
Michael> E-mail spam is an issue but the python.org infrastructure
Michael> already has to do spam filtering for mailing lists. Or does it
Michael> simply resend all mail?

Email sent to most mailing lists hosted on mail.python.org are passed
through a SpamBayes instance before being forwarded to the list's members.

Skip
unknown
2006-10-08 21:45:29 UTC
Permalink
skip at 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.
&quot;Martin v. Löwis&quot;
2006-10-03 19:58:44 UTC
Permalink
Paul Rubin schrieb:
> Ben Finney <bignose+hates-spam at benfinney.id.au> writes:
>> The existing SourceForge system runs on non-free software, which is a
>> significant differentiator from Bugzilla.
>
> The SourceForge software, at least in some versions, is free software.
> See for example http://savannah.gnu.org for an instantiation, which
> may be a fork. I never followed the saga much.

It is a fork of an old version. Existence of this version hasn't helped
a bit when we tried to get our data out of sf.net.

It would have been different if we had used the open source version
*and* hosted that ourselves. You only have a 100% guarantee that
you get the data out of the tracker if the data live on your own
disks (and you have good backup of these disks).

Regards,
Martin
A.M. Kuchling
2006-10-09 15:20:13 UTC
Permalink
On 9 Oct 2006 06:36:30 -0700,
Paul Boddie <paul at boddie.org.uk> wrote:
> ... Meanwhile, despite the python.org codebase presumably running
> various commercial sites, ...

Nothing should have given you this impression! python.org's
formatting is handled through a custom script called Pyramid, and if
you poke around with enough determination you can find the SVN
repository's URL. But it's never been released as a tarball, and
isn't used by any other sites.

As an experiment I tried formatting the python.org site using
rest2web; that looks promising, if I ever figure out how sidebars
work, and may someday replace Pyramid.

--amk
Ilias Lazaridis
2006-10-05 02:36:17 UTC
Permalink
Robert Kern wrote:
> Giovanni Bajo wrote:
> > Hello,
> >
> > I just read this mail by Brett Cannon:
> > http://mail.python.org/pipermail/python-dev/2006-October/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?
>
> No.

?? how do you know the answer??

anyway.

-

I don't think that a non-open-source system will be selected by the
responsible people.

Most possibly, they are aware about the basic requirements of an
infrastructure - which is control:

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

.
Ilias Lazaridis
2006-10-04 23:25:24 UTC
Permalink
Giovanni Bajo wrote:
> Hello,
>
> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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.

-

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

.
Michael Ströder
2006-10-05 23:42:20 UTC
Permalink
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.
Steve Holden
2006-10-05 06:29:29 UTC
Permalink
Ilias Lazaridis wrote:
> Giovanni Bajo wrote:
>
>>Hello,
>>
>>I just read this mail by Brett Cannon:
>>http://mail.python.org/pipermail/python-dev/2006-October/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

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
Ilias Lazaridis
2006-10-05 19:06:59 UTC
Permalink
Steve Holden wrote:
> Ilias Lazaridis wrote:
> > Giovanni Bajo wrote:
> >
> >>Hello,
> >>
> >>I just read this mail by Brett Cannon:
> >>http://mail.python.org/pipermail/python-dev/2006-October/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)

.
Georg Brandl
2006-10-05 08:27:14 UTC
Permalink
Ilias Lazaridis wrote:
> Giovanni Bajo wrote:
>> Hello,
>>
>> I just read this mail by Brett Cannon:
>> http://mail.python.org/pipermail/python-dev/2006-October/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
Georg Brandl
2006-10-05 08:56:51 UTC
Permalink
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
skip
2006-10-04 19:43:01 UTC
Permalink
>> No, actually switching trackers can be one big pain in the ass. You
>> probably aren't aware of how hard it's been for the Python
>> development team (I think Martin v. Loewis, mostly) to get tracker
>> data out of SF.

Fredrik> http://effbot.org/zone/sandbox-sourceforge.htm

Thanks for the memory jog. Before you wrote your scraper/downloader I seem
to recall there were several only-semi-successful attempts to get SF to
themselves dump the tracker data for us. That was what I was referring to.

Skip
&quot;Martin v. Löwis&quot;
2006-10-04 20:27:52 UTC
Permalink
skip at pobox.com schrieb:
> No, actually switching trackers can be one big pain in the ass. You
> probably aren't aware of how hard it's been for the Python development team
> (I think Martin v. Loewis, mostly) to get tracker data out of SF. An
> explicit requirement was that any tool chosen as a SF replacement be able to
> easily export its database to avoid this sort of "lock-in" in the future.

While I put quite some effort into getting data out of SF, it was
Fredrik Lundh who eventually implemented the solution that we'll use:
screen scraping. My efforts to get data out of SF "officially"
were futile.

Regards,
Martin
unknown
2006-10-03 08:52:52 UTC
Permalink
"Giovanni Bajo" <noway at sorry.com> writes:
> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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?

Sounds crazy, what's wrong with bugzilla?
&quot;Martin v. Löwis&quot;
2006-10-08 20:53:38 UTC
Permalink
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
Giovanni Bajo
2006-10-05 09:37:04 UTC
Permalink
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
&quot;Martin v. Löwis&quot;
2006-10-06 11:59:09 UTC
Permalink
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
Giovanni Bajo
2006-10-07 16:28:44 UTC
Permalink
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
Fredrik Lundh
2006-10-05 17:38:10 UTC
Permalink
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>
Tim Peters
2006-10-07 17:42:03 UTC
Permalink
[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.
skip
2006-10-06 13:20:07 UTC
Permalink
Paul> How often should a tracker freeze anyway? People with no
Paul> technical knowledge at all run BBS systems that almost never
Paul> freeze. Is a tracker somehow more failure-prone? It's just a
Paul> special purpose BBS, I'd have thought.

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

As for this question from Giovanni:

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

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

Skip
&quot;Martin v. Löwis&quot;
2006-10-06 11:07:26 UTC
Permalink
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
2006-10-06 11:24:48 UTC
Permalink
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
Michael Ströder
2006-10-05 17:14:23 UTC
Permalink
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.
Giovanni Bajo
2006-10-06 08:36:08 UTC
Permalink
skip at pobox.com wrote:

> 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.
--
Giovanni Bajo
Terry Reedy
2006-10-06 21:54:54 UTC
Permalink
"Giovanni Bajo" <noway at sorry.com> wrote in message
news:YzoVg.137036$zy5.1843214 at twister1.libero.it...
> skip at 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.
Giovanni Bajo
2006-10-04 13:08:23 UTC
Permalink
A.M. Kuchling 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.
>
> Being open source wasn't a requirement;

which is, indeed, shocking and amazing.

> minimal requirements were
> specified in the initial message requesting trackers
> (http://wiki.python.org/moin/OriginalCallForTrackers).

Where does it mention that only trackers which have at least an existing
installation and a group of people for maintenance will be considered? It
could easily be assumed that PSF had already enough bandwidth, server,
manpower to handle any bugtracker installation.

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.
--
Giovanni Bajo
Steve Holden
2006-10-04 14:21:50 UTC
Permalink
Paul Boddie wrote:
> Giovanni Bajo wrote:
>
>>In fact, are you absolutely positive that you need so much effort to
>>maintain an existing bugtracker installation?
>
>
> I wonder what kinds of insights were sought from other open source
> projects. It's not as if there aren't any big open source projects
> having approachable community members willing to share their thoughts
> on running open source (or any other kind of) issue tracking software.
> KDE and GNOME don't use SourceForge and yet manage their own
> infrastructure - has anyone asked them how they do it?
>
> Paul
>
Right, we could have asked Linus for advice ...

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
skip
2006-10-04 15:51:43 UTC
Permalink
Giovanni> In fact, are you absolutely positive that you need so much
Giovanni> effort to maintain an existing bugtracker installation?

The development group's experience with SF and I think to a lesser extent,
Roundup in its early days, and more generally with other components of the
development toolchain (source code control) and python.org website
maintenance suggests that some human needs to be responsible for each key
piece of technology. Maybe when it's mature it needs very little manpower
to maintain, but a substantial investment is required when the technology is
first installed.

Skip
&quot;Martin v. Löwis&quot;
2006-10-04 19:47:33 UTC
Permalink
Giovanni Bajo schrieb:
> 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.

I know that I'm currently putting more time into maintaining the
Subversion installation than I'd like to, despite this being a really
small amount of work per month, and despite others also having been
introduced to the infrastructure necessary for administration.
When I go on vacation, people effectively have to wait until
I return before they can get their write access enabled. I
sometimes defer dealing with admin requests for a few days, and
people start complaining.

Regards,
Martin
Aahz
2006-10-05 02:24:36 UTC
Permalink
In article <eg0q7a$u0e$1 at nnrp.ngi.it>,
Giovanni Bajo <raNOsky at deveSPAMler.com> wrote:
>
>I wonder why the PSF infrastructure committee believes that a group of 6-10
>people is needed to "install and maintain" Roundup.

Because Roundup has been "the answer" for at least two or three years,
but somehow it never has gotten enough concerted attention to make it
happen. I'm sure that experience informed much of the Infrastructure
Committee's work.

I suspect in the end that if four or five people who are known to follow
through on their commitments volunteered that probably would be enough.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"LL YR VWL R BLNG T S" -- www.nancybuttons.com
Ben Finney
2006-10-04 23:02:56 UTC
Permalink
"Martin v. L?wis" <martin at v.loewis.de> writes:

> Giovanni Bajo schrieb:
> > It is an extremely bad picture for an open source flag like Python
> > to go to a vendor for such an easy requirement as a bug database.
>
> You fail to recognize that Python is *already* using a non-free software
> for bug tracking, as do thousands of other projects. So from that point
> of view, the status wouldn't change.

The whole point of moving *from* SF *to* another bug tracker is to
improve the situation, surely.

You already seem to acknowledge that using free-software tools to
develop Python is desirable. I don't see why you're being so obtuse in
this sub-thread on *why* it's desirable.

--
\ "The Stones, I love the Stones; I can't believe they're still |
`\ doing it after all these years. I watch them whenever I can: |
_o__) Fred, Barney, ..." -- Steven Wright |
Ben Finney
Ben Finney
2006-10-05 01:50:30 UTC
Permalink
"Terry Reedy" <tjreedy at udel.edu> writes:

> "Ben Finney" <bignose+hates-spam at benfinney.id.au> wrote:
> > I don't see why you're being so obtuse
> I think name calling is out of line here.

So do I, which is why I addressed observed actions instead.

--
\ "I got a postcard from my best friend, it was a satellite |
`\ picture of the entire Earth. On the back he wrote, 'Wish you |
_o__) were here'." -- Steven Wright |
Ben Finney
Tim Peters
2006-10-05 06:44:31 UTC
Permalink
[Ben Finney]
>> I don't see why you're being so obtuse

[Terry Reedy]
> I think name calling is out of line here.

Name calling is always out of line on comp.lang.python. Unless it's
done by Guido. Then it's OK. Anyone else, just remind them that even
Hitler had better manners. That always calms things down again.

loving-usenet-despite-that-it's-usenet-ly y'rs - tim
Paul Boddie
2006-10-03 11:55:49 UTC
Permalink
Paul Rubin wrote:
> "Giovanni Bajo" <noway at sorry.com> writes:
> >
> > Does this smell "Bitkeeper fiasco" to anyone else than me?

I probably said as much before, possibly to the distaste of some
individuals. Still, the BitKeeper story should serve as a reminder
about relinquishing control of infrastructure to some seemingly
benevolent third party with their own separate interests. It should
especially be a reminder to those who deem Torvalds-style "overt
pragmatism" to be virtuous in the face of supposedly ideological
realism.

Of course, there's presumably a huge gulf between the vendor in this
case and the vendor in the BitKeeper case, especially with respect to
draconian non-compete clauses and threats to sue one's own customers.
However, it's certainly not some kind of heresy to at least question
the wisdom of moving community resources and services around in such a
way. After all, this situation has been brought about because of a
dependence on a supposedly unreliable commercial third party.

> Sounds crazy, what's wrong with bugzilla?

Well, Bugzilla is a bit of a monster. ;-) Seriously, having installed
it, it seems like a relic of the early CGI period with a bunch of files
that you're supposed to throw in a CGI directory before performing
.htaccess surgery, which they admittedly do for you if you choose to
trust that particular method of deployment. Contrast that with various
other common Web applications which only put actual CGI programs within
the CGI directory, making the whole deployment much cleaner and easier
to troubleshoot/maintain, and you can see that there's a serious need
for some repackaging work.

Sure, there are scripts to help check dependencies, which meant a trip
to CPAN (not as joyous as its advocates would have you believe), and
there is a nice configuration system in Bugzilla's own Web interface
which helps you finish the job off (providing you don't forget
something in the 16 pages of settings), but there's always this nasty
suspicion that something somewhere probably isn't configured properly.
Finally, on the subject of the inner workings of Bugzilla, one is
presented with the amusement of diving into Perl to fix stuff:
something that not everyone is enthusiastic about.

As for Bugzilla's interface, it is telling that some open source
projects actually put a layer on top of Bugzilla in order to avoid the
complexity of the search interface, although it must be said that
recent versions don't seem to immediately throw up the page with 40 or
so controls on it, just to search for a bug. That said, the fact that
many open source projects continue to use Bugzilla would suggest that
they're either not interested in or aware of alternatives (quite
possible), or they're reasonably happy with it (also quite possible).

Paul
Ben Finney
2006-10-03 11:55:51 UTC
Permalink
Steve Holden <steve at holdenweb.com> writes:

> Paul Rubin wrote:
> > "Giovanni Bajo" <noway at sorry.com> writes:
> >>I just read this mail by Brett Cannon:
> >>http://mail.python.org/pipermail/python-dev/2006-October/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?
> >
> > Sounds crazy, what's wrong with bugzilla?
>
> Much the same as is wrong with the existing SourceForge system, I'd say.

The existing SourceForge system runs on non-free software, which is a
significant differentiator from Bugzilla.

I would be greatly dismayed to see the PSF choosing to move critical
Python development data into a non-free system. I hope this
recommendation from the "PSF infrastructure committee" is rejected.

--
\ "There is no reason anyone would want a computer in their |
`\ home." -- Ken Olson, president, chairman and founder of |
_o__) Digital Equipment Corp., 1977 |
Ben Finney
Steve Holden
2006-10-03 10:59:14 UTC
Permalink
Paul Rubin wrote:
> "Giovanni Bajo" <noway at sorry.com> writes:
>
>>I just read this mail by Brett Cannon:
>>http://mail.python.org/pipermail/python-dev/2006-October/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?
>
>
> Sounds crazy, what's wrong with bugzilla?

Much the same as is wrong with the existing SourceForge system, I'd say.

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
A.M. Kuchling
2006-10-04 12:55:59 UTC
Permalink
On Wed, 04 Oct 2006 07:37:47 GMT,
Giovanni Bajo <noway at sorry.com> 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.

Being open source wasn't a requirement; minimal requirements were
specified in the initial message requesting trackers
(http://wiki.python.org/moin/OriginalCallForTrackers).

--amk
&quot;Martin v. Löwis&quot;
2006-10-04 19:40:09 UTC
Permalink
Giovanni Bajo schrieb:
>>> I hope this
>>> recommendation from the "PSF infrastructure committee" is rejected.
>> That is very very unlikely. Who would reject it, and why?
>
> The community, and I am impressed you do not want to understand the "why".

How would "the community" actually reject it? By not using it? Well,
that won't happen: They use the current SF tracker, despite it being
non-free software.

> It is an extremely bad picture for an open source flag like Python to go to a
> vendor for such an easy requirement as a bug database.

You fail to recognize that Python is *already* using a non-free software
for bug tracking, as do thousands of other projects. So from that point
of view, the status wouldn't change.

Regards,
Martin
Paul Boddie
2006-10-09 13:36:30 UTC
Permalink
Magnus Lycka wrote:
>
> It seems to me that an obvious advantage with either Roundup
> or Trac, is that if the Python project used it, the Python
> project would have a significant impact on how this product
> developed. Even if the Jira people seem eager to please us,
> I'm pretty convinced that it will be easier to get Roundup
> or Trac improved to fit our particular needs.

Yes, because Roundup and Trac are open source projects: there is no
barrier to prevent the users taking the code in a direction appropriate
to their own needs. And just to make it clear that I'm not picking on
Jira, it should be noted that even with their apparent willingness to
make a useful "community" product (and their otherwise remarkable open
source credentials), the Launchpad developers can't offer the kinds of
assurances implicitly provided by Roundup, Trac or any of their open
source brethren.

> That's valuable in two ways:
> 1) The Python project would get a bug tracker which is
> developed with the needs of the Python project as a
> prime concern. (Being the major "customer" of a product
> has benefits. Jira on the other hand, might get more
> and more integrated with other Java stuff that we don't
> really care about.

As has been said already, there's supposedly no guarantee that people
will want to develop Roundup at a hectic tempo in order to satisfy the
needs/desires of the Python developers. But then again, other pieces of
infrastructure have a high community investment, notably Mailman (which
uses Jira as its issue tracker, as it turns out).

> 2) We'd help making a good Python product even better, and
> probably more widely used, thus spreading the use of
> Python even further.

It seems to me that with all the fuss about marketing Python [1],
instead of ranting about how other products and technologies are
stealing all the thunder, one might instead want to start closer to
home. In this respect, several opportunities are being missed or
squandered either because people think marketing is all about press
releases, or they want Python to retain its stealth label (the
"competitive advantage" people mention constantly).

Take python.org as the place to start. One can claim all one likes
about how Web applications aren't special enough to warrant special
mentions or coverage in the context of persuading people about Python's
advantages, but many people presumably visit python.org and wonder...

* How they can develop Web applications using Python in a way they
recognise either from intuition or previous experience. Where can
they find a good solution and get started quickly?

* Whether python.org, as some kind of content platform, is some kind
of convenient answer to their own Internet/intranet site project.
Can they download the code and run the same kind of thing
themselves?

The answers aren't too clear to these questions. I've revisited some of
the material available via python.org [2] in order to attempt to
provide clearer answers to the first question, but the topic of
standardisation is currently stagnant (so it's every framework for
itself), and the community is split between hyping the most popular
frameworks whilst emphasizing the modest achievements that led to WSGI
(which doesn't really answer the first question entirely). Meanwhile,
despite the python.org codebase presumably running various commercial
sites, it would surprise me if there would ever be a convenient
downloadable package of that codebase available prominently from
python.org itself (even though the components are all openly
available). So the Python project - the power behind content management
solutions like Zope, Plone and (at a different angle) MoinMoin - offers
an incoherent response to the second question.

Then, there are the other recommendations under the "Using Python
For..." heading - advocacy points to show how Python can be really
useful - which mentions under "Software Development" the following:
Buildbot, Trac, Roundup and IDEs. If one ignores the current issue
tracker debate for a moment and follows the "Software Development"
link, one reaches a general Python applications page which mentions
amongst other "choices for web development" the CPS project, and
following the provided link swiftly delivers another advocacy own-goal:
"We're switching to JAVA!" state the CPS people proudly, still
blissfully unaware that "Java" isn't an acronym; "Read why" they
suggest.

It's tempting to label what I've written above as just some
opportunistic criticism of the maintenance level of the python.org
content, that the core developers should just choose their tools and
get on with things, and that this thread has attempted to politicize
the decision under discussion from the start. Indeed, as someone who
merely browses python-dev, perhaps I shouldn't care how the core
developers track their bugs: if they struggle to manage that
information in future, why should I care? Well, the reason I should
care is related to the reason why the core developers should care about
more than purely technical issues: the wider community and the core
developers do not exist by themselves in isolation; the well-being of
the community is related to how Python is managed and portrayed by the
custodians of the language, and the well-being of the development
effort is related to how much community effort can be directed towards
improving the language and its image. If this were not so, Python would
have vanished like many of its contemporaries.

Perhaps the decision makers evaluated the above and much more in depth,
although us outsiders are not in a position to say, but perhaps the
discussion around the decision wouldn't have been so inflammatory in
places if there had been an acknowledgement of this "bigger picture" of
the community, its influences and that in a large open source project
no moderately significant decision is without a political dimension.

Paul

[1] http://www.artima.com/forums/flat.jsp?forum=106&thread=150515
[2] http://wiki.python.org/moin/WebFrameworks
Ben Finney
2006-10-08 04:08:56 UTC
Permalink
"Ilias Lazaridis" <ilias at lazaridis.com> writes:

> 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
Paul Boddie
2006-10-06 10:02:02 UTC
Permalink
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
skip
2006-10-05 14:10:17 UTC
Permalink
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
Istvan Albert
2006-10-03 20:42:46 UTC
Permalink
Giovanni Bajo wrote:

> Does this smell "Bitkeeper fiasco" to anyone else than me?

well, no company will spend money/effort/resources unless it benefits
them some way. Once that benefit (or the perception of it) disappears
the company will cut the lifeline. It's just common business sense.

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.

So what if in three years (again worst case scenario) they need to
change trackers? It is not such a big deal and the benefits over these
two years might have balanced out the troubles of switching.

I.
proteusguy
2006-10-07 05:12:27 UTC
Permalink
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>
Valentino Volonghi aka Dialtone
2006-10-04 13:40:34 UTC
Permalink
Terry Reedy <tjreedy at udel.edu> wrote:

> As I understood B.C.'s announcement, that was one of the judging criteria,
> and the plan is for PSF to get a daily backup dump of the data.

This had nothing to do with the choice of not using Trac or Launchpad.

Quoting Brett Cannon from the original mail:
""
As for Trac and Launchpad, both had fundamental issues that led to them
not being chosen in the end. Most of the considerations had to do with
customization or UI problems.
""

So clearly the 'get a daily backup of the data' is not the reason.
Backing up a sqlite database is pretty easy.

--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
New Pet: http://www.stiq.it
Steve Holden
2006-10-04 14:23:25 UTC
Permalink
Valentino Volonghi aka Dialtone wrote:
> Terry Reedy <tjreedy at udel.edu> wrote:
>
>
>>As I understood B.C.'s announcement, that was one of the judging criteria,
>>and the plan is for PSF to get a daily backup dump of the data.
>
>
> This had nothing to do with the choice of not using Trac or Launchpad.
>
> Quoting Brett Cannon from the original mail:
> ""
> As for Trac and Launchpad, both had fundamental issues that led to them
> not being chosen in the end. Most of the considerations had to do with
> customization or UI problems.
> ""
>
> So clearly the 'get a daily backup of the data' is not the reason.
> Backing up a sqlite database is pretty easy.
>
Do you have any idea fo the scale of the Python issue (bug) database? Do
you really think SQLite would be a suitable platform for it?

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
Steve Holden
2006-10-04 02:12:05 UTC
Permalink
Paul Rubin wrote:
> "Istvan Albert" <istvan.albert at gmail.com> writes:
>
>>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.
>
>
> Well, what's so cool about it? Most large free software projects seem
> to use Bugzilla. I'd never looked at the Bugzilla code but from
> descriptions here it now sounds like the situation with CVS as of a
> few years ago. Maybe it's time for a rewrite/replacement, a la
> darcs/SVN/whatever.

Please feel free to go right ahead. Should be ready n a month or twelve ...

Like others I have my doubts about using commercial products to support
open source development but the guys who did the evaluation have chosen,
and I'm not about to second guess them.

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
Terry Reedy
2006-10-04 03:54:28 UTC
Permalink
"Ben Finney" <bignose+hates-spam at benfinney.id.au> wrote in message
news:87ac4ciynk.fsf at benfinney.id.au...
> If we *know* that we can always get all the data out of the product,

As I understood B.C.'s announcement, that was one of the judging criteria,
and the plan is for PSF to get a daily backup dump of the data.

tjr
Giovanni Bajo
2006-10-04 17:27:36 UTC
Permalink
Steve Holden wrote:

> No, I'm not on the infrastructure list, but I know that capable people
> *are*: and you know I am quite capable of donating my time to the
> cause, when I have it to spare (and sometimes even when I don't).
>
> 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.
>
> Kindly note that none of the above remarks apply to you.

The current request is: "please, readers of python-dev, setup a team of 6-10
people to handle roundup or we'll go to a non-free software for bug
tracking". This is something which I cannot cope with, and I'm *speaking*
up against. Were the request lowered to something more reasonable, I'd be
willing to *act*. I have to speak before acting, so that my acting can
produce a result.

And besides the only thing I'm really sniping the PSF against is about
*ever* having thought of non-FLOSS software. This is something I *really* do
not accept. You have not seen a mail from me with random moaning as "Trac is
better", "Bugzilla is better", "why this was chosen". I do respect the fact
that the PSF committee did a thorough and correct evaluation: I just
disagree with their initial requirements (and I have not raised this point
before because, believe me if you can, I really thought it was obvious and
implicit).

So, if your remarks apply to me, I think you are misrepresenting my mails
and my goals.
--
Giovanni Bajo
Giovanni Bajo
2006-10-04 21:18:25 UTC
Permalink
David Goodger wrote:

> Go back to the original announcement:
>
> """
> After evaluating the trackers on several points (issue creation,
> querying, etc.), we reached a tie between JIRA and Roundup in terms of
> pure tracker features.
> """
>
> JIRA gets a leg up because of the hosting and administration also
> being offered. But...
>
> """
> If enough people step forward we will notify python-dev that Roundup
> should be considered the recommendation of the committee and
> graciously
> turn down Atlassian's offer.
> """
>
> That is a perfectly reasonable offer. Put up or shut up.

You're cherry picking your quotes:

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

This is *NOT* a perfectly reasonable offer, because you do not see 6-10 people
stepping up at the same time for almost *anything* in the open source world.
--
Giovanni Bajo
David Goodger
2006-10-04 19:12:37 UTC
Permalink
Giovanni Bajo wrote:
> The current request is: "please, readers of python-dev, setup a team of 6-10
> people to handle roundup or we'll go to a non-free software for bug
> tracking". This is something which I cannot cope with, and I'm *speaking*
> up against. Were the request lowered to something more reasonable, I'd be
> willing to *act*.

No, the announcement stated the situation in a very different way.

Asking for a group of maintainers to commit to an essential piece of
infrastructure is perfectly reasonable. Brett didn't ask for 6-10 full
time developer/sysadmins. He asked for typical commitment, which is up
to a few hours per week. The initial work will probably be significant,
but will undoubtedly taper off over time.

Go back to the original announcement:

"""
After evaluating the trackers on several points (issue creation,
querying, etc.), we reached a tie between JIRA and Roundup in terms of
pure tracker features.
"""

JIRA gets a leg up because of the hosting and administration also being
offered. But...

"""
If enough people step forward we will notify python-dev that Roundup
should be considered the recommendation of the committee and graciously
turn down Atlassian's offer.
"""

That is a perfectly reasonable offer. Put up or shut up.

> And besides the only thing I'm really sniping the PSF against is about
> *ever* having thought of non-FLOSS software. This is something I *really* do
> not accept. ... I just
> disagree with their initial requirements (and I have not raised this point
> before because, believe me if you can, I really thought it was obvious and
> implicit).

That just shows that you were being na?ve. The initial requirements
were published openly and clearly.

> I do respect the fact
> that the PSF committee did a thorough and correct evaluation:

Yes, they did, and you should be thanking them instead of complaining.

If you feel so strongly, please volunteer.

-- David Goodger
skip
2006-10-04 15:57:56 UTC
Permalink
Istvan> I think you are missing the point. Switching to a different
Istvan> tracker is not such a big deal. Having a really good tracker is
Istvan> a big deal.

No, actually switching trackers can be one big pain in the ass. You
probably aren't aware of how hard it's been for the Python development team
(I think Martin v. Loewis, mostly) to get tracker data out of SF. An
explicit requirement was that any tool chosen as a SF replacement be able to
easily export its database to avoid this sort of "lock-in" in the future.

Skip
Oliver Andrich
2006-10-03 12:09:35 UTC
Permalink
Hi,

On 10/3/06, Giovanni Bajo <noway at sorry.com> wrote:
> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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?

No, this doesn't smell like the BK fiasco, it is just the decision to
use a certain tool. But it is easy to change or influence this
recommondation. Step up as an admin for Roundup. :)

Best regards,
Oliver
--
Oliver Andrich <oliver.andrich at gmail.com> --- http://roughbook.de/
Giovanni Bajo
2006-10-08 00:20:14 UTC
Permalink
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
Ilias Lazaridis
2006-10-08 03:49:38 UTC
Permalink
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.lang.python/msg/0334d6ff60a48991

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

It is in his nature to babble in this way.

Sometimes it's even funny!

.
Paul Boddie
2006-10-04 12:11:23 UTC
Permalink
Richard Jones wrote:
> Nick Craig-Wood wrote:
> >
> > Trac is really good in my experience.
>
> Trac was considered.
>
> > A nice extra is that it is written in python.
>
> So are Roundup and Launchpad, two of the other three trackers considered.

It should be noted that most skepticism (that I'm aware of) about
Launchpad is typically rooted in that service's closed source nature.
People voicing such skepticism don't seem to cut it any slack just
because it is apparently written in Python.

Paul
Steve Holden
2006-10-04 13:29:32 UTC
Permalink
Fredrik Lundh wrote:
> Steve Holden wrote:
>
>
>>But sadly people are much happier complaining on c.l.py than exerting
>>themselves to support the community with an open source issue tracker.
>
>
> you're not on the infrastructure list, I hear. python.org could still need a
> few more roundup volunteers, but it's not like nobody's prepared to con-
> tribute manhours. don't underestimate the community.
>
No, I'm not on the infrastructure list, but I know that capable people
*are*: and you know I am quite capable of donating my time to the cause,
when I have it to spare (and sometimes even when I don't).

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.

Kindly note that none of the above remarks apply to you.

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
Steve Holden
2006-10-05 06:22:07 UTC
Permalink
Fredrik Lundh wrote:
> Steve Holden wrote:
>
>
>>>you're not on the infrastructure list, I hear. python.org could still need a
>>>few more roundup volunteers, but it's not like nobody's prepared to con-
>>>tribute manhours. don't underestimate the community.
>>>
>>
>>No, I'm not on the infrastructure list, but I know that capable people
>>*are*: and you know I am quite capable of donating my time to the cause,
>>when I have it to spare (and sometimes even when I don't).
>
>
> what I was trying to say (between the lines) was that not only have
> the people on that list worked hard to do the evaluation (not to mention
> all the developers around the world that has worked even harder to set
> up test trackers), there's also been a good community response to the
> committee's call for "6-10 volunteers".
>
Excellent. I've just complained elsewhere in this thread that those
dissenting didn't appear to want to rectify the situation by offering
their time. It would be nice to be wrong about that.

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
Paul Boddie
2006-10-03 12:33:14 UTC
Permalink
lbolognini at gmail.com wrote:
> Giovanni Bajo wrote:
>
> > Does this smell "Bitkeeper fiasco" to anyone else than me?
>
> I can't understand why people waste time arguing this stuff.

Because people care about it, I guess.

> Use whatever tool is best at it's job... if it's not written in Python
> it doesn't mean that Python is not good for the task, only that there
> hasn't been any Python programmer that applied himself to the problem
> hard enough.
>
> And i dunno what the case against Trac is (it looks a fine tool for my
> small projects) but probably it's not good enough for python.org

Perhaps, although I imagine that Trac would have a lot more uptake if
it handled more than just Subversion repositories. I don't know whether
Trac is monolithic or not, but there is a need for a wider range of
modular tools operating in the following areas:

* Web-based source code browsing and searching for many repository
types; perhaps one per type, all providing a similar interface.
Currently, there's ViewVC which does CVS and Subversion browsing
(and limited searching), LXR which does CVS, Subversion and Git
searching (with arguably more limited browsing), OpenGrok which
seems to provide CVS, Subversion, RCS and SCCS browsing and
searching. Perhaps ViewVC just needs more attention.

* Issue tracking: a huge area in which Trac, Bugzilla, Roundup and a
bunch of proprietary tools exist.

* Documentation or content management: whilst arguably non-essential
to the management of a software project, I can see the benefit of
integrating documentation with the source code browser, especially.
And it's convenient if providing a service to users as well as
developers if things like downloadable files can be managed in a
way that is compatible with the rest of the solution.

* Mailing list management/administration, feeds, summaries, reports.

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.

> And BTW BitKeeper failed because Linus wanted to stop Tridge reverse
> engineering BitKeeper, not because BK wasn't good.

That's a simplistic view of the situation. The BitKeeper vendor imposes
a non-compete clause on its users, which is in itself pretty
scandalous, and the various attempts to accomplish independent
interoperability with the BitKeeper service led to its proprietor
packing up his toys and going home. You might believe that having some
opportunistic company narrowly define what you can and cannot do,
despite a fairly loose relationship based on you just using their stuff
in your workplace, to be acceptable as long as you get to use such nice
stuff. Others, however, consider implications wider than whether
something is technically good, including whether or not something
brings with it all sorts of unacceptable restrictions on personal
freedoms. Considered through such broader criteria, one can assert that
BitKeeper certainly wasn't good at all.

Paul
Ian Bicking
2006-10-05 22:55:35 UTC
Permalink
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
Magnus Lycka
2006-10-09 11:45:28 UTC
Permalink
Fredrik Lundh wrote:
> you're not on the infrastructure list, I hear.

I tried to figure out where that list is, so I could have
a look at the archives, but I didn't find it in the (for
me) obvious places. Could someone please provide a link
to the archives for this mailing list, or aren't there
any public archives of them? Only for PSF members?

> python.org could still need a few more roundup volunteers,
> but it's not like nobody's prepared to contribute manhours.
> don't underestimate the community.

So, how many have offered to help? Is this information
available in some public repository?

I don't know how much work it actually takes to maintain
a roundup installation for the Python project, but I know
that in general, not all people manage to follow through
on everything they commit to do, even if they have good
intentions, so I'd be a bit worried to move to roundup if
only two or three people had offered to run it, even if
that might nominally be enough. Of course, this depends
on who those people would be... Ten seems like a bit too
many though. I somehow suspect that less work would get
done in a group of ten than in a group of six people...

It seems to me that an obvious advantage with either Roundup
or Trac, is that if the Python project used it, the Python
project would have a significant impact on how this product
developed. Even if the Jira people seem eager to please us,
I'm pretty convinced that it will be easier to get Roundup
or Trac improved to fit our particular needs.

That's valuable in two ways:
1) The Python project would get a bug tracker which is
developed with the needs of the Python project as a
prime concern. (Being the major "customer" of a product
has benefits. Jira on the other hand, might get more
and more integrated with other Java stuff that we don't
really care about.
2) We'd help making a good Python product even better, and
probably more widely used, thus spreading the use of
Python even further.
Georg Brandl
2006-10-09 12:32:01 UTC
Permalink
Magnus Lycka wrote:
> Fredrik Lundh wrote:
>> you're not on the infrastructure list, I hear.
>
> I tried to figure out where that list is, so I could have
> a look at the archives, but I didn't find it in the (for
> me) obvious places. Could someone please provide a link
> to the archives for this mailing list, or aren't there
> any public archives of them? Only for PSF members?

The archives are viewable for list members. The list info is at
http://mail.python.org/mailman/listinfo/infrastructure

>> python.org could still need a few more roundup volunteers,
> > but it's not like nobody's prepared to contribute manhours.
> > don't underestimate the community.
>
> So, how many have offered to help? Is this information
> available in some public repository?

Not yet, as it seems.

Georg
Istvan Albert
2006-10-04 15:31:47 UTC
Permalink
Giovanni Bajo wrote:

> I understand your point. OTOH, exactly because the tracker system is a far
> lesser importance, it's amazing there is *ever* a need to evaluate non-FLOSS
> solutions, when there are so many good free solutions around. Instead of

I think you are missing the point. Switching to a different tracker is
not such a big deal. Having a really good tracker is a big deal.

Trackers are all about usability.

Alas most open source projects suck at that while excel in
implementation and performance.

FWIW I'd rather have the PSF even pay for good quality tracker since
that benefits everyone rather than funding some obscure project that
only 1% of the programmers will use/heard of.

Istvan
Giovanni Bajo
2006-10-03 08:19:10 UTC
Permalink
Hello,

I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/python-dev/2006-October/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
Robert Hicks
2006-10-05 01:39:59 UTC
Permalink
Giovanni Bajo wrote:
> Hello,
>
> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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

No.

Robert
Robert Hicks
2006-10-07 13:38:31 UTC
Permalink
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
Giovanni Bajo
2006-10-04 07:47:54 UTC
Permalink
Martin v. L?wis wrote:

> It's significantly different from the Bitkeeper fiasco in two
> important
> ways:
> 1. Bitkeeper is a source revisioning system, so it is similar to CVS
> and Subversion. This project here is "just" the bug tracker, which
> is of lesser importance. If we move to a different one some day, a
> certain amount of data lossage might be acceptable (e.g. we now
> likely lose the "history" of status changes and file attachments on
> each report). An export of all data is high on the requirements
> list, as Fredrik points out.

I understand your point. OTOH, exactly because the tracker system is a far
lesser importance, it's amazing there is *ever* a need to evaluate non-FLOSS
solutions, when there are so many good free solutions around. Instead of
recommending a closed source solution, you could have recommended Roundup *and*
explained there is a need for funding and/or volunteers before the migration
can happen.

You might also be understimating how negative could be the reaction from the
open-source community to such a move.
--
Giovanni Bajo
Aahz
2006-10-07 19:26:22 UTC
Permalink
In article <0BQVg.138807$zy5.1859480 at twister1.libero.it>,
Giovanni Bajo <noway at sorry.com> 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?
--
Aahz (aahz at 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
Fredrik Lundh
2006-10-03 08:46:54 UTC
Permalink
Giovanni Bajo wrote:

> I just read this mail by Brett Cannon:
> http://mail.python.org/pipermail/python-dev/2006-October/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?

not necessarily (and good support for data export is high on the
requirements list), but for those of us who's been following the
committee's work, there has indeed been a disturbing amount of
"free as in - oh shiny!" from the very beginning.

however, note that the committee do realize that using a Python-
powered tool for Python is a good thing in itself; they are asking
for volunteers that can keep a roundup instance running, and fix
any issues that arises. python.org has plenty of hardware, but not
enough manpower to do everything that could be done. see brett's
post for details.

</F>
A.M. Kuchling
2006-10-03 12:33:45 UTC
Permalink
On Tue, 03 Oct 2006 08:19:10 GMT,
Giovanni Bajo <noway at sorry.com> wrote:
> ... using a non open source tracker (called JIRA - never heard
> before of course) for Python itself.

Other projects do use it; see
<http://wiki.apache.org/general/ApacheJira> for a partial list, and a
link to the Apache Software Foundation's issue trackers.

> Does this smell "Bitkeeper fiasco" to anyone else than me?

The committee did expect this recommendation to be controversial. :)

--amk
Continue reading on narkive:
Loading...