Page 2 of 7

Re: 0.4.8 roadmap

Posted: Sun Mar 18, 2018 2:31 pm
by Ophiuchus
Geoff the Medio wrote:Given the recent issues with a refactoring change, is it perhaps worth making a v0.4.8 branch soon, and limiting it to release-blocking or at least reasonably well-tested non-blocking issues? I think the release is being delayed by such distractions...
+1

Does somebody lead the release process? I would certainly want to go at least into "feature freeze" now. If that means locking master or setting up a 0.4.8 branch I do not really care. Both would be fine.

Re: 0.4.8 roadmap

Posted: Sun Mar 18, 2018 6:21 pm
by Vezzra
Geoff the Medio wrote:Given the recent issues with a refactoring change, is it perhaps worth making a v0.4.8 branch soon, and limiting it to release-blocking or at least reasonably well-tested non-blocking issues?
It doesn't make much sense to me to create the release branch as long as the main feature of this release is still being worked on. For one there is still one release blocking PR related to said main feature, and then my impression is that there should be a bit more playtesting of the new feature, or at least playtesting by more people. Although Oberlus has been very diligent in that area, and a couple of others seem to have done a fair share of playtesting too, I'm a bit unsure if it has been sufficient for a completely new mechanic that introduced a significant change to another core mechanic, obviously caused significant balance issues that had to be ironed out, etc.

Unfortunately I didn't get around to do some decent playtesting myself, I always hoped I'd find the time, and never managed to. So I need to rely on the assessment of those involved with developing, playtesting, balancing and polishing the IS so far: do you guys think the feature is ready for release?

The other thing is, usually I wait until all release blocking issues are dealt with, for the simple reason to minimize the cherry picking ordeal that always commences the moment I create the release branch. If there is still stuff that needs to be done, that means the release branch needs to be maintained that much longer, which is particularly annoying with all the bugfixing that happens all the time. The longer it takes from the time the release branch is created until the release is finally out, the longer people already work on new stuff in master. Which introduces new bugs, which get fixed, and every time that happens someone has to pay attention if a bugfix fixes something that has been introduced after the creation of the release branch (and therefore must not get cherry picked into the release branch) or an older bug that has already been present before (and there must get cherry picked into the release branch).

Often enough the cherry picking is also left to me, which gets particularly tricky if there are conflicts to resolve. Difficult for me who hasn't written the code, and isn't the most competent coder around here to begin with.
I think the release is being delayed by such distractions...
Compared to the hassle maintaining the release branch for longer than absolutely necessary these issues you refer to look rather minor to me. Those bugs have been dealt with quickly enough, and haven't actually caused any delays (yet).

Of course, that said, I completely agree people should refrain from working on optional or new stuff for now and concentrate their efforts on cleaning up the remaining release blocking issues. Some items on the "0.4.8 (mandatory)" list have been sitting there for months, with no sign of anyone intending to touch them. If I create the release branch now, who knows how long it will take until those get solved?

Re: 0.4.8 roadmap

Posted: Sun Mar 18, 2018 6:39 pm
by Vezzra
Ophiuchus wrote:Does somebody lead the release process?
That would be me. Hence my forum title "Release Manager". ;)
I would certainly want to go at least into "feature freeze" now.
Well, we don't have something like that, at least not as strictly as other projects do. "Feature freeze" more or less happens when the release branch gets created, as usually only bugfixes get cherry picked into the release branch, not new features (of course, there can be the odd exceptions to that rule, but we try to avoid that for obvious reasons).

See my post above why that hasn't happened yet (besides me having been busy and not having much time for FO lately).

Another thing about something akin to a "feature freeze", let me quote myself (from a former post in this thread):
Vezzra wrote: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.
Of course, once it became clear that the IS feature would take more time than originally planned, people probably started on other stuff in the meantime. But it looks like the IS is getting closer to release ready finally, so I want to reinforce that statement:

Please, everyone, start prioritizing the release again, that is, concentrate your efforts on the remaining release blocking issues/PRs! And on giving the IS feature some final polishing! So we can get on with 0.4.8. :D

Re: 0.4.8 roadmap

