0.74 bugs

I’ve added link to bug tracker to board navigation module of our portal.

How obout # xx (# [space] xx) :wink:

Have you considered making some sort of bug coordinator ? I mean someone who would go through newly reported bugs and then pass them to the right people, mark double, change severity etc? This way it would be easy to get rid of all ‘incorrect’ inputs or doubled issues. Because after a while there`s going to be a few hundred tickets and lets face it - practically noone will read through all of them to check for a doubled issue.

To manage bugs properly, one needs to have some knowledge of programming and project architecture. And all the devs are (or are supposed to be) busy with fixing them. I’d rather ask for someone else to move remaining 0.73c bugs instead of Tow Dragon, who is needed to push the project forward.
Luckily with Mantis managing all the bugs is clear and easy, so now it takes much less time than before.

What happened to the SF project feed? It hasn’t updated since revision 1258.

They are undergoing some maitenance to be able to ‘serve for another ten years’ :wink:

That would work as well, but it would just avoid that Mantis makes a link reference out of it, however it may still be confusing for the reader (e.g.: “is this the # 15 from Mantis, or from some forum thread?”). So IMO it’s more practical to keep the build reference in front of the log number if we refer to forum reports.

That would work if the VCMI Team would have the experience of having already worked on a couple of projects before, so that the “bug coordinator” would know what type of issues each and every of the programmers would be able to handle. Plus, this is an open source project, not a game developing company, where every programmer needs to justify his salary by handling a certain share of the issues. :slight_smile: Even if I knew that programmer X is the best to handle some sort of GUI bugs, I couldn’t just go and assign those to him; maybe for some reason he’ll be busy for the next few weeks, while others had more time for it. Most of us live in different countries, so we don’t meet “at the office” daily, to know each other’s schedule, we have new programmers joining the VCMI team every couple of months and the whole work is voluntary. So the best way to “coordinate” such a project, is still to let each programmer voluntarily pick the bugs they would like to handle.

As for the other “tasks” of the “bug coordinator” that you mentioned above, I am actually going through all the reports, correcting links, marking relationships, changing severities etc. I guess you noticed the modifications I made to report #12 from you for example (i.e.: split in 5, as it contained multiple bugs). I just didn’t manage to go through them all yet, because it just happens that I’m very busy in RL lately (job+painting/redecorating the house) and in the same time we had a huge wave of bugs being added, as TowDragon transfered almost all unresolved bugs reported in the past 6 months or so (great job btw!;). So the amount of reports will not continue to increase at the same rate as in the last couple of days and eventually I will catch up (plus in the meantime some of the devs would take care of many of the necessary corrections as they run into them - for example I noticed OnionKnight already made quite a number of changes:). So I think in 1-2 weeks (max.) we’ll be up-to-date with everything, and from then on it’ll be no problem checking only the new reports added from one day to another. :wink:

I would have been happy to do the whole work of transferring those bugs, but as said above, it’s just bad timing for me. My agenda is pretty much fully booked until October 19th, so I prefer to not make any promises for the near future (which is a bit frustrating, 'cause this is the kind of job I would love to do, as I am not a programmer to help otherwise:).

As Zamolxis wrote, assigning bugs to developers is not easy. Assigner must know who wrote which part of the engine and who knows different parts. I think we (devs) can handle assigning on our own. The other problem is correcting severities of bugs - it could be done by any tester as it should reflect personal opinion. Thanks for Zamolxis for correcting bug reports, I can focus on different things instead.

PS: I’m going to add BBCode plugin to Mantis and extend it to allow and tags - no more problem with screenshots if I succeed. What do you think about automatic changing enters to
(like on this forum)?

[quote=“Tow dragon”]
I’m going to add BBCode plugin to Mantis and extend it to allow and tags - no more problem with screenshots if I succeed.

That would be a nice addition.

I have a slightly related question here (regarding screenshots, but especially attachments): is the available webspace quite generous, or should we preferably use thumb links & archived attachments as much as possible?

I can’t think of any disadvantage of such change, so I’m all for it. :slight_smile:

The way it works now, it could be quite frustrating for new testers who don’t know about
. After writing a nice report, detailing with bullet points the bug behavior or steps to reproduce, it’s not nice to see that all your formatting has been lost.[/quote]

Use them as much as possible. Space is limited and constantly shrinking (but there is no danger still).

Exactly. There are also many issues that can be solved by more than one programmer. I won’t have anything against if someone will resolve “my” issue. And I reserve myself a right to fix “not mine” bugs. :slight_smile:

Ok, it’s good to hear then that you manage bug handling :slight_smile: From experience I know that you can get many bugs in one day and lots of duplicates - I just wanted to point that out :slight_smile:

EDIT:
How about assigning the bug to the reported if someone has a question or request for more info? When you’ll have, like 20 bugs reported you may not notice that someone requests some feedback from you and not fill some additional info. But if the bug with request would be assigned to the reporter then you would see it out right. Or maybe you have some other idea?

I’m not sure if as reporter you have the access to make this change, but try the following:

On Mantis, go to My Account - Manage Columns. There, under “View Issues Columns”, add “reporter_id,” among the other column names, then click “Update Columns for Current Project”. Let me know if it works.

It works but I don`t see how it helps?

