Matthias Wächter wrote:
>> Do you know that this would increase my workload at least by a factor
>> of two? Most of these bugs are very small and fixed in no time.
>> Creating an entry in the issuetracker would take sometimes more time
>> than to fix a bug.
>
> Sure. That's my very generic point of view. I think co-developers of the
> product automatically have a better overview than any user: They know
> the code already, they sometimes review commits (rev-diff
> notifications), they follow the mailing list(s) in general and may have
> followed the discussions about the bugs. All a user can see at the first
> place is the change log.
Right. But the normal user doesn't care how a bug got fixed or the very
details about it.
> The question is, how much insight is wanted for users and code-newbies.
> The more they can fetch by simply reading change logs, referring the bug
> tracking issue numbers, referring the mailing list threads and such, the
> less work they have and the less work the developers have in responding
> to additional questions on the mailing list.
Up to now, there was only *one* (the one who started this thread) who
wanted to know more about a specific bug. I think that's not a good
reason to increase my workload that much.
> All this is not only done in a favor for the one user but also in favor
> of all the other customers and developers: If Célio can quickly verify
> whether his SMP problem is related to the bug you fixed or not, he can
> quicker or better report his problem.
Well, I'd have more work to do. In fact, a *lot* more work, which I'd
rather spend on coding.
If he had problems before on his SMP machine, he didn't mention them. If
they were that serious, I think he would have mentioned them already.
I think if he really wanted more detailed information about the fixed
bug, he should have also mentioned *what* problems he had which might be
based on that. If I have to do more work, I expect others to do the same.
> As already noted, there are different ways of helping the reader, four
> of them coming into my mind:
>
> * Giving an Id of one (or more) issues of the issue tracker related to
> the change:
>
> BUG: Fixed https and client certificates (issue4711)
That would mean to enter each and every bug in the issuetracker. As I
already mentioned, this would increase my workload too much.
> * Referring to the mailing list archive (unambiguously) regarding the
> bug report and/or the solution email:
>
> BUG: Fixed https and client certificates
> (http://svn.haxx.se/tsvn/archive-2006-01/0577.shtml)
What about bugs which never get to the mailing list (like this one)?
Some of the bugs are found due to sent in crashreports. And some I find
on my own.
> * Referring to the revision numbers of the (public) source code
> repository, even better if the developers follow a descent commit
> message policy:
>
> BUG: Fixed https and client certificates (r4711, r4715)
Could be done. But 99% of all users won't care or understand about the
sourcecode.
> * Giving the whole bug description verbose:
>
> BUG: Fixed https and client certificates
> - If the specified client certificates is located on a network
> share, the client certificate was not used and connections
> terminated unexpectedly with a "File not found" error.
> The current version allows client certificates located on
> a network share to work the same way as local ones.
Well, that I already do for most of the bugs. But a bug like we're
talking about, will take (as I mentioned before) a whole page to describe.
> If this information is written while the bugs are discussed and fixed,
> there is really no additional effort. It's just discipline.
Not really. If you're working in a big team, you're right. But I'm
almost alone here working on the project (coding).
> BTW: Update handling (security updates as well as normal updates) could
> be improved in TSVN: When TSVN reports a new version by checking the web
> site, the dialog window should offer two more buttons: "Update now ..."
> automatically fetches and installs the new MSI using the current
> settings. "More information" would be the second button opening a web
> browser opening the release notes referring the download files only one
> mouse click away.
"Update now" is risky. It could be misused by bad guys to make TSVN
download something nasty. We don't have certificates with which we can
sign our code, so that's out of the question.
And the update dialog already takes you to our download page (if you
click on the new version information). On that page, there's a link to
the new installer and also the changelog. If people really are
interested in that, they shouldn't be *that* lazy.
> ... or ask on the mailing list. This may be option five to the list
> given above: Don't give details in the change log but give this
> information on demand. But give it if asked for. :)
Ok then. I hope you like books, because that one will be long:
In TSVN, many dialogs use more than just one thread. Most use two
threads, one responsible for the UI, and one to execute longer tasks
like fetching the status of a working copy. To synchronize those
threads, a boolean variable is used to indicate if the worker thread is
running. If it is running, the UI thread isn't allowed to access data
which the worker thread is updating. Otherwise a crash can occur due to
the data not being valid (either because it was already removed,
replaced or not yet fully added).
On SMP systems, that variable isn't enough. Some SMP systems also have
different processor caches. If the worker thread now sets the 'blocking'
variable, the UI thread running on another processor and using the cache
of the other processor, that variable isn't always updated in the other
cache in time. So even if the worker thread indicates that it is working
on data, the UI thread might not notice it because that processor still
has the old value of that variable in the cache.
To avoid such situations, we'd have to use special APIs which force the
processor caches to be updated (by flushing the modified variable to
main memory).
This problem affects almost all of the TSVN dialogs and the cache.
(now I could write another two pages about the specific situations where
this could actually happen).
As you can see, most users won't care about this, and most won't
understand it either. But I had to sit down and spend 15 minutes writing
this stuff. 15 minutes I could have spent coding.
> Of course there are various levels of bug tracking quality. Companies
> often require their employees to file a bug report, especially if they
> are forced to enter a bug id upon commit. Sometimes a bug is found and
> fixed at the same time and the developer only requires a bug id for
> commit access. Lazy ones can be monitored producing issues like the
> following:
>
> Date: Tue 2005-05-05, 16:34, Zulu opens bug id4711
> State: Open
> Responsible: Zulu
> Text: Fix the bug
>
> Date: Tue 2005-05-05, 16:38, Zulu adds comment to id4711
> State: Open -> Testing
> Responsible: Zulu -> Gamma
> Text: Done, please test
>
> Date: Tue 2005-05-05, 16:39, Zulu adds comment to id4711
> Responsible: Gamma -> Zulu
> Text: I take over
>
> Date: Tue 2005-05-05, 16:41, Zulu adds comment to id4711
> State: Testing -> Closed
> Text: Works.
>
> Simple fixes for diffuse problem situations often don't seem worth the
> effort for describing what was did and why. The more effort the
> developer had fixing the issue, the more time he is willing to spend on
> describing his hard work. Even if from the user's point of view the
> justification may look quite different. :)
You can do that if you're in a team.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jan 26 19:02:34 2006