I agree with Chris. The current state of our 1.12 beta releases has not been what a user would expect from a beta release. Serious game breaking bugs shouldn't be present. IMO we should devote more time to testing *before* releases, not after. Our users should not be the ones who discover game-breaking bugs.
On Fri, May 30, 2014 at 9:13 PM, chris beck <beck...@gmail.com> wrote: > > If you keep changing things like WML we will stay in beta time until > middle of > > next year... Please focus on fixing bugs in branches/1.12 so that we can > > release the new series soon. > > This is a good point but I think its only a small part of the story. There > have been just > as many problems with the GUI interface, with far more impact, than the > WML changes. > > The real reason we are still in beta, IMO, is that there were huge changes > to the project > since the 1.10 release in many different departments, and little to no > testing of the combined > result until maybe December of this year. Beta 1 of 1.11.x was really > closer to an alpha -- basic > functionality was simply untested and missing, after major refactors had > taken place, and just > clicking around for a few minutes would reveal many bugs. Even after > months in beta we still > have struggled to get master into the "near-release" state demanded by > beta. > > I think that when we we begin 1.13 beta, we should only do so after > thorough internal testing, > especially which ensures that the user interface is stable. If we make > beta releases which are > unusable because the users cannot click on units and similar issues (which > have been a recurring > theme!)... we will poison the well and be unable to get the testing > assistance that we rely upon. > > It seems that right now, the timing of releases has mostly to do with, > what is written in the > changelogs, how long has it been since the last release, what are people's > schedules like... > and little to do with, what bugs are listed on the bug tracker, who has > tested them recently, > what are the results of independent testing of various areas of the > project. It shouldn't be > surprising then if the quality of releases is highly random and the target > deadlines become hazy. > If we are unwilling to commit to this kind of testing then IMO we should > resign ourselves to the > idea that, we will discover whatever bugs there are only whenever the > person responsible finds > them, and we will fix them whenever we get around to it. > > Especially, we should try never to have a repeat of 1.11.14, where we tag > a release without > doing basic sanity checks. Releases should go hand in hand with testing > and review, otherwise > they signify bureaucracy rather than progress. > > For example, one practice that we have right now is after tagging a > release, we review the bugs > on the bug tracker listed as "fixed" and "ready for test" and determine > their status, closing as > appropriate, so that we update our status almost in full just after any > release. Maybe this process > should happen *before* the targetted release date, so that the decision to > actually make a release > can be informed by the outcome. > > Best Regards, > Chris Beck > > > On Thu, May 29, 2014 at 10:13 AM, Nils Kneuper <crazy-ivano...@gmx.net> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi folks! >> >> I just wanted to remind you that branches/1.12 is under feature freeze. >> So you >> should not commit anything breaking the compatibility of WML unless there >> is >> absolutely no other way to fix an important bug. And when that is the >> case you >> should always link a bugtracker report to show this requirement. Shadowm >> pointed out that in the last two release announcements changes in WML had >> to >> be mentioned which should no longer happen since we are in feature freeze. >> >> If you keep changing things like WML we will stay in beta time until >> middle of >> next year... Please focus on fixing bugs in branches/1.12 so that we can >> release the new series soon. >> >> Cheers, >> Nils Kneuper >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> >> iEYEARECAAYFAlOHQHQACgkQfFda9thizwXbgQCgm1qmXtDYvx4VVM48Sk+mH6WP >> ErUAoKJrzQCsNYTWzIF2qYTiidEny0ie >> =MA2S >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Wesnoth-dev mailing list >> Wesnoth-dev@gna.org >> https://mail.gna.org/listinfo/wesnoth-dev >> > > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev > >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
