[size=92]I believe Tow took care of that by simply renaming SVN to 0.75 (was the main release anyway). And now we have the 0.next that can always be used until the next rename (then recreated, a.s.o.). [/size]
Now, Iād like to propose the devs another convention, regarding closing reports on Mantis:
Immediately closing for two categories (EDIT: I mean ācategoriesā in a generic way, not those in the āCategoryā column on Mantis):
NON-ISSUES: when investigation proves the behavior is identical with H3 (unless H3 was buggy on that item to start with), or if there is a difference, itās a known VCMI enhancement actually; also reports simply created by mistake go here (an admin can delete those afterwards, if the case)
DUPES: but only when itās an obvious dupe (to avoid closing a report which contains useful extra information)
RESOLVED items are the third and last category which needs closing, but my proposal is that the dev applying the fix in SVN only marks it as Resolved, without closing, which should be done only after the next public release, if the fix is confirmed.
I came to the conclusion this approach may (probably) be best, after an exercise I did today: I went through more than half of all reports marked as Resolved, to see which of them can be indeed closed. And it proved useful from 4 points of view:
a) ~45 Resolved reports closed (cleaning a bit the queue, with the certainty that theyāve been properly fixed, as I did IMO all the necessary to reproduce them)
b) ~5 New/Assigned reports moved to Fixed and Closed: while testing the Resolved ones, I also checked their relationships, and it turned out some of those were fixed as well
c) ~5 Resolved reports left open, some moved to feedback, because 1 was not fixed at all, 3 partially fixed and 1 still has a related issue pending (not reported elsewhere) - IIRC
d) Last but not least, while trying to reproduce all these bugs, I ran into about 10 other bugs, which I wouldnāt have discovered otherwise through regular testing (at least most of them).
So if nobody minds, Iām gonna continue this approach, as it proved (for me at least) one of the most efficient testing exercises since I joined the project. But feel free to share if you prefer another approach.
If we have such categories, we will loose information about the category assigned by reporter (town screen / battle etc.). Whatās wrong with using status / resolution fields? We can set status to closed and resolution to duplicate / wonāt fix (or add new resolution if possible - non-issue).
Oh sorry, it seems the way I put it was a bit confusing. I definitely didnāt mean that we create new categories. All current settings/statuses/categories/etc are very good as they are, and nothing needs changing. Perhaps not even possible, as they may be standard on Mantis. I was just referring to dev/admin actions. Perhaps I should have better used the word ātypesā, or specify Iām not referring to Mantis categories, but using the term in a more generic way.
My main concern was when do we close the Resolved reports. I felt that closing upon fixing is too soon (for me āclosedā reports are those we shouldnāt worry about anymore, which was not the case for 10% of our resolved reports, from what Iāve seen yesterday). So far Iāve already applied the āimmediate closingā policy for dupes, plus we had a few cases of non-issues (#75,198,212); and yesterday I closed about 50 Resolved reports, but only after verifying in 0.75 that they are fully fixed.
Basically I just wanted to know if the others are okay with the above approach, which is pretty much already applied. Perhaps as a sort of guarantee we wonāt have the case one day that a partially fixed bug is overlooked (because the related report was closed before checking that everything works fine in the next release).
[size=84]PS: I can see why my proposal, from the perspective of changing all categories, and moving reports from one category to another in order to have them closed, sounded like a terrible headache, with no added value.[/size]
I think I figured out why. There was one note from me on that report, which I marked as āprivateā, because it was outdated (after I figured the cause of the crash, it wasnāt relevant anymore).
The reason why TowDragon could still see the report, is most probably because heās an admin as well. That doesnāt mean itās a correct behavior (IMO). The purpose of marking one attached note as āprivateā is of course not to hide the whole report from the others. Iāve made the note āpublicā again, so you should be able to see #309 now. Let me know if otherwise.
Meanwhile Iāll check if this bug is known to the Mantis devs or else report it.
EDIT: Yes, itās a bug spotted by others as well in Mantis 1.2.0rc1 (which we are using). It has been fixed for RC2, but I donāt know if/when weāll make that update as well. Making notes private in our project does not seem of much use though, so I guess an update just for this is not really needed for now.
Weāre starting to get spam on Mantis. We had two such posts today on #174 and I think there was another case about a week ago (I saw a note from āanonymousā deleted on another report by one of the devs some time ago - I guess it was the same case).
If this continues, we may have to restrict the access for anonymous users (perhaps give it āviewerā profile, with possibility to only create reports, but not to add notes?).
I noticed. Weāve got about 10 spam notes in 24h.
I removed the right to add notes for anonymous users. They can still create reports though (I guessed that a bot can easily add a note, but less likely to fill in all the necessary fields for a new report). If Iām not mistaken, we didnāt have anonymous reporters anyway, just members of this forum forgetting to login when creating a report.
Itās a temporary solution to stop the spamming, until TowDragon & Tow take a decision upon it.
EDIT: There is a small ābugā (?) with this set-up though, namely that guests have to follow an external link to the āReport Issueā page. Iām not yet decided if thatās a good or a bad thing. On one hand it increases the chance that we get only genuine reporters, if they have to follow the links from our homepage (or the forum page); on the other hand, if one of these reporters prefers to stay anonymous and puts the Mantis View Issues page in their favorites, they wonāt have the Report Issue link on top to use it. Actually, from what Iāve noticed, the āReport Issueā link may appear appear on top of their page if they recently used the external link (so they can create a couple of bugs in a row, w/o the need of going through our website), but it disappears after a while. Because of that behavior Iām not sure if itās a bug, or implemented as a feature (against bots who āknowā how to create reports).
Meanwhile I also found out that captcha codes for Mantis guest users have been already requested about 3 years ago (and acknowledged by the devs as useful), but they havenāt been implemented to this day in the application. There are however some .php files attached to report #7741. Perhaps Tow or TowDragon can see if they represent a solution.
Iāll try adding āproject nameā captcha (as well as upgrading script to latest version) when moving tracker to the new server. (Should be done within a month or sth, more info later)
So far itās fine. Since I removed the access to add notes for anonymous users, we didnāt get any spam. They can still create reports, and for notes they could use the forum for the time being. Of course, ideally would be to allow them to also add notes, so if the scripts (or how are they called) from report #7741 will help (or sth similar), great.
Btw, I also added the right for reporters to edit their own notes upon request from phomm. Iām not sure if we never had that, or we actually did, but you removed it for some practical reason.
On a separate note:
I wanted to add two more columns in my āView Issuesā page: Product Version and Fixed in Version, but due to a known bug from 1.2.0rc1, they are not displayed correctly. I see a fix is mentioned HERE. Tow/TowDragon - when you have time - can you figure out how to apply that to our bugtracker?
EDIT: I just found a related report, which says itās fixed in 1.2.0rc2. So I guess when we make the upgrade itāll be fine. Perhaps not before the next dev. release, but if you have some time before 0.8, maybe we can upgrade Mantis to 1.2.0rc2. What do you think?
Mantis has been finally upgraded to 1.2.0 stable release. Hopefully it will fix several issues discussed here. Sorry for the delay.
EDIT:
Iāve also added SVN integration plugin.
It seems to have made a little to much associations (some old bugs numbers messed with recent ones) but may be a useful addition for future
EDIT2:
Giving it second thought, it seems be making too much mess. Iāll remove it.
At the moment there are 128 bugs marked as resolved, which looks pretty messy. Some months ago Zamolxis used to deal with them, but I see heās busy. How many testers have rights to close resolved issues?
You know, you can change the Hide Status filter to Resolved and it will look as if all the resolved ones are closed.
But Iāll try to make some time soon and do some clean-out in Mantis. Last month I was either on holiday or very busy at work to complete things before the holiday. July will be more relaxed so I should have more time for VCMI.
I think that is should be possible to add notes even if issue is closed.
cause not every time it is needed to create new report, just should be possible to write that old issue should be opened i.e. #443 and #522
Second if you just want to add any note refers to exact issue i.e. #499. What does it mean āFixed in Version: 0.81ā? It isnāt fixed in 0,81. Maybe it will be in next release.
I believe youāre right about #499. I corrected it.
As for #443, you should have a āReopenā button available if you are the reporter. Let me know if you donāt - it may be a conflict between 2 Mantis configuration settings. If yes, I think I might have a solution, but first pls check if you donāt have a āReopenā below the Attached Files area.
Depends what you mean by āthinkā. Iād say use it if you have good reasons to believe itās the same bug (e.g.: if it follows the same reproducibility pattern and leads to the same/similar results, or is only half-way fixed).
[/size]
