Hello,
I just read this mail by Brett Cannon: http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
Giovanni Bajo
Oct 3 '06
158  6267 
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.
(I don't think any of the proposed solutions would have a *capacity* problem.
afaict, the main argument was that trac and launchpad simply isn't quite as con-
figurable as the others. which doesn't have to be a bad thing, really -- effient
bug handling is more about process than technology. the best issue tracking
system I've ever used wasn't even designed for issue tracking...)
</F>
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
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
GiovanniIn fact, are you absolutely positive that you need so much
Giovannieffort 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
IstvanI think you are missing the point. Switching to a different
Istvantracker is not such a big deal. Having a really good tracker is
Istvana 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
sk**@pobox.com wrote:
GiovanniIn fact, are you absolutely positive that you need so
much Giovannieffort 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.
One thing is asking for a special help during the transition phase and the
"landing" phase (the first few months). Another thing is asking for "roughly
6-10 people" to install and maintain a Roundup installation. This is simply
not going to realistically happen, and I find it incredible for the PSF
committee to ask for such a high request. Damn, we don't have "roughly 6-10
people" in charge of reviewing patches or fixing bugs.
I followed the GNATS -Bugzilla transition myself closely, and a single
person (Daniel Berlin) was able to setup the Bugzilla server on the
gcc.gnu.org computer, convince everybody that a transition was needed (and
believe me, this was a hard work), patch it as much as needed to face the
needs of the incredibly picky GCC developers (asking for every little
almost-unused-and-obsoleted feature in GNATS to be replicated in Bugzilla),
and later maintain the installation. It took him approximately one year to
do this, and surely it wasn't full time. After that, he maintains and
administer the Bugzilla installation on his own, by providing upgrades when
needed and a few modifications.
I wonder why the PSF infrastructure committee believes that a group of 6-10
people is needed to "install and maintain" Roundup. Let us also consider
that Roundup's lead developer *was* part of the PSF infrastrucutre
committee, and he might be willing to help in the transition (just my very
wild guess), and he obviously knows his stuff. Also, given the requirement
for the selection, there is already a running roundup installation somewhere
(so the whole pipeline export -import has already been estabilished and
confirmed to work).
My own opinion is that a couple of person can manage the
transition/migration phase to *any* other bug tracking system, and provide
support in the python-dev mailing list. After the whole thing has fully
landed, I'd be really surprised if a single appointed maintainer would not
be enough.
If the PSF committee lowers its requests to a more realistical amount of
effort, I'm sure we will see many more people willing to help. I think many
people (including myself) would be willing to half-half-help with loose
ends, but when faced with an abnormous "6-10 people" request they just shut
up and sit in a corner.
--
Giovanni Bajo
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 wrote:
Hello,
I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
Giovanni Bajo
No just ignorance you your part!
Jira is given away for free to open source projects that want to use
it. And it just happens to be one of the best issue trackers on the
market, free or paid or opens source or not.
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 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".
Actually, it would appear that the request goes out to
comp.lang.python/python-list as well (ie. the ungrateful plebs like
myself who supposedly have nothing to contribute to the direction of
the Python project).
[...]
And besides the only thing I'm really sniping the PSF against is about
*ever* having thought of non-FLOSS software.
It has already been brought up that Python plays well with everyone and
everything, and thus a closed source tool projects the attitudes of the
core developers. However, in contrast to the use of tools such as
Roundup which have some advocacy value, the adoption of commercial
products often works largely in favour of the vendor: they're seen to
be helpful and charitable (which they may well be), and there's a
certain level of publicity value generated from the transaction (albeit
not as much as if the Bugzilla project switched over to a closed source
issue tracker).
Of course, this message so far probably passes for "being political" in
the eyes of certain people, but I think it's interesting to put such
decisions in the context of the calls to advocacy that people come out
with every now and again. Indeed, I believe that the PSF now have an
advocacy coordinator to lead the onslaught selling Python into
"business" or whatever people regard Python advocacy to be these days.
However, as an open source project it doesn't necessarily send a good
message to "business" that the amazing processes that drive Python
development are powered by closed source software (although they also
have been through the use of SourceForge) and that the developers
passed over a project that they were quite happy to use promotionally
once upon a time.
Indeed, while it was still running, the Software Carpentry competition
(the initiative which led to the development of Roundup) was potent
publicity material showing that Python and open source development
produce great software. The risk is that "business" looks at the level
of self-belief ("don't mention the competition by name" [1], but where
the competition isn't just other languages: it's also other development
methodologies) and wonders whether they wouldn't be better off with
some closed source development environment for their closed source
commercial product instead.
I guess what plebs like myself are supposed to take away from this is
the following: if the core developers are subsequently much more
productive developing the language (which is not exactly the thing
which requires most attention in the Python distribution these days, in
my opinion), then who are we to complain as long as we can still stuff
our bugs into some Web-based interface or other?
Paul
[1] http://holdenweb.blogspot.com/2006/0...se-python.html
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
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
>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
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
Giovanni Bajo schrieb:
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.
Regards,
Martin
Harry George schrieb:
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.
IMO, the biggest concern was that it didn't really "scale". I.e. if you
have a thousand open and several thousand closed reports in the
database, you need excellent support for queries, sorting, and alike.
Trac doesn't quite have the same power that the other tools do.
For example, to save a query/report, you actually have to write it in
SQL. For a complex report (with multiple groups), you cannot change
the order of items returned on the page (for a simple search, clicking
on the headings changes the order).
To see what I mean, please try to find out how many open reports
for the module "report system" are currently entered in the tracker
at http://trac.edgewall.org/report
How many of these are for 0.9.x?
There is also searching, which doesn't give a tabular view of all
tickets, but instead gives a Web search result page (similar
to what a search engine produces). This makes it difficult to scan
systematically for, say, all titles.
Regards,
Martin
"Martin v. Löwis" <ma****@v.loewis.dewrites:
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. sk**@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
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
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
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
Paul Rubin schrieb:
"Martin v. Löwis" <ma****@v.loewis.dewrites:
>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
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
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
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".
</F>
"Martin v. Löwis" <ma****@v.loewis.dewrites:
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.
Giovanni Bajo wrote:
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.
There was no problem. The committee had their mandate, to find the best
candidate for a tracker for Python. The quality of the tracker was felt
to be more important than the language it was written in or the license
it uses. The committee members worked hard to fulfill their mandate,
and they deserve the gratitude and appreciation of all of us.
I know for a fact (having raised this very issue with the committee
myself) that they took "written in Python" into consideration. Not as a
requirement though -- the requirement was simply to decide on the best
tracker, regardless of language or license.
Look at the results again. Jira and RoundUp tied for functionality, but
Jira has a hosting/admin offer behind it. That's huge. But rather than
declaring Jira the outright winner, which they could have done, the
committee has allowed the community to decide the matter. If enough
admins come forward, RoundUp will win.
I read that as a big push for "written in Python".
David Goodger
Giovanni Bajo wrote:
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,
Yes it is:
Jira = 1st place functionality + hosting/admin provided
RoundUp = 1st place functionality
Jira wins. But the offer is to allow the community to make up the
difference. If anything, that's unfair to Jira. So why are you
complaining?
because you do not see 6-10 people
stepping up at the same time for almost *anything* in the open source world.
Then that's a failure of the open source world.
But I *do* see it happening right now. People *are* stepping up.
David Goodger
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 schrieb:
>* 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?
Exactly so. Atlassian would generate a daily dump, and we would copy it
to a machine on python.org with a cron job.
Regards,
Martin
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
"fuzzylollipop" <ja*************@gmail.comwrites:
Giovanni Bajo wrote:
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?
Jira is given away for free to open source projects that want to use
it.
Just as Bitkeeper was.
"Given away for free" has nothing to do with the criteria being
discussed here.
--
\ "My, your, his, hers, ours, theirs, its. I'm, you're, he's, |
`\ she's, we're, they're, it's." -- Anonymous, |
_o__) alt.sysadmin.recovery |
Ben Finney
"Martin v. Löwis" <ma****@v.loewis.dewrites:
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
"David Goodger" <dg******@gmail.comwrites:
Look at the results again. Jira and RoundUp tied for functionality,
but Jira has a hosting/admin offer behind it. That's huge. But
rather than declaring Jira the outright winner, which they could
have done, the committee has allowed the community to decide the
matter. If enough admins come forward, RoundUp will win.
I read that as a big push for "written in Python".
I prefer to read it as a big push for "not dependent on non-free
tools".
--
\ "To me, boxing is like a ballet, except there's no music, no |
`\ choreography, and the dancers hit each other." -- Jack Handey |
_o__) |
Ben Finney
Giovanni Bajo wrote:
Hello,
I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
Giovanni Bajo
Fascinating.
The python foundation suggests a non-python non-open-source bugtracking
tool for python.
It's like saying: "The python community is not able to produce the
tools needed to drive development of python forward."
Anyway. The whole selection process is intransparent.
The commitee should have stated "goals" and "requirements" with a
public verification of the tools against them.
- http://case.lazaridis.com/wiki/Tracking
..
"Ben Finney" <bi****************@benfinney.id.auwrote in message
news:87************@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.
Terry Jan Reedy
Giovanni Bajo wrote:
Hello,
I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
Giovanni Bajo
No.
Robert
"Terry Reedy" <tj*****@udel.eduwrites:
"Ben Finney" <bi****************@benfinney.id.auwrote:
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
In article <eg**********@nnrp.ngi.it>,
Giovanni Bajo <ra*****@deveSPAMler.comwrote:
>
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 (aa**@pythoncraft.com) <* http://www.pythoncraft.com/
"LL YR VWL R BLNG T S" -- www.nancybuttons.com
Robert Kern wrote:
Giovanni Bajo wrote:
Hello,
I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
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
..
Ben Finney schrieb:
>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.
I don't deny it's desirable; I deny it's a indispensable requirement.
I truly believe that Jira would be a useful bug tracker and improve
the situation, despite it being non-free software. This really is no
source of worry for me. I'm feeling more uneasy about the fact that
it is written in Java (but still, this wouldn't stop me from
recommending it as it is a useful and well-engineered piece of
software).
In this sub-thread, I complain about this FUD "Python is moving
to a non-free bug tracker" (suggesting that it is moving away
from a free bug tracker).
Regards,
Martin
Ben Finney wrote:
"David Goodger" <dg******@gmail.comwrites:
>>Look at the results again. Jira and RoundUp tied for functionality,
but Jira has a hosting/admin offer behind it. That's huge. But
rather than declaring Jira the outright winner, which they could
have done, the committee has allowed the community to decide the
matter. If enough admins come forward, RoundUp will win.
I read that as a big push for "written in Python".
I prefer to read it as a big push for "not dependent on non-free
tools".
And I'd prefer it if you'd drop this subject. So, if you have nothing
new to say, kindly leave it. You have made your opinion known, as you
are fully entitled to do. Frankly I am getting less interested in your
opinion with each new post.
You appear to be prepared to go to any length short of providing effort
to support the open source tracker.
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 wrote:
"Ben Finney" <bi****************@benfinney.id.auwrote in message
news:87************@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
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
Ilias Lazaridis wrote:
Giovanni Bajo wrote:
>>Hello,
I just read this mail by Brett Cannon:
http://mail.python.org/pipermail/pyt...er/069139.html
where the "PSF infrastracture committee", after weeks of evaluation, recommends
using a non open source tracker (called JIRA - never heard before of course)
for Python itself.
Does this smell "Bitkeeper fiasco" to anyone else than me?
--
Giovanni Bajo
Fascinating.
The python foundation suggests a non-python non-open-source bugtracking
tool for python.
It's like saying: "The python community is not able to produce the
tools needed to drive development of python forward."
Anyway. The whole selection process is intransparent.
The commitee should have stated "goals" and "requirements" with a
public verification of the tools against them.
Is there any stick in the known universe that you will grasp the *right*
end of? http://wiki.python.org/moin/OriginalCallForTrackers
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 wrote:
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.
the dissenting won't contribute a thing, of course. they never ever do.
but not everyone is wired that way.
</F>
Steve Holden <st***@holdenweb.comwrites:
And I'd prefer it if you'd drop this subject. So, if you have
nothing new to say, kindly leave it.
I'm happy to, but:
You appear to be prepared to go to any length short of providing
effort to support the open source tracker.
This was addressed in a previous post. I don't have the skills nor the
resources to do this. Yes, as has been pointed out, it actually *is*
far less effort to point out problems, than to solve them. That
doesn't detract from the value of pointing out problems.
This thread was started on the shock of realising that a non-free tool
was even being *considered* for the new Python bug tracker. Those are
the terms on which I've been arguing.
Apparently there are some people who *have* put themselves forward to
support a free-software tool. Great! My point all along has been that
Python's developers are well advised to consider *only* free-software
tools for supporting development of Python, and that from among those
the best tool for the job should be chosen.
As you say, nothing new has been said now for a while, so in the
absence of that I'm happy to leave it here.
--
\ "Why, I'd horse-whip you if I had a horse." -- Groucho Marx |
`\ |
_o__) |
Ben Finney
[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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
