Maintenance branch
Moderator: Moderators
Maintenance branch
I've added a maintenance branch of spring that contains most non-opengl changes since 104.0.
This is done as a temporary measure to keep new engine changes tested so bugs don't get the opportunity to ferment.
A few guidelines:
1) No commits or pull requests will be made directly to this branch, only cherry-picks from develop
2) Bug reports on this branch will only be investigated (by me) if the reporter clearly states whether it can be reproduced on the develop branch or not (unless impossible, e.g., desyncs).
3) If there's a non-opengl change that I haven't ported to the branch even though I should have, contact me through PM or through #sy
This is done as a temporary measure to keep new engine changes tested so bugs don't get the opportunity to ferment.
A few guidelines:
1) No commits or pull requests will be made directly to this branch, only cherry-picks from develop
2) Bug reports on this branch will only be investigated (by me) if the reporter clearly states whether it can be reproduced on the develop branch or not (unless impossible, e.g., desyncs).
3) If there's a non-opengl change that I haven't ported to the branch even though I should have, contact me through PM or through #sy
Re: Maintenance branch
Why does this require a new branch?
why is kloot writing "." ?
why is kloot writing "." ?
Re: Maintenance branch
That way it allows breaking and WIP openGL changes to continue unhindered in develop.raaar wrote:Why does this require a new branch?
Re: Maintenance branch
https://springrts.com/mantis/view.php?id=5812
https://springrts.com/mantis/view.php?id=5811
(it doubles the work for testers / the diff from develop to the maintainance is huge. possible bugs are found in maintainance which aren't in develop and vice versa)
i don't see this plan going to work both reports ignored rule 2. it seems.
imo its more effective to test current develop and report bugs as usual. if we have to many breaking stuff, the breaking changes should be made on a branch.
https://springrts.com/mantis/view.php?id=5811
(it doubles the work for testers / the diff from develop to the maintainance is huge. possible bugs are found in maintainance which aren't in develop and vice versa)
i don't see this plan going to work both reports ignored rule 2. it seems.
imo its more effective to test current develop and report bugs as usual. if we have to many breaking stuff, the breaking changes should be made on a branch.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Maintenance branch
I guess the intention is that all play-testers should use the maintenance branch until, at some point in future, the develop branch is announced as "finished the GL upgrade", at which point we'll go back to testing develop?
Re: Maintenance branch
Not quite "finished", but when stability returns to be a higher priority in develop, or whenSilentwings wrote:I guess the intention is that all play-testers should use the maintenance branch until, at some point in future, the develop branch is announced as "finished the GL upgrade", at which point we'll go back to testing develop?
Actually in both cases reproducing wasn't applicable, so reports were ok.i don't see this plan going to work both reports ignored rule 2. it seems.
The point is that this plan was my idea of what I can do personally to keep the engine tested as much as possible, while allowing games to have a playable version with fixes for bugs present in 104.0.
I'm not surprised that some think it's an incorrect approach, this way of work was chosen partially because I can implement it by myself.
Re: Maintenance branch
i guess kloot has to say if the maintainance branch helps him or not... lets see. there is no clear right or wrong here.hokomoko wrote:Actually in both cases reproducing wasn't applicable, so reports were ok.
The point is that this plan was my idea of what I can do personally to keep the engine tested as much as possible, while allowing games to have a playable version with fixes for bugs present in 104.0.
I'm not surprised that some think it's an incorrect approach, this way of work was chosen partially because I can implement it by myself.
Re: Maintenance branch
Having engine devs using the same branch makes it more likely that they'll stumble upon each other's bugs before they hit the rest of the community.
Re: Maintenance branch
I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested and you do not have to worry about commits with both GL and other changes.
I think this is better since the GL changes will be tested and you do not have to worry about commits with both GL and other changes.
Re: Maintenance branch
If you let ZK handle it then ZK just stays at 104.0 for a while and the GL changes will not be tested. Note that with maintenance branch they do not get tested either but at least the non-GL ones do.I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested
Last edited by sprunk on 20 Oct 2017, 18:44, edited 1 time in total.
Re: Maintenance branch
sprunk, that is only if game(zk) devs do not have the time or will to test develop.
I suspect hokomoko and perhaps even kloot are willing to contribute to that zk branch if zk devs do not have time/will for it.
Imo, it is clear all develop changes should be tested by game devs and testers like me since develop changes are not thoroughly tested by "upstream".
I think it will be difficult to only get the non-GL changes from develop to the maintenance branch, e.g. I bet kloot is not keen on separating commits for that.
I suspect hokomoko and perhaps even kloot are willing to contribute to that zk branch if zk devs do not have time/will for it.
Imo, it is clear all develop changes should be tested by game devs and testers like me since develop changes are not thoroughly tested by "upstream".
I think it will be difficult to only get the non-GL changes from develop to the maintenance branch, e.g. I bet kloot is not keen on separating commits for that.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Maintenance branch
But what about the rest of us? Do we get special engine Dev help as well? ZK already has an army of devs compared to the rest of us. After all of that, If zk needs help from engine devs, then the rest of us are probably screwed.
Re: Maintenance branch
So if you ever had beef with kloot- wait some time, fork this branch and implement some graphics heavy feature for spring. Got it !
Re: Maintenance branch
@forb I think the intention is that all devs can rely on it, so you too should talk to hokomoko
My main worry with this approach is that it has a chance of leading to a gl3/4 engine fork if content devs decide not to use gl4. I see little guarantee or exact schedule for this things temporariness.
My main worry with this approach is that it has a chance of leading to a gl3/4 engine fork if content devs decide not to use gl4. I see little guarantee or exact schedule for this things temporariness.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Maintenance branch
Here are my thoughts on the branch: https://github.com/ZeroK-RTS/Zero-K/issues/2547.
On testing - I think testing carried out by a small pool of testers is ineffective. This reflects well on the stability of the engine. In the months leading up to 104.0 almost all the bugs were either rare or hardware specific. The former type requires many players playing many games to find and the latter type are mostly impossible to find with my hardware. We've only found these bugs by tracking the dev engine as the live engine on the server. My testing prior to making an engine live amounts to running an AI game (to check for obvious synced bugs) and testing bugfixes.
On testing - I think testing carried out by a small pool of testers is ineffective. This reflects well on the stability of the engine. In the months leading up to 104.0 almost all the bugs were either rare or hardware specific. The former type requires many players playing many games to find and the latter type are mostly impossible to find with my hardware. We've only found these bugs by tracking the dev engine as the live engine on the server. My testing prior to making an engine live amounts to running an AI game (to check for obvious synced bugs) and testing bugfixes.
I don't understand this viewpoint. What is being done with the engine which you are unable to take advantage of? You can use the maintenance branch and you could have been tracking develop earlier to get all the latest fixes. Why aren't you just glad that someone was testing develop on players?Forboding Angel wrote:But what about the rest of us? Do we get special engine Dev help as well? ZK already has an army of devs compared to the rest of us. After all of that, If zk needs help from engine devs, then the rest of us are probably screwed.
I don't see hpw that ticket is relevant or what needs handling there which is related to engines.cleanrock wrote:I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested and you do not have to worry about commits with both GL and other changes.
Re: Maintenance branch
I guess you only want to use non-breaking changes because the zk selected 104 was bad in some way, i say this because https://github.com/spring/spring/commit/6971132e was excluded from maintenance.Google_Frog wrote:I don't see how that ticket is relevant or what needs handling there which is related to engines.
Perhaps this is a good idea but at some point all changes need to be tested to move forward with your model (must be tested in public games and revert engine if fail).
I think zk should have test hosts running a zk-test version/branch using a selected spring/develop but perhaps the current low player base do not make this a realistic option if many big public games are required.
It all looks a bit messy to me but perhaps you guys have a good plan.
Re: Maintenance branch
This commit was excluded due to my error, it was actually in the list of things ZK wanted to port.cleanrock wrote:I guess you only want to use non-breaking changes because the zk selected 104 was bad in some way, i say this because https://github.com/spring/spring/commit/6971132e was excluded from maintenance.
In general - breaking changes are planned to be included in the maintenance branch. If there are more commits that I've missed please point them to me.
Re: Maintenance branch
seems the branch wasn't updated since 13. Nov. i.e. https://github.com/spring/spring/commit ... 8a3c2e6618 :)hokomoko wrote:In general - breaking changes are planned to be included in the maintenance branch. If there are more commits that I've missed please point them to me.
Re: Maintenance branch
I've updated maintenance branch, builds should be up somewhen. Breakages are quite possible.