I’ve updated the report.

Until we see if there’s a way to allow users to update their on report, you can always mention the changes you want to make in the comment notes and I’ll be happy to make the update.

It’s because we prefer to code rather than to test. Usually when we make a change we test most important features affected by this change - but it does not apply to big changes. For example, when we change processing of all spells on the server (ie. we add spell resistance) we don’t test all implemented spell to check if they still work but only a few. It leads to more bugs but makes development faster.

I’ll see if we can allow all users to edit their own reports.

EDIT:
We can only allow users to update all reports (not just their own). We could also grant everybody (except anobnymous users) editor proviliges. I don’t know which one is better.

With this release, a couple of overhauls were made in the code, with the GUI and animations I think. When you replace a part of a system with a new one you can count on a whole lot of bugs and missing features just like when the old one was first introduced. But typically these bugs are easier to fix because of prior experience and knowing the differences between the old and new system.

That is a bit risky/annoying. I guess we could give it a try, if there is request from the users, but if anyone abuses it, we change it back. I’ll let you & Tow decide on that. For me it’s fine either way.

@mantis
perhaps easier is to not allow editing “for all” - all to put in new comments
if diffrencies are to big we can delegate one person to track updating messed “issue threads”

I don’t think it matters if only administrators or programmers can update fields, because, for example, you may have done a wrong title and I think it’s quite acceptable for Zamolxis or another member of the team to edit the title (or other fields sometimes too).

Best regards,
Steven.

It looks that testers have found an incredible number of bugs, but there’s no one to fix them I wish we could keep the amount of resolved issues above 10%

Have no fear, the day of glory will come.

I and Tow have started new semester at our university so we have less time for VCMI. Additionally, Tow’s computer got broken and ubuntux made some changes that spoiled VCMI on Windows (it must be repaired before I start fixing bugs from mantis). Please be patient.

Sorry to hear about Tow’s computer. That can be quite annoying… Hope the hard drive wasn’t affected (I still remember the day my HDD crashed 2 weeks before my end thesis, with half of my research on it - that was the day I learned to back up important things more frequently:)

For the rest it’s okay to wait for the moment. VCMI is still pretty playable so we don’t “urgently” need a release.

Plese give developer status to Ubuntux.

@Warmonger

done

Would it be possible to give the testers access to builds not released as a new version? I mean something like daily builds except that they most probably wouldn’t be daily This way we could avoid duplicating issues (like reporting something that’s already fixed since last release).

You can always compile it yourself if you have the tools. Nightly builds could require some build automation. Personally I have some problems with Windows SxS, which won’t let me run the program on anything but my system. Linux users should be able to compile it themselves, there’s not a whole lot of dependencies anyhow.

To avoid reporting duplicate issues, the filter is very useful. You can just enter the term what it’s about like “artifact” and you will, at least at this point, only get a handful of reports that can easily be skimmed through if they cover your issue or not.

Or alternatively to Mantis’s filter, you can change the default view of the issue list (e.g.: change the Show filter on top from 50 to 500) to have all reports displayed on one page. And then use CTRL+F. So for reports like 200-202, a simple search with “wait”, “stack” & “sword” would have revealed that they were already previously reported.

For the rest, it’s not a matter of “giving access” to builds. I believe the coders compile the new code changes themselves. As for really creating a build ready to install for us testers, that’s a bit time consuming. That’s why it’s done only once (max. twice) a month: the bi-monthly official release, plus 1-2 development releases in between. This time there’s been an exceptional delay in the release of a new dev.version (which I agree it may be needed, considering that about 50 bugs were corrected since 0.74 came out), because Tow’s computer crashed last month, and he’s usually the one preparing these packages. Let’s have a bit more patience until he gets a new one and then I’m sure we’ll get a new release.

SPLIT:

[quote=“Tow”]

[size=84]The PC issue you had must have been quite a blow, which now probably makes December 1st a deadline pretty hard to meet for 0.75 (surely not with all the features you may have had in mind for it). However, just in case you are still considering it, here is what I could do from my part:

