[Scummvm-devel] ScummVM 1.1.0 has been tagged

[Travis Howell]

On 1/04/2010 7:33 PM, Max Horn wrote:
> Am 01.04.2010 um 05:20 schrieb Travis Howell:
>> Why did ScummVM 1.1.0 get tagged, when we still have regressions? bugs
>> #2961787, #2976353 for example. It is still not clear how many of the
>> Nippon Safe bugs are regressions either, due to that recent load/save issue.
>
> It was made clear by Peres the he cannot work on these bugs. And nobody else offered to work on them. So there seems to be no point in waiting for a magic resolution of these. OK, we can delay 1.1.0 -- by weeks? Months? And then we release a ScummVM which lags by that amount behind the ScummVM trunk.

Yes, that was mentioned during the previous release cycle (for ScummVM 
1.0.0). But I didn't see any response at all, to your recent query about 
Parallaction engine to Peres, unless it was not CCed to the mailing 
list. Nor did I see any actual request for other people to handle Nippon 
Safe regressions, or the Parallaction engine in the meantime.

If Nippon can't be worked on for 'x' amount of time, then why even make 
a release in the meantime? since bugs in Nippon Safes were an issue for 
the last release cycle too. With a few of the more recent bug reports 
for Nippon Safes, occurring under ScummVM 1.0.0 too.

> It's a trade off. I think it's better to get regular releases out, not just for commercial products, but especially also for open source products. You disagree. Fine.
>
> Tell you what, you can act as the release manager for the next release! How about that? I am completely serious. It might mean we won't get another release before 2011 or 2012, but I don't mind, as long as nobody is going to blame *me* for it :-).

I would like to, but my real life situation (which I would rather not 
detail) means my reliability isn't that good any more.

>> The new tools still lack more thorough public testing, it seems we
>> failed to ask for more testing in this case. Should we risk releasing
>> new tools which aren't as well tested? or maybe wait longer for more
>> public testing and handle separately this time?
>
> Yes, we should risk it, because waiting won't solve any problems. Only *working* will solve them. Nobody is working on this, as far as I can tell. Nobody is working on organizing this public testing. As with the release management, I cordially invite you to do this for the next time around, Eugene (who currently has -1 time for ScummVM) and me (who currently has 0.1 time for ScummVM) would most definitely glad for help with that. Just because we are project admins doesn't automatically mean that we must do all the annoying, tiresome, boring work alone, right? :-).

Well there is a tools status page on the wiki ( 
http://wiki.scummvm.org/index.php/GSoC_Tools_status ) at least, which 
could be mirrored or used in the future.

Another option would be to simply exclude the GUI tool for now, due to 
the lack of testing, and still not been quite complete. As the older GUI 
tool was excluded, from previous releases of the tools.

> So, as with NIPPON, just waiting won't solve anything. By making a release, at least we will get a wider public testing.

I would argue that releasing new tools that aren't as well tested, could 
be an extremely bad idea. As we could end up with users been unable to 
compress sound files (for smaller devices), or users ending up with 
unusable files (in the worse cases).

>> We are not a commercial product, and don't have any reasons that a major
>> release must be produced by a specific date. So I really don't see why
>> major releases are pushed through, when they are good reasons
>> (regressions in this case) for delays.
>
> See above. I don't think commercial vs. non-commercial has any relevance here.

No, you still have not answered why a major release must be made at this 
point in time. Only stated why you don't think it worth waiting.

>> With ScummVM been used more often for games releases (i.e. on Good Old
>> Games), I think it is even more important to avoid any regressions in
>> stable games. If we keep letting known regressions in stable games
>> through, than it seems more like ScummVM is going backwards. Which is
>> only going to cause problems for users who specifically stick to major
>> releases, to avoid regressions and more stability.
>
> I always prefer to avoid regressions, if I see any chance for that. In this case, I don't. Hence my decision not to wait for this. The regressions will be clearly mentioned in the release announcement, telling any NIPPON players to wait for 1.1.1. This seems like an acceptable tradeoff to me.

Basically my main point is, what is the purpose of a major release? I 
thought it was to offer users a more stable build, with more bugs fixed 
and additional features added. But users are able to try out newer 
features via our regular snapshots now, which only leaves less bugs and 
more stability. And if we continue to let regressions through, then 
there seems to be no purpose at all.

On 1/04/2010 10:36 PM, Max Horn wrote:
> P.S.: Oh, and one more thing. I just looked at our IRC logs and saw this:
>
> <... ongoing discussion about 1.1.0 release ...>
>
>Let me set this straight: I didn't ignore nobody, I simply didn't
>*see* Kirben's comment. Kirben, if you had *addressed* me, i.e. used
>my nick, my IRC client would have highlighted it, and I would have
>responded; but as it was, the comment simply got lost in a flood of
>other things. Plus it was almost 3 AM, and I was already half asleep.
>IRC is a lossy media, you sometimes need to shout to be heard. There
>is a reason why I always preach that important stuff shouldn't be
>discussed via IRC alone.
>So I am sorry that you felt ignored, but you weren't deliberately
>ignored.

OK, that is why I followed up with the email to devel about the situation.

> By the way, *I* felt pissed that we are having this very discussion
>again, and that you waited till *after* all the tagging work was done
>to complain, instead of voicing your concerns, say, 2 days ago...

Yes, I incorrectly assumed the release manager was still monitoring 
recent update to the bug reports, and wouldn't tag while there were 
still known regressions.