Well, normally bugs should be assigned to a programmer, so assigning them back to the reporter would be strange (not to mention the bugtracker doesn’t technically allow assigning to “reporter” profiles).

The purpose of my suggestion was only meant to make it easier to check if any of your reports contains a feedback request:

  • Click on “Reporter” column header to have all your reports grouped together
  • Then check for which of them the date in the “Updated” column is bolded - you’ll only need to check those to see if the update is a feedback request

So it shouldn’t take more than 1min to check if someone has perhaps requested feedback on one of your reports.

@BBCode support in Mantis

I tried to install appropriate plugins but it’s more difficult than I previously thought. Instruction doesn’t contain info about which files must be writable by installation script (by default none is) and that lack of privileges spoiled something. It seems that I’d have to spend many hours to make it work so I’m not going to do it soon.

It’s ok. I don’t think they are a necessity, more just a “nice to have”. As long as we have clickable links, it should be enough for reporting bugs. :wink:

With
working, I’m suspecting other tags like , , and might work.

Yes, I agree that it is best to sort by version. However like Zamolxis suggests, rather than SoD maps first, instead using chronological order of map versions - so RoE maps first, AB maps next, then SoD maps, WoG maps and eventually VCMI maps, if certain mod capabilities get integrated into an updated H3 VCMI editor. :slight_smile:

Best regards,
Steven.

@OnionKnight
and what with ? :wink:
@Steven Aus
I think most players prefer reverse sorting (newest “version” first)

Maybe we could do a poll? Although it can’t be completely unbiased, as the earlier choices are more likely to be chosen all else being equal, so I guess it would be a fair as can be to have the choices in alphabetical order. The choices could be:

Sorted by:
“map name, alphabetical order”
“map version with newest version first (alphabetical within versions)”
“map version with oldest version first (alphabetical within versions)”

Are there any other choices that would be good to include?

I think it would still be good to have an option in VCMI for players to select their default sorting.

Best regards,
Steven.

FYI - 0.73c bugs up to #19 have been logged as well to Mantis. I’ve been a bit slowed down in the process because I was checking their reproducibility in 0.74 and discovered new bugs in the process.

However due to the problem reported here I cannot go on for today. Well, I could, but it’s a bit annoying not to have all reports visible, to run a search and check for duplicates / related items before I report anew. Hopefully by tomorrow the problem can be fixed, otherwise I’ll continue to log the other 0.73c bugs as it is.

Hi gatto,

I’d like to add your bug to the Mantis bugtracker (or you can log it yourself if you prefer). But can you please clarify one detail: by “spelled twice turn per one”, do you mean you were able to cast it twice in one turn or sth else? Also, is it reproducible?