FreeOrion

Forums for the FreeOrion project
It is currently Sat Dec 16, 2017 10:17 pm

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: 0.4.8 roadmap
PostPosted: Sun Oct 29, 2017 6:32 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4303
Location: Sol III
I think it's time to start planning for the 0.4.8 release. Which means we should start to determine what needs to go into/is mandatory for that release, and what can wait for later. The original intention has been to get 0.4.8 done by the end of the year, to (probably) no one's surprise it will take us a bit longer (most likely).

So I've split up the "v0.4.8" milestone into three:

  • "v0.4.8 (mandatory)": for issues/PRs that absolutely need to be fixed/finalized, and are therefore release-blocking.
  • "v0.4.8 (optional)": for issues/PRs that can or mayby should go in, but are not absolutely needed, and therefore do not block the release.
  • "post v0.4.8": for issues/PRs that should be postponed until after the release, these are issues/PRs that would take too much time and effort and would delay the release too much.

I've done a first pass and went over all the open issues and PRs, and and tried to assign them to one of these milestones as best as I could. As your assessment might be different, please, everyone, take a look at these milestones and the issues/PRs assigned to them and post your feedback here. If you think an issue/PR should be reassigned, make a proposal and state your reasons, so we can discuss it.

As you can see, I've considered only a few issues/PRs as mandatory, consequently it looks like 0.4.8 is almost done (97%). This of course is misleading, because there are actually two major items which will take quite some time and effort to fix/complete: the major feature of this release, the Imperial Stockpile, and the logging issues on OSX (the latter being a big headache IMO).

The implementation of the Imperial Stockpile feature itself seems close to completion (thanks to Geoff picking it up after there hasn't been any progress for a while now). However, the new feature needs some serious playtesting and refinement before it can be considered ready for release. I suspect the intial content in particular will probably need some serious adjustments. Furthermore, the AI needs to be able to have at least basic capability to handle the new feature. @AI team, any idea/estimations how much work this is going to be?

The issues with the broken logging on OSX is a major problem: Apparently the solution to that requires changes to the build setup (the boost libraries need to be shared instead of static libraries), which require changes to the OSX SDK that are blocked by an issue we haven't been able to resolve so far. Although a solution has been proposed, apparently it's not a very good one (a temporary hack at best), and adrian_broher raised serious objections. However, the logging issues on OSX need to be fixed for the release, so we need to reach an agreement there, I think this might become the major holdup for 0.4.8. If anyone has an idea how to solve that mess, that would be appreciated very much...

Comments, opinions, suggestions, etc.?


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Mon Oct 30, 2017 5:03 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
Vezzra wrote:
Furthermore, the AI needs to be able to have at least basic capability to handle the new feature. @AI team, any idea/estimations how much work this is going to be?
Very basic handling of the feature should be pretty easy/quick to implement-- the AI could simply always enable the first item in its queue to draw from the stockpile. As far as something more advanced goes, I haven't looked at the stockpile in a while, but the expectation was that there would be some techs for expanding the stockpile size and efficiency, we should probably be able get them worked into the AI research planning someplace at least, even if it might be at a lower priority than a human player would use for them. The best use from my recollection of stockpile planning would be for the AI to consider any resource groups it has that are separated from its main resource group, and figure out if any items in those are critical enough that they should be given stockpile privilege. Doing that really well might be quite tricky, but it could be that figuring out some sort of reasonable-and-better-then-nothing rule might not be too bad. I am likely still pretty swamped for most of November, but will try to squeeze in some stockpile review.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Mon Dec 04, 2017 3:15 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4303
Location: Sol III
As there hasn't been much feedback, I assume you guys more or less agree with what I've considered mandatory for the release and what not. The broken logging on OSX has been resolved, and the major feature of this release (Imperial Stockpile) has been merged, which means we should be able to wrap things up in the foreseeable future. ;)

What remains to be done:

First of all, it would be good if as many of you as possible would playtest the new mechanic in particular now, and give your feedback. I consider what went in as still very rough around the edges and in need of polishing before we can deem this ready for release. In particular the content provided needs a major overhaul, IMO. What we have is perfectly fine for playtesting, as it gives you easy access to the new feature in test games. But the Imperial Stockpile techs/tech tree and the fluff explanations can certainly be improved, and being able to use the stockpile definitely shouldn't be something available right from game start.

Second, there are the issues and PRs mandatory for 0.4.8. I urge all our (active) devs to give those priority now, so we can clear that list. We can't proceed with the release until every item on that list has been finished.