Posted: Mon Mar 19, 2018 2:19 pm
by Ophiuchus
Vezzra wrote:
Ophiuchus wrote:Does somebody lead the release process?
That would be me. Hence my forum title "Release Manager". ;)
:)
Vezzra wrote:"Feature freeze" more or less happens when the release branch gets created, as usually only bugfixes get cherry picked into the release branch, not new features (of course, there can be the odd exceptions to that rule, but we try to avoid that for obvious reasons).
Thanks for the clarifications. I totally get we should minimize unnecessary merging. What I meant with locking the master for feature freeze is (announcing that you are) not accepting any pull requests with new features. So only 0.4.8 mandatory (and maybe 0.4.8 optionals) and bugfixes. Is that an option?
Vezzra wrote:Please, everyone, start prioritizing the release again, that is, concentrate your efforts on the remaining release blocking issues/PRs! And on giving the IS feature some final polishing! So we can get on with 0.4.8. :D
I'm in ;)

Re: 0.4.8 roadmap

Posted: Mon Mar 19, 2018 5:54 pm
by adrian_broher
Ophiuchus wrote:I totally get we should minimize unnecessary merging. What I meant with locking the master for feature freeze is (announcing that you are) not accepting any pull requests with new features. So only 0.4.8 mandatory (and maybe 0.4.8 optionals) and bugfixes. Is that an option?
No, do your release feature freeze thingies on a release branch and leave master alone.

Re: 0.4.8 roadmap

Posted: Tue Mar 20, 2018 3:07 pm
by Ophiuchus
adrian_broher wrote:
Ophiuchus wrote:I totally get we should minimize unnecessary merging. What I meant with locking the master for feature freeze is (announcing that you are) not accepting any pull requests with new features. So only 0.4.8 mandatory (and maybe 0.4.8 optionals) and bugfixes. Is that an option?
No, do your release feature freeze thingies on a release branch and leave master alone.
Meh :(

Re: 0.4.8 roadmap

Posted: Thu Mar 22, 2018 1:04 pm
by Vezzra
Ophiuchus wrote:What I meant with locking the master for feature freeze is (announcing that you are) not accepting any pull requests with new features. So only 0.4.8 mandatory (and maybe 0.4.8 optionals) and bugfixes. Is that an option?
Not really. I do understand the sentiment, and while I have to admit that I'm tempted myself at times to do something drastic like this (when I see people happily working on features and optional stuff while release blocking things hang for months), the very idea to work with release branches is to avoid exactly that: block ongoing development in master.

Creating the release branch is actually the "feature freeze" you're asking for, but it doesn't make much sense to do that "feature freeze" as long as the main feature of the release is still worked on. While it looks like we might be able to wrap that up soon, we aren't there yet. Getting the last PRs for the IS merged would be a big step, and then some more playtesting feedback.

Which brings me to the the question I already made a few posts above: Do you guys think the IS feature is ready for release? The responses haven't exactly been overwhelming so far, which isn't very encouraging... ;)

Re: 0.4.8 roadmap

Posted: Thu Mar 22, 2018 1:12 pm
by Vezzra
Ophiuchus wrote:Meh :(
Now, don't be discouraged :D The stuff happening in master hasn't caused any delays so far, it's the IS feature still being worked on that's the big roadblock right now. Once that's done, clear the last release blocking issues, and we are good to go.

Re: 0.4.8 roadmap

Posted: Thu May 10, 2018 2:44 pm
by Vezzra
The last updates in this thread have been made roughly one and a half months ago, and progress on the remaining release-blocking issues and PRs has been, well, tedious and kind of pitiful at best. Also, the responses to my (repeated) appeal:
Vezzra wrote:Which brings me to the the question I already made a few posts above: Do you guys think the IS feature is ready for release? The responses haven't exactly been overwhelming so far, which isn't very encouraging... ;)
...has been as underwhelming as before.

I have to confess this is a bit disheartening, although that's of course no one's fault - apparently a considerable part of our team (devs and playtesters) hasn't had much time recently (me included). But whatever the reasons, I'm a bit at a loss how to address this problem. I don't want to delay 0.4.8 for another couple of months, we need to come up with some ideas what we can do about it, so we can finally proceed with the release.

