Stefan,
Sorry for the long answer ...
Stefan Küng schrieb:
> On 1/26/06, Matthias Wächter <matthias.waechter@tttech.com> wrote:
>> I think that in the change log for each listed entry there should be a
>> bug tracking issue number applied. This is not only for someone like
>> Célio who is interested in his own bug observations but also for developers.
> 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.
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.
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.
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)
* 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)
* 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)
* 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.
If this information is written while the bugs are discussed and fixed,
there is really no additional effort. It's just discipline.
>> [...]
>> v0.9.1:
>> - various minor bugs fixed
>
> That's a valid entry for a changelog. Changelogs have to be short, so
> listing every little change isn't possible.
Well, there could be one bug tracking issue listing all these changes in
short, referred to by this comment at least once easing the task of
finding this information.
>> v1.0.1:
>> - major security bug fixed - please update now!
>
> Security bugs require a detailed description. But not too detailed,
> otherwise some bad guys have it easier to exploit them.
Well, that's an additional topic worth (at least) an additional thread,
but maybe on another mailing list. :)
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.
> Most people won't even know what that is, and definitely don't care.
> Those who do, can always check the commit logs, do a diff, ...
... 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. :)
> Also, some bugs, while fixed in a minute (e.g. wrong variable used,
> wrong if() check, ...) can require a one page long explanation on when
> this really affects you. It's not uncommon that such a bug can only be
> triggered if multiple settings/setups must be set specifically or you
> won't even notice them. So listing all those just for a one-line fix?
> You must be kidding!
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. :)
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jan 26 15:56:26 2006