It would be great if we could get 0.4.8 out by the end of January. If that's not possible, then by the end of February at the latest. Hopefully. ;)


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Mon Dec 04, 2017 6:06 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
Vezzra wrote:
It would be great if we could get 0.4.8 out by the end of January. If that's not possible, then by the end of February at the latest. Hopefully. ;)
There is a lot that I'd still like to do, not all really bugfixes, but won't have much time for until the end of this month, so end of January seems a bit a bit tight on time-- I'd like to be able to introduce some non-bugfix code at least up through the middle of January.

Quote:
being able to use the stockpile definitely shouldn't be something available right from game start.
I've followed up in Oberlus' feedback thread...

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Mon Dec 04, 2017 7:55 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
I have two questions: Is hostless an essential feature for v0.4.8?

If it is not, then bugs Heap-buffer-overflow in creating universe in the second game session. and Segfault on second session in hostless mode should not be on the mandatory list.

If hostless is an essential feature for v0.4.8, then I think that there are more unfound bugs because it changes a key assumption in the original design of the server, that it would be shutdown between games.


Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Fri Dec 08, 2017 12:31 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4303
Location: Sol III
Dilvish wrote:
There is a lot that I'd still like to do, not all really bugfixes, but won't have much time for until the end of this month, so end of January seems a bit a bit tight on time-- I'd like to be able to introduce some non-bugfix code at least up through the middle of January.
Well, if you have some stuff you want to get into 0.4.8 for which you need more time, we can certainly consider that (after all, one of the main purposes of this thread is to make such requests ;)). What are those things you want to get in?

Are the others ok with delaying 0.4.8? Guesstimating by what Dilvish said and past experiences (it always takes longer than you think), I'd expect a delay until March at the least. Geoff? Mat?

That said, a bit more time might be good anyway. Based on my own playtesting and the feedback that has been provided so far it seems the Imperial Stockpile feature needs some tweaking and balancing before it can be deemed release-ready, which I expect to take some time.


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Fri Dec 08, 2017 12:53 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4303
Location: Sol III
LGM-Doyle wrote:
I have two questions: Is hostless an essential feature for v0.4.8?
Well, originally 0.4.8 has been intended as a smaller release squeezed in before 0.5 (for which the plan is to introduce Influence, which is going to be a big, major thing) for the introduction of the Imperial Stockpile feature, so no, not really. However, as it has already been merged, it should be at least basically functional and not totally broken, so we can introduce it as an experimental feature.
Quote:
I'd say, it depends on how badly these bugs break hostless mode. Multiplayer and all related stuff is something I just don't have the time to look at/experiment with, so I can't make any judgement on that.
Quote:
If hostless is an essential feature for v0.4.8, then I think that there are more unfound bugs because it changes a key assumption in the original design of the server, that it would be shutdown between games.
If it's really so bad that we can't get hostless mode to work at least sufficiently well to pass as experimental feature, then yes, everything related to that feature should be considered optional, not mandatory for the release.

Looks like you (and Geoff) are probably the ones who can judge that best, so I defer this decision to the both of you. Geoff?
Quote:
Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.
While I understand and agree that's an issue, how is renaming those milestones to something more generic supposed to solve anything? Once the release is out, I intend to rename "0.4.8 (optional)" instead of making a new milestone and moving all the assigned issues and PRs anyway, so unless the timestamp of issues/PRs are reset when the assigned milestone is just renamed, there shouldn't be a problem with those. And the issues/PRs assigned to "post 0.4.8" will have to be reassigned to the renamed "0.4.8 (optional)", so their timestamp is going to change regardless how "post 0.4.8" has been named...?


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Fri Dec 08, 2017 2:17 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
Vezzra, mass changing of milestones causing spurious timestamping is more irksome than a full blown issue.
Vezzra wrote:
I intend to rename "0.4.8 (optional)"
This might work, but most other re-labelings, reset the timestamp. We will see.
Vezzra wrote:
how is renaming those milestones to something more generic supposed to solve anything?
Milestone names could be choosen that do not require immediately moving many/any issues upon releasing a new version.

The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".

One way of interpreting their intent is immediate, near future and far future requirements. Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version. The version numbers could be stripped from the second two milestones. It would improve their utility.

Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests.

And in another way, required, desirable, and wished for.

We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".

We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"

We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.

