View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008209||mantisbt||bugtracker||public||2007-07-29 06:30||2007-07-30 03:56|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0008209: Numbering of bugnotes should start from 1|
It is somewhat cumbersome to look at bugnotes in a given issue page and saw them numbered 14034, 14631, 15688 and so on...
I think it would be really useful to show a numbering starting from 1 in each bug
If there is consensus on the general concept, I will have a look at what is required and evaluate the impact on the actual codebase
|Tags||No tags attached.|
I can see where your coming from, but I think trying to change this behaviour will cause more hassle then it's worth:
b) Lets say you add 5 notes to a bug. Note 5 says "I completely agree that should implement this as describe in note 2 but definitely not the solution describe in note 3".
You'd then be in a situation where either
It might be possible to improve the display, but for the reasons stated above, you might find that it may be more sensible to leave 'as is'.
I wonder if there would be any benefit to adding a #view_bugnote_id_threshold config variable, such that normal users can not see the number - i'm thinking companies that want to hide how active or inactive developers are.
In terms of the ~ syntax, I'm sure it would be possible to change that to say ~noteid@bugid or similar to allow the current behaviour.
I don't see the return on investment for this work. The thing that would be hard to fix is that if we implement this we are likely to break all ~ existing links in current installations. Hence, the work around would be to support both modes. But then, we will have to maintain them both.
Hence, I don't think we should go for it. This reminds me of the request to have all projects start with bug number 1, which we always rejected.
a) I don't understand this... :P
b) In general, I think we shouldn't allow deleting stuff. That said, I share your worries about the situation you describe, and the solution I am planning would surely be robust enough to not break in that (common) scenario
We use sequential numbers because numbers have a meaning: if the last bug reported is 8200 and I'm looking at 2077, I already know that's something "ancient".
I think there is a great difference between this and the "restart bug numbering on each project"; that request is driven by the wrong reasoning, becasue they believe the user perceived quality is related to a low issue number.