If you manage to prepare 0.73c with debug symbols and latest fixes (plus fix for #223) by Thursday, from Thursday evening till Sunday evening I have a free long week-end, which I could spend checking each and every of the bugs reported as fixed. Probably I’ll even have time to check all other items reported as implemented. And on the way I’m sure I’d spot any other major bugs still in there (I’m planning for 20-30h of thorough testing). If you and/or the other devs would be around to fix what can be still fixed, then we may be able to release a pretty bug-free 0.75 on December 1st. If we manage that, the testers may have a VCMI they could enjoy during the holidays and happy-hunt for minor bugs, and you may have a more relaxed time to work on the major features you have in mind for 0.8, without being “bugged” by crash reports and requests for dev. releases due to annoying bugs.

Of course, that may be just a hypothetic scenario, as I’m totally unaware of the time (and not only) resources that you may have these days. Otherwise, if there’s anything else I can help with, let me know… [/size]

For me it is really good idea. I will have 2 weeks free around Holidays which mainly I will have to spend with my family so I hope I have much time for testing.
But what I would like to mention do not try to finish the 075 at the end of November by force. I know that it is kind of habit that new release appears first day of the month but what’s wrong with if it appears i.e. 10th of December. IMO nothing. And I’m sure that it is better way to omit the appearance of old renewed bugs and multiplied new bugs.

Let the power be with you

I would like to see current version released at worst at 1st December, we can take it for bugfix release. We can wait with any major features for another month as in December I’m expecting the work to speed up. It’s rather irrelevant how the versions will be labeled as we won’t run out of numbers anyway.

By “at worst”, do you mean the latest, or the earliest?

But I agree. As we won’t run out of numbers anyway, I don’t think it matters much if 0.75 comes out without many new features or not. Though we had quite a few “feature” reports on Mantis which are resolved, so it’s not like we don’t have anything. Together with the bug fixes, there are 70 resolved items.

I’ll try to make next dev release within a day then.

Actually none of the features I planned is done. Generally I wasn’t planning 0.75, I hoped to move directly to 0.8 at the Jan/Feb 2010. However lack of time and technical issues shattered my plans.
Now we have done several minor features and a lot of fixes. We can release 0.75 on 1 Dec but I’m not sure if the progress we made is worth of dragging community attention. Alternatively it may be just next dev build, with the “big announcement” postponed until 0.8 (or whatever will be next) with more new features is ready.

Project seems well-organized if the new builds are issued on the first days of month
More seriously, there are always bugs to fix. Delaying release in order to fix them usually leads to very rare releases. Which are buggy anyway, because all things added/changed in that time haven’t been thoroughly tested by the release.
“Release early, release often” says the rule. I don’t know if current pacing of releases is “often” but they’re at least regular.

One more thing. Testing and bugfinding still remains the most important goal of the releases. If we were able to make a bug-free release, there would be no need for any (until the project is done).
New bugs and some recurring ones are the imminent part of releases in the current stage of project development.

There’s been a change in my schedule and I had to cancel my day off tomorrow (someone got sick and we have a project implementation). So I hope I didn’t make you rush too much with 0.74c for today, as I won’t be able to start the big testing before Saturday. The good news is that I got Monday free instead, so I still have 3 days free, which I’m mainly gonna spend on VCMI.

I kinda like the idea of having a 0.75 release. The number sounds like a milestone (75%).

But we can leave it up to you if we announce it or not, if Warmonger updates the threads opened at CH & HC or not, a.s.o. Perhaps we could wait with the decision until Monday. If I do manage to do what I planned, and it turns out 0.75 promises to be quite free of major bugs, maybe we can still have a small announcement. 'Cause if that’s the case, it’d be still better if people following links from other sites would find their way to 0.75, rather than 0.74.

Well, there’s truth in that. Theoretically there’s no difference in releasing a new build on the 1st or the 5th for example, in a 3 year long project. But somehow - subconsciously I guess - I can’t help a feeling of extra satisfaction if we manage to make it for the 1st.

Perhaps the project even ‘is’, not only ‘seems’ more organized like this. But regardless of that, it’s good in general for the PR if we uninterruptedly manage to stick to the ‘promise’ of bi-monthly releases, while in the same time remaining ourselves on the safe side by not making specific promises in advance.