Tcl/Tk 8.5.3 RELEASED
Donald G Porter
Tcl/Tk 8.5.3 Release Announcement
June 30, 2008
The Tcl Core Team is pleased to announce the 8.5.3 releases of the Tcl
dynamic language and the Tk toolkit. This is the third patch release
of Tcl/Tk 8.5. More details can be found below. We would like to
express our gratitude to all those who submit bug reports and patches.
This information is invaluable in enabling us to identify and eliminate
problems in the core.
Where to get the new releases:
------------------------------
Tcl/Tk 8.5.3 sources are freely available as open source from the
Tcl Developer Xchange web site at:
http://www.tcl.tk/software/tcltk/8.5.html
This web page also contains additional information about the releases,
including new features and notes about installing and compiling the
releases. Sources are always available from the Tcl SourceForge
project's file distribution area:
http://sourceforge.net/project/showfiles.php?group_id=10894
Binaries for most major platforms are available from:
http://www.activestate.com/Tcl
For additional information:
---------------------------
Please visit the Tcl Developer Xchange web site:
This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.
Summary of Changes since Tcl/Tk 8.5.2:
--------------------------------------
The following were the main changes in Tcl/Tk 8.5.3. A complete list
can be found in the changes file at the root of the source tree. The
more complete ChangeLog is also included with each source release. This
is a patch release, so it primarily included bug fixes and corrections
to erratic behavior. Below are only the most notable changes.
* Corrected unreliable [fcopy] callbacks and enabled bidirectional fcopy.
* Support Tcl Module packages in a Safe Base interp.
* Fixed [slave bgerror] to operate in slave, not master.
* Fixed crash when a ttk::label gets width or height of zero.
* Fixed crash in [chan postevent].
* Fixed crash in [dict append].
* Fixed crash in [glob -dir {} a].
* Fixed crash in Tk_ParseArgv().
* Fixed crash in a global [grab].
* Fixed [tell] overflow on large files.
* Fixed missing <Enter> events on canvas items.
* Made Tk more robust when Tcl and Xlib disagree about system encoding.
* Improved Solaris support for DTrace and 64 bit.
* Fixed floating point rounding on Solaris/x86.
--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Witek
GUI when some simple and annoying bugs are persistent?
I repoted a bug in February regarding broken behaviour of
tk_getOpenFile -multiple 1 on Linux. I posted it to the bugtracker. Then
another person submitted it again in April.
Two versions (8.5.2 and 8.5.3) were released since I reported the bug for
the first time and it is still there. For me it is crucial to be able to
select multiple files in an openFile dialog. This bugs seems to be
relatively simple to fix. Why is it still present? Maybe Tcl/Tk on Linux is
not as important as on Windows/Mac?
Please advise
Witek Mozga
a casual programmer
Gerald W. Lester
> How am I supposed to consider Tcl/Tk8.5 as serious language for scripting
> GUI when some simple and annoying bugs are persistent?
>
> I repoted a bug in February regarding broken behaviour of
> tk_getOpenFile -multiple 1 on Linux. I posted it to the bugtracker. Then
> another person submitted it again in April.
>
> Two versions (8.5.2 and 8.5.3) were released since I reported the bug for
> the first time and it is still there. For me it is crucial to be able to
> select multiple files in an openFile dialog.
If it is really critical, and you do not feel like fixing it yourself,
ActiveState offers support contracts -- some with guaranteed response time.
> This bugs seems to be
> relatively simple to fix. Why is it still present? Maybe Tcl/Tk on Linux is
> not as important as on Windows/Mac?
>
> Please advise
>
> Witek Mozga
> a casual programmer
>
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Donald G Porter
> I repoted a bug in February regarding broken behaviour of
> tk_getOpenFile -multiple 1 on Linux. I posted it to the bugtracker.
Who is the item assigned to? Have you tried writing them to ask what
the delay is?
USCode
Out of curiosity, did the tk_getOpenFile command ever support
multiple-file selections on Linux? Or is this missing functionality?
If this was something that worked before but is broken now I agree it
should be a high-priority fix but unfortunately this is the reality of
open-source software. No one actually gets paid or has a formal
obligation to make a fix but you are free to fix it yourself and offer
the fix to the community.
ZB
> How am I supposed to consider Tcl/Tk8.5 as serious language for scripting
> GUI when some simple and annoying bugs are persistent? [..]
It's not that bad with TCL anyway: I can recall, when I reported to the
dev-team of ${an unix-like operating system} that their ATA-driver is flawed
- and gave even necessary evidence, to help them to trace the problem - I've
received: "...since you've got access to the sources, you can fix it now,
and send us a patch". :D
...a dev-team member of another ${unix-like operating system}, being informed
about ACPI-related problems (with evidence, of course), has replied with an
invitation: "...it's a great opportunity for you to get in!" :D
Well, maybe...
--
ZB
Eric Hassold
Gerald W. Lester wrote :
> Witek wrote:
>> How am I supposed to consider Tcl/Tk8.5 as serious language for scripting
>> GUI when some simple and annoying bugs are persistent?
>>
>> I repoted a bug in February regarding broken behaviour of
>> tk_getOpenFile -multiple 1 on Linux. I posted it to the bugtracker. Then
>> another person submitted it again in April.
>>
>> Two versions (8.5.2 and 8.5.3) were released since I reported the bug
>> for
>> the first time and it is still there. For me it is crucial to be able to
>> select multiple files in an openFile dialog.
>
> If it is really critical, and you do not feel like fixing it yourself,
> ActiveState offers support contracts -- some with guaranteed response time.
Is it irony, or a real suggestion?
First reaction for this 8.5.3 release should definitely have been first
of all lot of thanks for all contributors and maintainers, and
qualifying Tk as a "not serious language" was a little bit harsh.
BUT
Tcl needs users as much as it need maintainers, especially if those
users take care of sharing their experience, reporting bugs,...
Tomorrow's contributors will be today's users, and I believe we should
put more care in convincing programmers and newcomers Tcl is a great
language, built around a helpful community, and providing actual
solutions to their practical needs, if we want Tcl to keep on being
alive tomorrow thanks to a users community as broad as possible.
Of course, ActiveState offers great support and expertise. But I really
hope no one want to let users believe this is the official way to go to
have a regression in a Tcl release to be fixed (otherwise, please let us
know).
About this specific issue: support for -multiple option is documented to
works on Unix version, and was working as expected in 8.4 branch.
Indeed, this bug is a regression introduced in 8.5b3, when switching to
Tile widgets in file dialog. Comment and a workaroud provided by Ian Gay
on 2008-04-09 can be found in followups of bug tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=1936220&group_id=12997&atid=112997
and consists simply in adding a '-takefocus 0' option, in tkfbox.tcl
line 1155, when creating the Ok/Open button.
A serious regression, a simple fix, but problem persists 2 releases and
3 monthes later. We all know current maintainers are already offering
lot of unpaid time and can't do more. So I believe we should face it,
this sounds like another alert on the lack of resources required to keep
Tcl/Tk to the highest grade of quality it has ever been since so many years.
Not complaining, even less criticizing, only observing and trying to
anticipate.
Eric
Donal K. Fellows
> Tcl needs users as much as it need maintainers, especially if those
> users take care of sharing their experience, reporting bugs,...
> Tomorrow's contributors will be today's users, and I believe we should
> put more care in convincing programmers and newcomers Tcl is a great
> language, built around a helpful community, and providing actual
> solutions to their practical needs, if we want Tcl to keep on being
> alive tomorrow thanks to a users community as broad as possible.
>
> Of course, ActiveState offers great support and expertise. But I really
> hope no one want to let users believe this is the official way to go to
> have a regression in a Tcl release to be fixed (otherwise, please let us
> know).
If you want something fixed, the only ways that are guaranteed to work
are to do it yourself or to hire someone else to do it for you. Really.
I have only a limited amount of time to work on Tcl/Tk, and most of the
other maintainers are the same; we don't sit around all day wondering
what to do, we get on with our jobs. Sometimes we have some spare time
and then we create new features, fix bugs, or do other maintenance. But
if you want a guarantee, it'll cost you one way or another. It's the way
of the world. Always was. Free bugfixes by others are on a "best effort"
basis everywhere.
That said, sometimes the lack of a bugfix is just a slipup. :-)
Donal.
Andreas Leitgeb
> If you want something fixed, the only ways that are guaranteed to work
> are to do it yourself or to hire someone else to do it for you. Really.
I think, the main reason for the quite disappointed posting was, that
1.) the bug was extraordinarily simple
2.) there already existed a patch in the tracker
3.) but it was still missed again and again.
Perhaps, in future such trivial bugfixes shall be tagged with a prio 9
to avoid their being missed accidentally. (there have already been
speling fixes in docu with a prio 9, just to avoid their being missed)
So, obviously it's not as if that prio was only reserved for real
show-stopper bugs.
yahalom
I really appreciate the work done by the TCT ,core and packages
developers. complaining about what they do seems to me like spitting
from the well you drink from. We all enjoy tcl due to their work and
the glass is certainly on the full side. Keep on the great work you
do...
Eric Hassold
I totally agree, and mentionned in my message current maintainers
already offer more time for free we could expect. And I know how
ungrateful it is to offer time for free as a maintainers, while having
to get on with "real" job. I tried to insist (probably unsuccessfully)
that my post wasn't criticizing anyone, but only pointing out Tcl is
maybe lacking some resources for maintaining it, commiting available
patches, etc... My suggestion wasn't to blame those who already offer
lot of their time, but, from observation of a "slipup", start thinking
about how to prevent it, how to find more resources to help them, or how
to improve the collaborative development process. I find Andreas'
suggestion one good step in this direction.
Eric
Ron Fox
> Donal K. Fellows <donal.k...@manchester.ac.uk> wrote:
>> If you want something fixed, the only ways that are guaranteed to work
>> are to do it yourself or to hire someone else to do it for you. Really.
>
> I think, the main reason for the quite disappointed posting was, that
> 1.) the bug was extraordinarily simple
> 2.) there already existed a patch in the tracker
> 3.) but it was still missed again and again.
>
> Perhaps, in future such trivial bugfixes shall be tagged with a prio 9
> to avoid their being missed accidentally. (there have already been
> speling fixes in docu with a prio 9, just to avoid their being missed)
Is this irony ;-)
> So, obviously it's not as if that prio was only reserved for real
> show-stopper bugs.
>
--
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321
ZB
> you are free to fix it yourself and offer the fix to the community.
Yes, I always liked this "tip" :] Actually, why there are any "download"
links at all? It should be replaced by: "you saw, how I made it - and now
you can easily make it on your own (or even better)". ;]
--
ZB
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> speling fixes ...
> ^^^^^^
> Is this irony ;-)
In the context of such errors and their fixes, it is written with
one "l". If it's about correct spelling, then two "l" are correct.
Since all the dictionaries are all about correct spelling, they
completely miss out on this subtlety :-D
Witek
> I really appreciate the work done by the TCT ,core and packages
> developers. complaining about what they do seems to me like spitting
> from the well you drink from.
I don`t use Tcl to earn my daily bread so I don`t have to worship its
developers. I just wanted to use a tool they offer.
I read that Tcl is simple yet powerful and that Tk "can produce rich,
native applications that run unchanged across Windows, Mac OS X, Linux and
more". I tried and it was not.
I thought that input from a user will be apreciated by the developers
because they give me a tool for free and I help to make the tool better by
pointing a bug, and both sides gain.
Why the official website so much encourages people to use Tcl if their input
is later ignored? I think it would be fairly to cite on the website what
some of you say on this group: "I have only a limited amount of time to
work on Tcl/Tk, and most of the other maintainers are the same". This would
make clearer for a novice what to expect.
Apparently Tcl is not very popular these days and "fix the bug yourself"
strategy, repeling for a novice user like me, will not help it gain more
attention.
--
Witek
http://trimen.pl/witek/
Donal K. Fellows
> Why the official website so much encourages people to use Tcl if their input
> is later ignored?
'Cos we slipped up in this instance. Sometimes there's no deep reason.
(We're also less inclined to hold back on releases while we try to
squelch every bug. That was tried in 8.4 and 8.5, and those releases
took *ages* as a result.)
Donal.
USCode
It's not a "tip", it's the nature of open source.
ZB
> It's not a "tip", it's the nature of open source.
...and your assumption is: "we all are developers"? ;)
--
ZB
damon.c...@gmail.com
was just missed. Maybe we need a quick review before a release to
pick up low-hanging fruit in the bug tracker. This one CERTAINLY
falls into that category. Particularly since someone had already
submitted the bug AND a fix.
D
ZB
> I don't think this one was some great conspiracy to ignore a bug. [..]
...and I don't think either.
--
ZB
Aric Bills
> I read that Tcl is simple yet powerful and that Tk "can produce rich,
> native applications that run unchanged across Windows, Mac OS X, Linux and
> more". I tried and it was not.
>
> I thought that input from a user will be apreciated by the developers
> because they give me a tool for free and I help to make the tool better by
> pointing a bug, and both sides gain.
>
> Why the official website so much encourages people to use Tcl if their input
> is later ignored? I think it would be fairly to cite on the website what
> some of you say on this group: "I have only a limited amount of time to
> work on Tcl/Tk, and most of the other maintainers are the same". This would
> make clearer for a novice what to expect.
>
> Apparently Tcl is not very popular these days and "fix the bug yourself"
> strategy, repeling for a novice user like me, will not help it gain more
> attention.
>
> --
> Witekhttp://trimen.pl/witek/
It's unfortunate that your bug report languished for so long, but I
don't think it's fair to judge Tcl (or the Tcl community) on the basis
of this one experience. For starters, within hours of your post Eric
Hassold was able to locate a patch to fix the issue you reported.
Things sometimes fall through the cracks; as far as I can tell, Tcl is
no different in this respect from every other major venture in life.
As someone who has reported bugs in the past, I can testify that the
Tcl maintainers value bug reports and try to respond to them
promptly. As far as I know, no one has tried to lead anyone to
believe that the maintainers have an unlimited amount of time to
devote to Tcl or that they guarantee an immediate turnaround on
anything. (I doubt that many other projects, open source or
commercial, promise this either.)
However, in the absence of such a guarantee, thousands of programmers
HAVE written rich applications in such a way that the same source code
runs on Windows, OS X, and Linux. Doing so does require some care,
but that's a topic for another place and time. The point is that the
claims made on the Tcl web page are accurate, a point that I and
others can back up with actual source code.
It would be a shame to let this one bug overshadow all the powerful
features Tcl/Tk has to offer. Please accept the community's sincere
apologies and give it one more try.
Aric Bills
> Dnia 30.06.2008 USCode <d...@spamon.me> napisa³/a:
>
> > you are free to fix it yourself and offer the fix to the community.
>
> Yes, I always liked this "tip" :] Actually, why there are any "download"
> links at all? It should be replaced by: "you saw, how I made it - and now
> you can easily make it on your own (or even better)". ;]
> --
> ZB
I understand the frustration with the "you can fix it yourself"
attitude, and I agree that we should take care in suggesting that
others fix the bugs they encounter. However, community-provided bug
fixes *are* a key element in the development medium-to-large open
source software, and in a community where in theory *everyone* is a
programmer (as you pointed out), there should be several people with
the skills to do such work, so it may not be entirely out of place to
remind people of this fact.
Plus, aren't we fortunate to have the ability (in legal terms if not
in terms of personal skills) to fix the bugs we encounter? When I
come up against a bug in proprietary software (and even Steve Ballmer
admits that they're in there), I *might* be able to report it, but
then I'm at the mercy of the company to fix it; what's worse, when and
if they fix the bug, they will probably make me pay to get a version
where the bug is fixed!
ZB
> I understand the frustration with the "you can fix it yourself"
> attitude, and I agree that we should take care in suggesting that
> others fix the bugs they encounter. However, community-provided bug
> fixes *are* a key element in the development medium-to-large open
> source software, and in a community where in theory *everyone* is a
> programmer (as you pointed out),
No, even in theory one cannot make such assumption. It's a poor excuse,
like the one: "you've got root access to system installed on your machine,
so you're system administrator".
"system administrator rights" != "system administrator knowledge & skills"
The same with programming, and the source code availability.
> there should be several people with the skills to do such work, so
> it may not be entirely out of place to remind people of this fact.
I'm afraid, you misunderstood me a little.
If I'm sending a bugreport about problems with ATA driver, it doesn't mean,
that I could fix it by myself - but I don't want to, because I prefer to go
to cinema, for example. In fact, no idea how it's working, and no plans
(for the nearest future), to study the case - just because of shortage of
time. Of course, I'm aware, that the others can be busy too. So pay
attention, that availability of the source code is only the *potential*
(not to be confused with *real*) possibility to fix the bugs by anyone.
The second thing is, that - still talking about that ATA - I was rather
surpised receiving the answer, which can be shortened to: "So, it's not
working? We don't care. Works for us". Leaving the bug, that can make
problems not just to me, but to the 10 thousand other users as well?
By the quite other occasion someone replied, that "the devs are making it
just for themselves; and it may work for you, or may not". But such approach
seems to be far from reliability. My understanding is, that when someone
gives his work to the public, he can expect then not only the gratitude, but
bugreports as well (and comments about his work, and questions...). And such
bugreports simultaneously are expectations, that the problems will be fixed.
--
ZB
Aric Bills
> Dnia 01.07.2008 Aric Bills <aric.bi...@gmail.com> napisa³/a:
>
> > I understand the frustration with the "you can fix it yourself"
> > attitude, and I agree that we should take care in suggesting that
> > others fix the bugs they encounter. However, community-provided bug
> > fixes *are* a key element in the development medium-to-large open
> > source software, and in a community where in theory *everyone* is a
> > programmer (as you pointed out),
>
> No, even in theory one cannot make such assumption.
I was referring to the Tcl community, where I think the assumption
holds. The assumption is not that everyone can hack the core, but
that a certain subset of individuals have those skills, and another
subset has the aptitude to acquire them. Since users are essentially
getting something for nothing, I don't think the occasional, tactful
invitation to contribute is out of line. At the same time, I don't
fault anyone who can't or doesn't contribute code.
> It's a poor excuse,
> like the one: "you've got root access to system installed on your machine,
> so you're system administrator".
>
> "system administrator rights" != "system administrator knowledge & skills"
>
Well, you may or may not be competent to run a particular operating
system on your computer, but if you are the owner, you bear the
ultimate responsibility for system administration, for better or for
worse.
> The same with programming, and the source code availability.
>
> > there should be several people with the skills to do such work, so
> > it may not be entirely out of place to remind people of this fact.
>
> I'm afraid, you misunderstood me a little.
>
> If I'm sending a bugreport about problems with ATA driver, it doesn't mean,
> that I could fix it by myself - but I don't want to, because I prefer to go
> to cinema, for example. In fact, no idea how it's working, and no plans
> (for the nearest future), to study the case - just because of shortage of
> time. Of course, I'm aware, that the others can be busy too. So pay
> attention, that availability of the source code is only the *potential*
> (not to be confused with *real*) possibility to fix the bugs by anyone.
We agree on this point.
> The second thing is, that - still talking about that ATA - I was rather
> surpised receiving the answer, which can be shortened to: "So, it's not
> working? We don't care. Works for us". Leaving the bug, that can make
> problems not just to me, but to the 10 thousand other users as well?
I have been there too, and I know how frustrating it can be. But
aside from the discourteous response you received, I don't see any
room for objection here. The developer is not obligated to act in
your best interest or even in the best interest of ten thousand other
users, much to everyone's chagrin.
> By the quite other occasion someone replied, that "the devs are making it
> just for themselves; and it may work for you, or may not". But such approach
> seems to be far from reliability. My understanding is, that when someone
> gives his work to the public, he can expect then not only the gratitude, but
> bugreports as well (and comments about his work, and questions...). And such
> bugreports simultaneously are expectations, that the problems will be fixed.
Imagine you want to do something good for the world, so you raise some
funds, take some time off and come to my village in Outer Slobovia,
where you install a generator and wire my house. In your haste, you
forget to connect one of the outlets to rest of the electrical
system. I can ask you to fix the problem (and even expect that you
will), but if you are short on time or funds, you may not be able to
do so no matter how much you would like to. In that situation it
might not be out of place for you to suggest that I do it myself or
hire someone to do it for me. I may or may not have the skills or the
means to do those things, but at the end of the day, what are my other
options? I can live without electricity (note that this--my previous
state of affairs--is the worst case scenario), I can search for
another volunteer who can do the job, or I can live with the work you
have done in its present state.
Users of open source software are like the residents of my village in
Outer Slobovia; to the extent that we do not know how to perform the
kind of work that is performed for us, we are at the mercy of generous
people like you. Still, considering the negligible investment
required to acquire and use OSS, the returns are tremendous, in spite
of occasional inconveniences.
Kevin Walzer
>>
>>> you are free to fix it yourself and offer the fix to the community.
>> Yes, I always liked this "tip" :] Actually, why there are any "download"
>> links at all? It should be replaced by: "you saw, how I made it - and now
>> you can easily make it on your own (or even better)". ;]
>> --
>> ZB
>
> I understand the frustration with the "you can fix it yourself"
> attitude, and I agree that we should take care in suggesting that
> others fix the bugs they encounter. However, community-provided bug
> fixes *are* a key element in the development medium-to-large open
> source software, and in a community where in theory *everyone* is a
> programmer (as you pointed out), there should be several people with
> the skills to do such work, so it may not be entirely out of place to
> remind people of this fact.
What if you don't have the skills? How do you learn?
I've submitted patches to other open-source projects (cf Python) because
the bugs were within my skills to fix. For instance, I fixed a bug in
IDLE (Python's Tk-based editor) that required patching a Python-Tkinter
source file--this was within my skill set.
By contrast, when I look at the open bugs in Tk proper that might be
relevant to me (bugs in Tk's Aqua/Mac implementation, for instance),
they all require coding in C. Actually, it's more complicated than
that--they require a knowledge of 1.) C, 2). Tk's C API, and 3.) Apple's
Carbon API. #1, I can do, a little; #2. Looks like I can grok it with
some effort, since Tk's C API is very clean and well-organized; #3,
Forget it. Apple's Carbon API is very baroque, poorly documented, and
(as of the latest version of OS X) hardly worth learning anyway because
it's been deprecated.
When faced with these obstacles, I tend to get discouraged. Tk on the
Mac needs more contributors, but the barriers to entry at the core C-API
level are simply too high.
Any thoughts about this?
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
USCode
>> It's not a "tip", it's the nature of open source.
>
> ...and your assumption is: "we all are developers"? ;)
No, but it is: "reality". ;)
Donal K. Fellows
> ...and your assumption is: "we all are developers"? ;)
On comp.lang.tcl? I think it's safe to assume that everyone here can
write Tcl scripts, which is what some parts of Tcl and Tk are
implemented as (notably the Unix tk_get*File code is pure Tcl).
Donal.
Neil Madden
[...]
>
> If I'm sending a bugreport about problems with ATA driver, it doesn't mean,
> that I could fix it by myself - but I don't want to, because I prefer to go
> to cinema, for example. In fact, no idea how it's working, and no plans
> (for the nearest future), to study the case - just because of shortage of
> time. Of course, I'm aware, that the others can be busy too. So pay
> attention, that availability of the source code is only the *potential*
> (not to be confused with *real*) possibility to fix the bugs by anyone.
>
> The second thing is, that - still talking about that ATA - I was rather
> surpised receiving the answer, which can be shortened to: "So, it's not
> working? We don't care. Works for us". Leaving the bug, that can make
> problems not just to me, but to the 10 thousand other users as well?
>
> By the quite other occasion someone replied, that "the devs are making it
> just for themselves; and it may work for you, or may not". But such approach
> seems to be far from reliability. My understanding is, that when someone
> gives his work to the public, he can expect then not only the gratitude, but
> bugreports as well (and comments about his work, and questions...). And such
> bugreports simultaneously are expectations, that the problems will be fixed.
Is your suggestion that contributors to/maintainers of open source
projects be made duty bound and/or legally responsible to fix all bugs
that are submitted to them?
I believe the Tcl and Tk maintainers already put in a huge investment of
time, for very little thanks, to keep the tools we use every day in good
condition. Sometimes simple bugs get overlooked. That is just a fact of
human nature. Sure, perhaps more could be done to check the bug tracker
before a release, but that just adds more time that somebody has to
commit to (and thus less time they have to spend on fixing real
show-stoppers).
Certainly, I don't think bug reports are ignored, and patches are always
welcome. *Everybody*, no matter their technical competence, has the
ability to find out when a release is due and chase up whether fixes
they need are going to be included. (Referring to the OP of this
sub-thread:) Complaining about it after the release is announced seems
to me to just indicate that you weren't sufficiently concerned about the
patch in the first place to track its progress -- and thus it is a bit
hypocritical to complain about the priorities of volunteers.
-- Neil
ZB
> Is your suggestion that contributors to/maintainers of open source
> projects be made duty bound and/or legally responsible to fix all bugs
> that are submitted to them?
What's my suggestion has been written already, and I'm unable to express
this differently. If you misunderstood - I'm sorry, perhaps my poor english
is to blame (still working on this). I'm not "native speaker".
--
ZB
Larry W. Virden
> My understanding is, that when someone
> gives his work to the public, he can expect then not only the gratitude, but
> bugreports as well (and comments about his work, and questions...). And such
> bugreports simultaneously are expectations, that the problems will be fixed.
While it would be nice if the world worked in such an altruistic
manner. However, in general, what I have seen happen over 30 years of
open source is often "I wrote something, it works for me, here's the
source, go figure how to get it to work, and oh, by the way, if you
fix something, tell me about it and maybe if I'm not bored I will
apply the fixes you provide" kind of mentality.
Tcl doesn't have this, in general. However, there are a large number
of bugs in the list. More than one person can read through on a
regular basis. We don't have in general someone just reading bug
reports and assigning them to someone. We don't have, in general,
someone providing a roadmap of features that someone on the team is
going to be implementing. We have a group of hard working (over
working, in some cases) programmers who try to keep track of the most
recent bug reports. They work a lot of unpaid hours, trying to keep
things going, add in a few new things occasionally, read over recent
bug reports to see if they can reproduce problems, and occasionally
look over the reports of the past to see if they can reproduce the
problems.
The BEST way, in my opinion, to handle this sort of thing is to a)
report the problem initially, b) test in subsequent alpha and beta
releases, c) update the original report with comments as to any change
(or lack thereof) in the problem, d) ask here (or in some cases on the
wiki, or tcl core, or other forums) if anyone has an idea of a way to
fix the problem, e) update the problem ticket with new info and leads
as found, and f) if during the process of the release of a new
version, your patch isn't found, say something over on TCL CORE before
the release, asking if someone could look at the ticket and update the
code before the release.
Is that a lot of work? Yes. Is it technical - not in general. It is
persistence. Not in a pushy obnoxious manner (Well, not if done in a
humble, helpful manner). And then fixes become available as you need
them.
We had a problem a few yrs ago. It was a combo of platform and options
that not many others were exercising. We submitted several patches,
worked with people who wanted to try things another way, and
eventually the change made it into the distribution.
Until that time, each release, we applied patches, etc. so we had the
fix locally.
Of course, if anyone out there is reading this, has a LOT of money,
perhaps is retired with a lot of time on his or her hands, and wants
to either work on things or pay someone else to, I figure something
could be worked out with several of the regular maintainers...
Maybe a place in Monte Carlo, or in the Alps, or whatever...
Ralf Fassel
| [LOT of money]
|
| Maybe a place in Monte Carlo, or in the Alps, or whatever...
Where do I apply? :-)
R'