Thread: [Widelands-public] Build16 time plan
Status: Beta
Brought to you by:
sirver
From: Peter S. <sea...@gm...> - 2011-02-06 13:02:25
|
Hi @ all :), I recently wondered what we really want Build16 to be. Actually it is not the 1.0 release, but just another milestone. So how about a decision for the date of branching Build16? Of course some stuff tagged for Build16 is still not implemented, but if we keep on waiting and adding new bugs and features for build16-rc1, we will never release Build16 until Widelands is finished ;). Okay, let's be serious ;) - We should add a definite date for branching Build16 and therefor for the feature freeze - everything not implemented until than, will be implemented in the next release. We do not loose anything, but just bring all the cool new graphics, features, sounds, texts, translations, scenarios, the build system (damn I surely forget something here and make someone angry ;) ) to our players (and no, development builds are no excuse - I read much to often, that people fear development builds, just because they are named that way.). So? Anything speaking against the 1st of April for branching and feature freezing Build16? Cheers Peter |
From: Holger R. <Hol...@gm...> - 2011-02-07 09:39:54
|
Hi, > > I recently wondered what we really want Build16 to be. > Actually it is not the 1.0 release, but just another milestone. > > So how about a decision for the date of branching Build16? Of course > some stuff tagged for Build16 is still not implemented, but if we keep > on waiting and adding new bugs and features for build16-rc1, we will > never release Build16 until Widelands is finished ;). :) I am quite serious about your targeted bug list. Actually, I was expecting to see more headway with it, it's just that real life leaves little time for widelands atm. > > Okay, let's be serious ;) - We should add a definite date for branching > Build16 and therefor for the feature freeze - everything not implemented > until than, will be implemented in the next release. I'd rather slim the targeted bugs down. Build 15 was released in pretty much that fashion and I think it contains more bugs that were not really necessary. I'd like to have build 16 more polished in this regard. > We do not loose anything, but just bring all the cool new graphics, > features, sounds, texts, translations, scenarios, the build system (damn > I surely forget something here and make someone angry ;) ) to our > players (and no, development builds are no excuse - I read much to > often, that people fear development builds, just because they are named > that way.). > > So? > Anything speaking against the 1st of April for branching and feature > freezing Build16? > Following the release cycle [1] this would be First-Snow feature freeze. We could do this right now: only targeted bugs and features could be targeted from then on. We can then set a deadline for the begin of step 2 on 1. April so that we are not lost in time again. [1] http://wl.widelands.org/wiki/ReleasingWidelands/ What do others think? Sounds like a plan? Cheers, Holger |
From: Foppe B. <fop...@gm...> - 2011-02-07 10:55:11
|
2011/2/7 Holger Rapp <Hol...@gm...> > > What do others think? Sounds like a plan? > It sounds like a great plan, but maybe it misses a extensive testing part: a tournament or a play day? Widelands build 16 is going to be a great step forward for the project! ;-) > Cheers, > Holger > > -- Met vriendelijke groet, Foppe Benedictus |
From: Peter S. <sea...@gm...> - 2011-02-07 17:06:42
|
Holger Rapp wrote: > > Okay, let's be serious ;) - We should add a definite date for branching > > Build16 and therefor for the feature freeze - everything not implemented > > until than, will be implemented in the next release. > I'd rather slim the targeted bugs down. Build 15 was released in pretty much > that fashion and I think it contains more bugs that were not really necessary. > I'd like to have build 16 more polished in this regard. Of course! My request was more about new features and new wishlist stuff. However some bugs are rare and hard to catch like the "savegame does not contain pictures" bug, which is not reproducible for me, although I faced it two times since build9half as well - it is long known and it would be VERY COOL to have it fixed! However we should not see it a blocker bug, as it simply does not occur that often and even if it occurs, it does not break savegames. > > We do not loose anything, but just bring all the cool new graphics, > > features, sounds, texts, translations, scenarios, the build system (damn > > I surely forget something here and make someone angry ;) ) to our > > players (and no, development builds are no excuse - I read much to > > often, that people fear development builds, just because they are named > > that way.). > > > So? > > Anything speaking against the 1st of April for branching and feature > > freezing Build16? > > > Following the release cycle [1] this would be First-Snow feature freeze. We could do this right now: only targeted bugs and features could be targeted from then on. We can> then set a deadline for the begin of step 2 on 1. April so that we are not lost in time again. > > [1] http://wl.widelands.org/wiki/ReleasingWidelands/ Yeah :)! However in "First snow feature freeze" campaigns are listed as "may not be changed anymore", so adding the second atlantean campaign map would be disallowed, right? However there is a bug report about adding atl02.wmf, so how to handle this? Foppe Benedictus wrote: > > 2011/2/7 Holger Rapp <Hol...@gm... <mailto:Hol...@gm...>> > > > What do others think? Sounds like a plan? > > It sounds like a great plan, but maybe it misses a extensive testing > part: a tournament or a play day? > Widelands build 16 is going to be a great step forward for the project! Fully agreed :)! Cheers Peter |
From: Holger R. <Hol...@gm...> - 2011-02-08 09:40:00
|
>> >> > Okay, let's be serious ;) - We should add a definite date for branching >> > Build16 and therefor for the feature freeze - everything not implemented >> > until than, will be implemented in the next release. > > I'd rather slim the targeted bugs down. Build 15 was released in pretty much > > that fashion and I think it contains more bugs that were not really necessary. > > I'd like to have build 16 more polished in this regard. > > Of course! My request was more about new features and new wishlist stuff. However some bugs are rare and hard to catch like the "savegame does not contain pictures" bug, which is not reproducible for me, although I faced it two times since build9half as well - it is long known and it would be VERY COOL to have it fixed! However we should not see it a blocker bug, as it simply does not occur that often and even if it occurs, it does not break savegames. I agree. We can reschedule such issues. > his would be First-Snow feature freeze. We could do this right now: only targeted bugs and features could be targeted from then on. We can > then set a deadline for the begin of step 2 on 1. April so that we are not lost in time again. > > > > [1] http://wl.widelands.org/wiki/ReleasingWidelands/ > > Yeah :)! However in "First snow feature freeze" campaigns are listed as "may not be changed anymore", so adding the second atlantean campaign map would be disallowed, right? However there is a bug report about adding atl02.wmf, so how to handle this? Reschedule the bug report then. Freeze is Freeze. We only add the two multiplayer scenarios and be done with. Holger |
From: Peter S. <sea...@gm...> - 2011-02-08 22:54:08
|
Okay, I rescheduled the atl02.wmf bug to build17-rc1 What about the following three bugs: * Replace InnoSetup script with CPack functionality * Build static binary * Heal soldiers in warehouses and training sites I think the first should really be retargetted, as the current InnoSetup script works just fine and a move should not be done shortly before a new release. For the second, I remember, that Timowi was quite far and even built some mostly static binaries. For the official downloadable linux version this would of course be a great improvement, but it shouldn't be a blocker either, should it? The last one is a bug that can be quite annoying, however fixing it properly seems to be a lot of work - Raúl fixed this (at least for the headquarters) in his lua_hq branch, through the garrission feature, however his branch still needs some more work until it is mergeable... Cheers Peter |
From: Nicolai H. <pre...@gm...> - 2011-02-16 09:45:02
|
Sorry I'm late to this discussion, I only returned from travelling last night. On Monday 07 February 2011 10:39:47 Holger Rapp wrote: > Following the release cycle [1] this would be First-Snow feature freeze. We > could do this right now: only targeted bugs and features could be targeted > from then on. We can then set a deadline for the begin of step 2 on 1. > April so that we are not lost in time again. > > [1] http://wl.widelands.org/wiki/ReleasingWidelands/ > > What do others think? Sounds like a plan? I would definitely like to see build-16 out of the door soon. If the First- Snow Feature Freeze is in place, then the remaining differences in OpenGL rendering cannot be fixed for build-16 (notably: fixing the no pictures in scenario messages bug *is* invasive), and if you were to set the date on next Monday, I promise I will fix this rendering problemthis weekend (that was my original plan). What do you say? Other than that, I think starting with freezing is a good idea. I think we should at least try to get to Winter-Time feature freeze before 1.4.; the list of targetted bugs isn't *that* long (though to be honest I'm already seeing a bug that I'd rather move to addressing shortly after build-16). In order to get the most stable build-16 possible, I think we should schedule semi-official multiplayer games on the weekend again from now until the release date. cu, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte. |
From: Holger R. <Hol...@gm...> - 2011-02-09 08:04:27
|
> > > What about the following three bugs: > * Replace InnoSetup script with CPack functionality > * Build static binary > * Heal soldiers in warehouses and training sites > > I think the first should really be retargetted, as the current InnoSetup > script works just fine and a move should not be done shortly before a > new release. > For the second, I remember, that Timowi was quite far and even built > some mostly static binaries. For the official downloadable linux version > this would of course be a great improvement, but it shouldn't be a > blocker either, should it? > The last one is a bug that can be quite annoying, however fixing it > properly seems to be a lot of work - Raúl fixed this (at least for the > headquarters) in his lua_hq branch, through the garrission feature, > however his branch still needs some more work until it is mergeable... I agree with your analysis in all points. I suggest to continue the discussion of individual bugs on the bug tracker though because the relevant people do read the bug tracker; I am not so sure who is reading this mailinglist anymore. Holger |
From: Victor P. <vic...@gm...> - 2011-02-09 08:20:38
|
i certainly am reading the mailing list. work and a new house prevents me from doing much on widelands atm but it is certainly interesting to follow the progress. then again, maybe move the list from sourceforge to launchpad? regards Victor Pelt On Wed, Feb 9, 2011 at 9:04 AM, Holger Rapp <Hol...@gm...> wrote: > > > > > > What about the following three bugs: > > * Replace InnoSetup script with CPack functionality > > * Build static binary > > * Heal soldiers in warehouses and training sites > > > > I think the first should really be retargetted, as the current InnoSetup > > script works just fine and a move should not be done shortly before a > > new release. > > For the second, I remember, that Timowi was quite far and even built > > some mostly static binaries. For the official downloadable linux version > > this would of course be a great improvement, but it shouldn't be a > > blocker either, should it? > > The last one is a bug that can be quite annoying, however fixing it > > properly seems to be a lot of work - Raúl fixed this (at least for the > > headquarters) in his lua_hq branch, through the garrission feature, > > however his branch still needs some more work until it is mergeable... > I agree with your analysis in all points. I suggest to continue the > discussion of individual bugs on the bug tracker though because the relevant > people do read the bug tracker; I am not so sure who is reading this > mailinglist anymore. > > Holger > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Widelands-public mailing list > Wid...@li... > https://lists.sourceforge.net/lists/listinfo/widelands-public > |
From: Holger R. <Hol...@gm...> - 2011-02-16 11:59:06
|
Hi, > > On Monday 07 February 2011 10:39:47 Holger Rapp wrote: >> Following the release cycle [1] this would be First-Snow feature freeze. We >> could do this right now: only targeted bugs and features could be targeted >> from then on. We can then set a deadline for the begin of step 2 on 1. >> April so that we are not lost in time again. >> >> [1] http://wl.widelands.org/wiki/ReleasingWidelands/ >> >> What do others think? Sounds like a plan? > > I would definitely like to see build-16 out of the door soon. If the First- > Snow Feature Freeze is in place, then the remaining differences in OpenGL > rendering cannot be fixed for build-16 (notably: fixing the no pictures in > scenario messages bug *is* invasive), and if you were to set the date on next > Monday, I promise I will fix this rendering problemthis weekend (that was my > original plan). What do you say? I can live with that. This gives me some time to work on #673734 which is strictly speaking a feature. My suggestion is to give this weekend for a hacking marathon (I'll be in IRC at least saturday, maybe sunday) and than do first snow feature freeze on monday. We should then aim for ~2 weeks for winter-time feature freeze and then another 2 weeks for the first release candidate. > In order to get the most stable build-16 possible, I think we should schedule > semi-official multiplayer games on the weekend again from now until the > release date. I agree to this. The packagers will have to get in gear, we should announce trunk revisions every thursday and the packagers should make a test package available. If no one complains, I will announce the dates and the procedure on the homepage on the weekend. There is a slight problem with this: I am on vacations starting February 15th for 2 weeks. So most of this maintenance stuff (posting on homepage and watching the bug tracker) must be done by someone else in the meantime. Who can do this? Holger |
From: Peter S. <sea...@gm...> - 2011-02-16 19:57:16
|
Am 16.02.2011 12:58, schrieb Holger Rapp: >> In order to get the most stable build-16 possible, I think we should schedule >> semi-official multiplayer games on the weekend again from now until the >> release date. > I agree to this. The packagers will have to get in gear, we should announce trunk revisions every thursday and the packagers should make a test package available. If no one complains, I will announce the dates and the procedure on the homepage on the weekend. > > There is a slight problem with this: I am on vacations starting February 15th for 2 weeks. So most of this maintenance stuff (posting on homepage and watching the bug tracker) must be done by someone else in the meantime. Who can do this? Are you sure about the dates? It is already 16th of February... I am busy with some exams at the moment, however if nobody had time for that job, I would try to. A helping hand would be cool anyways :). Cheers Peter |
From: Holger R. <Hol...@gm...> - 2011-02-17 09:24:29
|
> > Am 16.02.2011 12:58, schrieb Holger Rapp: >>> In order to get the most stable build-16 possible, I think we should schedule >>> semi-official multiplayer games on the weekend again from now until the >>> release date. >> I agree to this. The packagers will have to get in gear, we should announce trunk revisions every thursday and the packagers should make a test package available. If no one complains, I will announce the dates and the procedure on the homepage on the weekend. >> >> There is a slight problem with this: I am on vacations starting February 15th for 2 weeks. So most of this maintenance stuff (posting on homepage and watching the bug tracker) must be done by someone else in the meantime. Who can do this? > Are you sure about the dates? It is already 16th of February... > I am busy with some exams at the moment, however if nobody had time for > that job, I would try to. A helping hand would be cool anyways :). Indeed, I meant the 26th February - 13th March. I'll be on Tenerife and work on my Tan. Sorry for the confusion :). Cheers, Holger |
From: Nicolai H. <pre...@gm...> - 2011-02-20 16:50:26
|
On Wednesday 16 February 2011 20:56:53 Peter Schwanemann wrote: > Am 16.02.2011 12:58, schrieb Holger Rapp: > >> In order to get the most stable build-16 possible, I think we should > >> schedule semi-official multiplayer games on the weekend again from now > >> until the release date. > > > > I agree to this. The packagers will have to get in gear, we should > > announce trunk revisions every thursday and the packagers should make a > > test package available. If no one complains, I will announce the dates > > and the procedure on the homepage on the weekend. > > > > There is a slight problem with this: I am on vacations starting February > > 15th for 2 weeks. So most of this maintenance stuff (posting on homepage > > and watching the bug tracker) must be done by someone else in the > > meantime. Who can do this? > > Are you sure about the dates? It is already 16th of February... > I am busy with some exams at the moment, however if nobody had time for > that job, I would try to. A helping hand would be cool anyways :). I can help with posting things on the website of course. I've added all the big stuff I wanted to do, so the rest is going over the list of bugs targetted for build16-rc1, and perhaps bugs in general? I assume that until the "full freeze", any bug fixes are welcome, and after the "full freeze", only catastrophic bug fixes are allowed, did I understand that correctly? cu, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte. |
From: Peter S. <sea...@gm...> - 2011-02-20 22:24:59
Attachments:
auslastung.png
|
Am 20.02.2011 17:50, schrieb Nicolai Hähnle: > I can help with posting things on the website of course. I've added all the > big stuff I wanted to do, so the rest is going over the list of bugs targetted > for build16-rc1, and perhaps bugs in general? I just tested your changes and am really impressed! The only left thing that I still miss in OpenGL mode are the smooth terrain changes. All other issues are fixed! Very good work! :) I for myself have to beg your all pardon. I know a feature like the dedicated server should have been discussed / blueprinted before being implemented, but as I found the time and hoped to get it ready for Build16, I just started coding... *shame on me* However to defend my work :) : The current state of the "dedicated" modus is: * Server starts up and opens a game with the map set via "--dedicated=<map>" * Clients can set up the server via chat commands and can start the game * Once started, the game runs until the last player left. Afterwards, the dedicated server closes the game, reconnects to the metaserver and reopens a new game... Attached is a screenshot of the kde process monitoring tool. "Speicher" means "Used RAM". The Widelands process run by "nasenbaer" is the client (SDL mode), while the widelands process started by "mronki" is the dedicated server. In this case I used a saved game from a random (128x160) map with 7 players (5 computer players) that was saved after ~2 hours of game. My system: Dual Core 2GHz. So to conclude: The Widelands client uses around 64% of one core and 432MB RAM, while the server uses only 20 % of one core and 17 MB RAM, although all computer players are only calculated on the server. Looks for me, like the server could be run even on a 800 MHz computer without flaws. :) I hope you forgive my solo effort and pledge amendment! :) > I assume that until the "full freeze", any bug fixes are welcome, and after > the "full freeze", only catastrophic bug fixes are allowed, did I understand > that correctly? I would agree with this statement. From my side: The freeze can come! :) Cheers Peter |
From: Nicolai H. <pre...@gm...> - 2011-02-21 10:56:55
|
On Sunday 20 February 2011 23:24:34 Peter Schwanemann wrote: > Am 20.02.2011 17:50, schrieb Nicolai Hähnle: > > I can help with posting things on the website of course. I've added all > > the big stuff I wanted to do, so the rest is going over the list of bugs > > targetted for build16-rc1, and perhaps bugs in general? > > I just tested your changes and am really impressed! The only left thing > that I still miss in OpenGL mode are the smooth terrain changes. All > other issues are fixed! Very good work! :) Thank you :) Besides the smooth terrain, there is a bug remaining that concerns road rendering (bug #594686), but those things will have to wait until build-17. > I for myself have to beg your all pardon. I know a feature like the > dedicated server should have been discussed / blueprinted before being > implemented, but as I found the time and hoped to get it ready for > Build16, I just started coding... *shame on me* I know how that feels ;) Your changes look more or less unintrusive to me, so it's all good. I'm still sceptical whether that feature is very useful, but at least it'll shut up all those regular questions about it. cu, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte. |
From: Holger R. <Hol...@gm...> - 2011-02-21 12:05:29
|
Hi everybody, > > I can help with posting things on the website of course. I've added all the > big stuff I wanted to do, so the rest is going over the list of bugs targetted > for build16-rc1, and perhaps bugs in general? > > I assume that until the "full freeze", any bug fixes are welcome, and after > the "full freeze", only catastrophic bug fixes are allowed, did I understand > that correctly? The freeze will start tomorrow morning; there is a merge about datadirs that I want to have reviewed as it seems to make sense to have it in build 16. My interpretation of this feature freeze is as you put it, nicolai. The complete ruleset is listed in the Wiki and on the news post I send in. Basically, only translations and media changes (pictures, sound, music) + bug fixes are welcome now. All feature development should happen in branches. We will also concentrate on fixing the remaining open bugs for build 16rc1. As soon as they are all closed or retargeted, we will give the translators some 2 weeks time, then push out the first release candidate. Oh and btw: Congratulations to the great coding sprint by various people on the weekend! I am sorry that I couldn't contribute my share this time, but we had a bachelors party on friday which left me pretty much dead on saturday :(. As mentioned, I am away starting on friday night, but will stay reachable till then. I also try to contribute some bug fixes till then. Cheers and I drink on build 16, the best widelands version so far! Holger |