If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Sun Dec 10, 2017 5:23 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4303
Location: Sol III
LGM-Doyle wrote:
This might work, but most other re-labelings, reset the timestamp.
What do you mean by "most other re-labelings"? There are two ways in which milestones of issues/PRs are going to be changed after a release: renaming of a milestone (which should not change the timestamps) and reassigning issues/PRs to another milestone (which of course will change their timestamp). Is there anything else?
Quote:
The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".

One way of interpreting their intent is immediate, near future and far future requirements. [...] Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests. [...] And in another way, required, desirable, and wished for.
Erm, not quite. I guess this could be one reason for our misunderstanding: the "mandatory" and "optional" milestones are exactly that (not correspond loosly to ;)), release blocking issues/PRs and those that do not block the release. The purpose of the "post" milestone is to mark issues/PRs which shouldn't be worked upon until after the release. Either because they require too much effort and are not important for the release (so would distract too much dev manpower), or would open a can of worms that would delay the release too much.

Or, to phrase it a bit more to the point: "mandatory" = must go in, "optional" = can go in, "post" = should not go in.

Which means the the "post" milestone only makes sense when we're trying to wrap up a release, which in turn means that after a release all the issues/PRs assigned to the "post" milestone have to be reassigned. Unless I'm missing something obvious here, having more generic names for the "optional" and "post" milestone isn't going to help with that...
Quote:
Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version.
Right, which is why I intend to rename the "0.4.8 (optional)" milestone to "0.5 (optional)" (or "next release (optional)" if we haven't decided on the version number of the next release). All the "mandatory" issues/PRs have been closed/merged anyway, which only leaves the issues/PRs assigned to the "post" milestone. These are actually the only ones of concern when it comes to the timestamp problem.

The only advantage generic names for the "optional" and "post" milestones would be that renaming them isn't necessary anymore. Given how rarely that happens, I consider that a non-issue. I'd rather have the (IMO) more descriptive names which include the version number, but that's of course more of a cosmetic issue and a matter of personal preference.

The only way to avoid the reassigning of issues/PRs after a release I see would be to give up the "post" milestone.
Quote:
We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".

We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"

We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.

If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.
I'm a bit confused... except the last step, all this is practically the same as the current scheme, just different names for the milestones.

And I don't get that last step: what single feature request are you referring to here? Issues/PRs assigned to "optional" need to be reassigned to "vX.Y.Z" if we decide to promote something from being optional to being required for the next release, which is certainly not restricted to one item, and does not only happen right after a release. Also, this does not cover that items need to be moved from the "wishlist"/"post" milestone to "optional"...?

Sorry, it's not that I'm not open to revising my workflow here, you just need to have a bit more patience with me until I get what you mean. ;)


Top
 Profile  
 
 Post subject: Re: 0.4.8 roadmap
PostPosted: Sun Dec 10, 2017 8:49 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
Vezzra wrote:
What do you mean by "most other re-labelings"?
I meant that changing an issue's label changes its timestamp.
Vezzra wrote:
renaming of a milestone (which should not change the timestamps)
I expect that renaming the milestone will change the timestamp. If renaming the milestone does not change the timestamp, then all of this discussion is moot.
Vezzra wrote:
"post" = should not go in.
This I misunderstood. I assumed that if new contributor showed up with a fully functional Battle Simulator, before we started test a release candidate, we would help them merge it rather than saying, "Please wait a month or two". That is why I called it the third milestone wishlist.
Vezzra wrote:
Given how rarely that happens, I consider that a non-issue.
It is because it is rare that it is an issue. As time progresses we will accumulate issues. In a year we might have 1000+ unresolved minor issues/feature requests. With the current system, after a release renaming the optional Vx.y.z milestone will timestamp all of the issues. An issue that has had no other activity in two years and the latest feature request both look the same. If a new dev is looking for something to implement/fix, it would be better if they selected from a newer issue without trolling through any cruft. With the suggested system, a future maintainer can cull old issues without having to open every issue and see if there was some activity other than the milestone change.
Quote:
I'd rather have the (IMO) more descriptive names which include the version number ... a matter of personal preference
You are doing the work, so it is your preference that should get double weight.
Vezzra wrote:
all this is practically the same as the current scheme, just different names for the milestones
Correct. The different names (without version numbers) for wishlist and optional means that they have the same purpose regardless of the current target version.
Vezzra wrote:
And I don't get that last step: what single feature request are you referring to here?
This was implying that the new milestone would start with only the single core feature being transferred from wishlist or optional. It was also a too oblique reference to the absence of an influence issue to be transferred. :wink:

It was not meant to imply that other items could not move as well, but any move would be significant and indicate a change in status (and timestamp) of that particular issue.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group