One thing that has been suggested repeatedly is to go ahead and create the release branch already, to prevent the introduction of new bugs/issues by stuff going into master that isn't really required for the release. Although that has it's own problems if it takes too long for the remaining issues that need to be fixed for the release to be taken care of (I'm talking about the cherry picking to the release branch thing), I'm willing to take that step at this point - provided the last things concerning the main feature of this release (the IS) can be finished before at least. I'm talking about issues #2030 and #2080. So, anyone who wants to take on those is more than welcome.

Another thing we can do is reevaluate the remaining release-blocking issues and PRs and reconsider if they really are absolutely necessary for the release, and make those which can be left unresolved optional. I'm thinking e.g. of #1794 and #2009.

Any of the issues/PRs on the mandatory list we can reassign to optional? Or maybe the other way round: which of these issues/PRs do you consider absolutely necessary for the release? Please, everyone, give your feedback!

Re: 0.4.8 roadmap

Posted: Thu May 10, 2018 2:59 pm
by Geoff the Medio
Vezzra wrote:...which of these issues/PRs do you consider absolutely necessary for the release?
The parsing problems are probably blocking, though there are alternatives if it can't be fully resolved. AI issues, I can't meaningfully comment on. UI quirks are debatable.

Re: 0.4.8 roadmap

Posted: Thu May 10, 2018 4:29 pm
by o01eg
Vezzra wrote: Any of the issues/PRs on the mandatory list we can reassign to optional? Or maybe the other way round: which of these issues/PRs do you consider absolutely necessary for the release? Please, everyone, give your feedback!
I suppose any backward or forward compatibility breakers should be considered as a mandatory, other server-only (AI) or client-only (UI) issues could be postponed to bugfix release within 0.4.8 branch.

Re: 0.4.8 roadmap

Posted: Thu May 10, 2018 10:23 pm
by Dilvish
I've revised #2009 (about sanitizing and better commenting the AI uses of currentMeter vs initialMeter) to be optional, since I am pretty sure that the most important changes identified there have already been done.

I am also putting some more time into #1794 (about an AI error message that sometimes pops up on savegame load) The AI already recovers fairly cleanly from that error situation, but we have it still visibly flagging the error because we're still puzzled about just how the error situation comes about (and whether the underlying cause is also leading to other problems which haven't made themselves apparent), and we want to avoid out-of-sight-out-of-mind. If I don't get it resolved fairly soon, then we could change the logging to be warn level rather than error level, so that it does not trigger an in-game message about the problem, and then downgrade the Issue to optional rather than mandatory.

While working on #1794 today I came across another issue that was triggering an in-game AI error message about ShipDesign cache corruption after game load. There was already some related cleanup being done with logging just at the warn level, but the cleanup had not been quite thorough enough to always prevent the problem later triggering an error message. I'm about to submit a PR that adds some more cleanup and resolves the error message, but I'm also going to submit an optional-grade Issue for the underlying cache corruption issue the warning is for, because just like with #1794 if we wind up with a lingering underlying error that we simply recover smoothly from but don't really fully resolve then I think we should keep an outstanding Issue open for it.

Re: 0.4.8 roadmap

Posted: Mon May 14, 2018 7:25 pm
by Vezzra
Ok, we are down to 2 release-blocking issues, one of which (#1794) can be reassigned to optional after applying some stop-gap fixes to the release branch (as suggested by Dilvish), and the other one, while it needs to be addressed, isn't so serious that it should block the creation of the release branch.

Which means, unless something unexpected turns up or someone objects, I think we can finally proceed with that.

Deadline is coming Sunday, May 20th, 6pm UTC.

That should give everyone a few days time to think things over, if there is anything we might have overlooked that should/needs to be done before, or to raise any objections. If nothing comes up, and no one objects until then, I will proceed with the creation of the release branch.

Re: 0.4.8 roadmap

Posted: Fri May 18, 2018 3:47 pm
by Vezzra
I've opened the "management issue" for the 0.4.8 release.

Despite the issues/PRs that have been added to the mandatory milestone in the meantime, I'm still aiming for the May 20th deadline for the creation of the release branch, as those don't seem serious enough for me to postpone that. If anyone objects, please do so in time, otherwise I'll proceed as planned.

Re: 0.4.8 roadmap

Posted: Sat May 19, 2018 7:21 pm
by Vezzra
Just a heads-up: I have to be at an unplanned appointment tomorrow evening, meaning, creation of the release branch might/will be delayed until probably very late into the evening. Worst case I'll only be able to get around to it on Monday.

However, the deadline will be left as it is, so please, don't count on the delay. :wink: