[Scummvm-devel] Idea: ScummVM weekly snapshots

Thierry Crozat criezy at scummvm.org
Sun Jul 24 23:53:26 CEST 2016


Hi Lothar,

I am not convince this is a good idea, mostly because of the delay this introduce after fixing a bug to have it included in a snapshot. My feeling (but I might be wrong) is that most users don't have the knowledge or tools to compile ScummVM themselves, and when there is a need for iteration between the developer and bug reporter, a one week delay can significantly slow down the bug resolution.

On your specific points, there may be some value in a), although we could also possibly improve the wording of announcement without switching to weekly snapshots.
I am even less convinced about b). After a regression has ben introduced it will be present in all the daily builds. So I am not sure why it would be less likely to find it in those builds than if we were making weekly snapshots.
Regarding c), the GAMESDB could be improve in that regard, but that does not necessarily require switching to weekly snapshots. Similarly, for c2 we could have more frequent news about recent addition or changes to ScummVM anyway, and not necessarily on a weekly bases (that would depend on the number and importances of changes - sometimes nothing happens in a week and some other weeks there is a flurry of commits). I am wondering however if an announcement would be the best medium for this. Maybe a blog, Twitter or Facebook would be more adapted?

Thierry

On 14 Jul 2016, at 19:49, Lothar Serra Mari <lserramari at gmail.com> wrote:

> Hello my dear adventurers!
> 
> A few weeks ago, I had the idea to replace (or extend) the current
> nightly/daily builds of ScummVM with weekly snapshot versions.
> 
> The idea is to create a snapshot build once a week and name it after
> the current calendar week, so this week's snapshot would be named
> "ScummVM 1.9.0_16w28". This is the way Minecraft testing works btw. :)
> 
> Basically, I see three benefits in the weekly snapshots:
> 
> a) Announcements are more precise: Currently, when a new engines is in
> it's final stage of development, we usuall announce it with something
> like "playable in the latest daily builds". This could lead to
> confusion for inexperienced users, because it is not *exactly* clear
> which is the latest version at the time of writing. Writing "playable
> with the upcoming ScummVM Snapshot 1.9.0_16w29 and newer" would solve
> this.
> 
> b) Larger user base for game tests: When a new game, port or
> significant change is announced, people will start testing it using
> different daily versions because they won't start testing all at the
> same time, therefore I assume that weekly instead of daily builds will
> increase the user base for a specific release and thus increase the
> chance of finding regressions.
> 
> c) Easier integration into the upcoming GAMESDB. We could simply add
> each snapshot as a target in the GAMESDB and don't have to use
> "tricks" like selecting 1.8.1 and then inserting the commit hash in
> the comments.
> 
> c2) We could make a small announcement of the changes of the past week
> on the website. Nothing special, but something I'd like to write ;)
> 
> On the downside, changes made during a week won't receive much testing
> until the release of the next snapshot. This might be not too bad,
> because the more experienced users still can compile the latest code.
> 
> I have no idea how easy it is to implement those weekly snapshots
> using our current buildbot setup - do we need to do a branch each week
> or is there a possibility to simply schedule a build on a specific
> time and give this release it's own version string?
> 
> Please let me know what you think of this idea. Don't hesitate to call
> it "stupid and utter nonsense". :)
> 
> With best regards
> Lothar/rootfather
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel





More information about the Scummvm-devel mailing list