New Committee insights & feedback
by Tim Condon · in Torque 3D Professional · 03/22/2014 (11:41 am) · 16 replies
Hi all--
There was an interesting conversation over on GitHub about Pull Requests that has some insights from the new committee about their vision for Torque. In retrospect, it would probably have been better to have that conversation in a more public venue, but you can find the conversation here: github.com/GarageGames/Torque3D/pull/545. The relevant conversation starts about eight posts down (basically anything dated in the past week or so).
It seemed worth sharing in large part because we haven't had any official statement from the new committee yet, but these posts give a bit of insight into the thinking that's been going on behind the curtain over the past six weeks or so.
--Tim
There was an interesting conversation over on GitHub about Pull Requests that has some insights from the new committee about their vision for Torque. In retrospect, it would probably have been better to have that conversation in a more public venue, but you can find the conversation here: github.com/GarageGames/Torque3D/pull/545. The relevant conversation starts about eight posts down (basically anything dated in the past week or so).
It seemed worth sharing in large part because we haven't had any official statement from the new committee yet, but these posts give a bit of insight into the thinking that's been going on behind the curtain over the past six weeks or so.
--Tim
#2
But then this was said.
Which is the wrong attitude to have. The committee needs to take ownership of this project and stop being scared of large pull requests.
And I will say one more thing, like so many before me I'm done with this project, MaintaingBACKWARDS COMPATIBILITY IS A DEATH SENTENCE to this project. Software and especially game engines need to evole and grow and not stay stagnate. None of major engines are backwards compatible with their previous iterations. UE4 is a prime example.
03/22/2014 (2:19 pm)
I think Tim Condon hit the nail on the head with statementQuote: When I look through the Pull Request history, I see two types of outcomes. Most changes were small improvements like a bugfix or an incremental feature, or they introduced widescale changes (such as this request, or the console refactor). If they were of the first type, they were - to use your phrasing - pushed through pretty quick. If they were of the second type, they basically died on the vine. I recognize that there are a lot of reasons for that, but it sends a message to the community that Torque is in maintenance mode, not development mode.
But then this was said.
Quote:We're not taking ownership of Torque, we're just trying to shepherd it into the future in the best way we can.
Which is the wrong attitude to have. The committee needs to take ownership of this project and stop being scared of large pull requests.
And I will say one more thing, like so many before me I'm done with this project, MaintaingBACKWARDS COMPATIBILITY IS A DEATH SENTENCE to this project. Software and especially game engines need to evole and grow and not stay stagnate. None of major engines are backwards compatible with their previous iterations. UE4 is a prime example.
#3
In the case of the console stuff there was clearly an interest in improving the system, as is evidenced by the discussion on the forums around the time. And to this day there still is if you consider what Jeff H is trying to do by implementing arrays... which covers some of the similar ground to my original changes. If he decides to make a pull request and his changes die on the vine just like mine, that does not send out a good message to contributors of the engine.
Having said that though, there have also been a few instances in the past of people trying to changes things and insert new fancy things for no good reason, which I think in a lot of cases is a bad idea as it introduces more complexity to the game engine. When I was refactoring the core code to use in an embeddable library, I noticed a few of cases in the pre-MIT code where functionality was duplicated several times over, or things were more over-engineered than they needed to be. And that was with a product being backed by a full development team who supposedly knew what they were doing! So I think its also important to have the oversight to reject pull requests too.
Regarding backwards compatibility I think it's important to a certain extent... you don't suddenly want to update from Torque3D 4.0 to 4.1 and find the world renders upside down and you have to rewrite all your game object code to use MVC for example.
03/22/2014 (3:15 pm)
I think Jimmy makes a good point about the large pull requests - it's frustrating when you put a lot of RND into a large pull request which has to change core things in the engine, only for it to get completely stalled because everyone is scared of it so much they don't even want to say no. I would rather have had someone say "James, these changes are too much. Can we rethink this?" and that would have been ok.In the case of the console stuff there was clearly an interest in improving the system, as is evidenced by the discussion on the forums around the time. And to this day there still is if you consider what Jeff H is trying to do by implementing arrays... which covers some of the similar ground to my original changes. If he decides to make a pull request and his changes die on the vine just like mine, that does not send out a good message to contributors of the engine.
Having said that though, there have also been a few instances in the past of people trying to changes things and insert new fancy things for no good reason, which I think in a lot of cases is a bad idea as it introduces more complexity to the game engine. When I was refactoring the core code to use in an embeddable library, I noticed a few of cases in the pre-MIT code where functionality was duplicated several times over, or things were more over-engineered than they needed to be. And that was with a product being backed by a full development team who supposedly knew what they were doing! So I think its also important to have the oversight to reject pull requests too.
Regarding backwards compatibility I think it's important to a certain extent... you don't suddenly want to update from Torque3D 4.0 to 4.1 and find the world renders upside down and you have to rewrite all your game object code to use MVC for example.
#4
Just saying that the only reason why I am doing this is because I want them to be used in my game while my programmers and I write a lot of the scripting :P, but thanks for mentioning me. But yeah, I agree though, you've done a lot more than I have (not to mention you have a ton more experience with programming, I'm new-ish too it and never had anything but high school programming courses) and it basically got pushed to rock bottom.
Also I agree with James U on backwards compatibility. Don't want to break the everything :P
03/22/2014 (3:36 pm)
Quote:In the case of the console stuff there was clearly an interest in improving the system, as is evidenced by the discussion on the forums around the time. And to this day there still is if you consider what Jeff H is trying to do by implementing arrays... which covers some of the similar ground to my original changes. If he decides to make a pull request and his changes die on the vine just like mine, that does not send out a good message to contributors of the engine.
Just saying that the only reason why I am doing this is because I want them to be used in my game while my programmers and I write a lot of the scripting :P, but thanks for mentioning me. But yeah, I agree though, you've done a lot more than I have (not to mention you have a ton more experience with programming, I'm new-ish too it and never had anything but high school programming courses) and it basically got pushed to rock bottom.
Also I agree with James U on backwards compatibility. Don't want to break the everything :P
#5
No, your right maintain compatibility with in the same version is vital.
New extensive features and rewrites should be saved for major revisions not minor ones.
Wich brings me to their Revision system. I argued against their current reversion system as a minor changes would bump up the version number.
03/22/2014 (4:01 pm)
@ JamesNo, your right maintain compatibility with in the same version is vital.
New extensive features and rewrites should be saved for major revisions not minor ones.
Wich brings me to their Revision system. I argued against their current reversion system as a minor changes would bump up the version number.
#6
- some official parallel review/experimental branches
- or at least a list of repos that are considered staged for review.
These would exist parallel to the core release branch and act as staging points for contributions or other developments.
If there is a big contribution where a dev or a company does not have time to package that into smaller chunks as needed by the committee for a core release, they can push it to an experimental branch and ask for community volunteer to to help with the code review and packaging into pull requests for future consideration by the committee.
This way big contributions do not get rejected outright but can be staged and managed into the core process as time, resource and people can support.
This is sort of organically occurring anyhow.
For example there is Tim's stuff (lets call it a UI/Editor experimental branch), AndrewM is maintaining a next gen branch, Louis has the OpenGl branch, Anis has the Directx refactor branch, JeffH has the extensions to torquescript branch, never mind the cool stuff by the Winterleaf team et al to name just a few..
If we maintain either an official set of experimental branch repos or a list of staging repos / then either the original dev or a volunteer can become responsible for submitting pull requests from an experimental branch into the core committee and the core committee manages the stable Torque3D release.
People interested in features that do not make the core - can manage their own packaging based on experimental branches and maintain them as long as they need.
Other open source projects like Blender use parallel branches in this way (in the past with svn now with git). They enable Summer of Code projects to live along side interest groups such bio-simulation and robotics groups among others as well as the official core dev 3D authoring branches. The staging and parallel development approach is part of what makes Blender a successful and interesting open source project.
The benefit of using this approach for Torque3D to the community and individual contributors would be:
- developments and contributions become visible even if not in core release
- interesting experiments can be undertaken and assessed in relation to the core without impacting stability
- there are known points of responsibility and contact
- contributions can be stage managed and not lost,
- community volunteers can get involved to help
- and future feature incorporation can be planned based on available resources, active contributions etc.
just a thought.
03/24/2014 (12:48 am)
Perhaps a means to solve this is to either have:- some official parallel review/experimental branches
- or at least a list of repos that are considered staged for review.
These would exist parallel to the core release branch and act as staging points for contributions or other developments.
If there is a big contribution where a dev or a company does not have time to package that into smaller chunks as needed by the committee for a core release, they can push it to an experimental branch and ask for community volunteer to to help with the code review and packaging into pull requests for future consideration by the committee.
This way big contributions do not get rejected outright but can be staged and managed into the core process as time, resource and people can support.
This is sort of organically occurring anyhow.
For example there is Tim's stuff (lets call it a UI/Editor experimental branch), AndrewM is maintaining a next gen branch, Louis has the OpenGl branch, Anis has the Directx refactor branch, JeffH has the extensions to torquescript branch, never mind the cool stuff by the Winterleaf team et al to name just a few..
If we maintain either an official set of experimental branch repos or a list of staging repos / then either the original dev or a volunteer can become responsible for submitting pull requests from an experimental branch into the core committee and the core committee manages the stable Torque3D release.
People interested in features that do not make the core - can manage their own packaging based on experimental branches and maintain them as long as they need.
Other open source projects like Blender use parallel branches in this way (in the past with svn now with git). They enable Summer of Code projects to live along side interest groups such bio-simulation and robotics groups among others as well as the official core dev 3D authoring branches. The staging and parallel development approach is part of what makes Blender a successful and interesting open source project.
The benefit of using this approach for Torque3D to the community and individual contributors would be:
- developments and contributions become visible even if not in core release
- interesting experiments can be undertaken and assessed in relation to the core without impacting stability
- there are known points of responsibility and contact
- contributions can be stage managed and not lost,
- community volunteers can get involved to help
- and future feature incorporation can be planned based on available resources, active contributions etc.
just a thought.
#7
I completely agree. I think it's also worth mentioning Blender's Open Movie Projects. This gets the community involved, and gives them a sense of ownership in the software. It also serves as a direction for Blender, seeing that ton and co. set a goal that they want to reach for, and then drive development in that direction.
My 2 cents
03/24/2014 (10:56 am)
@PhillipI completely agree. I think it's also worth mentioning Blender's Open Movie Projects. This gets the community involved, and gives them a sense of ownership in the software. It also serves as a direction for Blender, seeing that ton and co. set a goal that they want to reach for, and then drive development in that direction.
My 2 cents
#8
In all fairness, this was attempted with James' console refactor and almost no one jumped in to test that.
That said, I have a feeling that was a combination of 2 factors:
a) people still weren't(aren't) familiar enough with git to actually be able to get that branch and test it specifically, and
b) visibility problems - not enough people even knew it needed to be tested and where to go to test it.
I think pushing controversial PRs into a branch that can be tested and reviewed over time is probably the best way to approach the really big things, we just need a solid way to ensure people are aware those exist and need testing.
The current SC is working on a git-side Torque3D website that emphasizes the engine and git-stuff specifically, so we can look at having a place where we can emphasize those experimental branches to ensure people are at least aware of them.
That said, on the side of the SC being 'scared' to implement big changes, a part of that is we're very cognizant of the complaint with Torque3D that it's a mess that would confuse a bowl of spaghetti. Just dumping in large, hundred-file-touching requests doesn't do that issue any favors, so we're treading lightly.
The UI PR mentioned is a particularly complicated one because it's big and also adds a bunch of separate improvements. And it's hard for the SC to properly test everything when it's like that. James' console refactor was more pointed and thus easier to test.
However, moving to the experimental branch approach - and pushing them into the spotlight so they're tested by the community, would be a good way of dealing with that.
We're also looking to move to a X.0 and X.Y branch approach, where huge, breaking changes can be moved into the next-major revision branch without having to sit and sputter while we move through the sub-revision updates. That should also improve this sort of situation.
03/24/2014 (6:31 pm)
Pretty interesting discussion in here! :DQuote:
If there is a big contribution where a dev or a company does not have time to package that into smaller chunks as needed by the committee for a core release, they can push it to an experimental branch and ask for community volunteer to to help with the code review and packaging into pull requests for future consideration by the committee.
This way big contributions do not get rejected outright but can be staged and managed into the core process as time, resource and people can support.
In all fairness, this was attempted with James' console refactor and almost no one jumped in to test that.
That said, I have a feeling that was a combination of 2 factors:
a) people still weren't(aren't) familiar enough with git to actually be able to get that branch and test it specifically, and
b) visibility problems - not enough people even knew it needed to be tested and where to go to test it.
I think pushing controversial PRs into a branch that can be tested and reviewed over time is probably the best way to approach the really big things, we just need a solid way to ensure people are aware those exist and need testing.
The current SC is working on a git-side Torque3D website that emphasizes the engine and git-stuff specifically, so we can look at having a place where we can emphasize those experimental branches to ensure people are at least aware of them.
That said, on the side of the SC being 'scared' to implement big changes, a part of that is we're very cognizant of the complaint with Torque3D that it's a mess that would confuse a bowl of spaghetti. Just dumping in large, hundred-file-touching requests doesn't do that issue any favors, so we're treading lightly.
The UI PR mentioned is a particularly complicated one because it's big and also adds a bunch of separate improvements. And it's hard for the SC to properly test everything when it's like that. James' console refactor was more pointed and thus easier to test.
However, moving to the experimental branch approach - and pushing them into the spotlight so they're tested by the community, would be a good way of dealing with that.
We're also looking to move to a X.0 and X.Y branch approach, where huge, breaking changes can be moved into the next-major revision branch without having to sit and sputter while we move through the sub-revision updates. That should also improve this sort of situation.
#9
I just wanted to jump in and say we're working on an actual intro blog and a shiny new website for Torque, which we're hoping will more effectively channel people to the right sources of knowledge about the engine. It won't be a full-on community site - GG.com will still be the home of T3D's forums and user blogs - but we just wanted a nicer landing page for people than the GitHub repo or the GG product page. And, importantly, it will include the committee charter, our modus operandi, and guidelines for pull requests and how we will go about evaluating them.
I'll come back later and actually add some content to this thread when I shouldn't be doing other things :P.
03/25/2014 (10:41 pm)
Sorry about the lack of transparency so far, guys. Following the discussion on issues and pull requests is currently the best way to see how we work :P.I just wanted to jump in and say we're working on an actual intro blog and a shiny new website for Torque, which we're hoping will more effectively channel people to the right sources of knowledge about the engine. It won't be a full-on community site - GG.com will still be the home of T3D's forums and user blogs - but we just wanted a nicer landing page for people than the GitHub repo or the GG product page. And, importantly, it will include the committee charter, our modus operandi, and guidelines for pull requests and how we will go about evaluating them.
I'll come back later and actually add some content to this thread when I shouldn't be doing other things :P.
#10
If i'm reading this correctly, that would be a great idea. It would make sense to have
3.51
3.6
3.7 etc
and also the next major version 4.0. Version 4.0 would give a great chance to start implementing some larger changes (for example D3D11/GL4 and the advancements that go with these) with whatever interface breaking changes are needed to see these new features implemented. If projects need modification to work from 3.x > 4.x than so be it. If projects don't need to be modified than great but if they do, well that's the price of advancement. Obviously version 3.x series would all be fully backward compatible.
03/26/2014 (4:15 am)
Quote:We're also looking to move to a X.0 and X.Y branch approach, where huge, breaking changes can be moved into the next-major revision branch without having to sit and sputter while we move through the sub-revision updates. That should also improve this sort of situation.
If i'm reading this correctly, that would be a great idea. It would make sense to have
3.51
3.6
3.7 etc
and also the next major version 4.0. Version 4.0 would give a great chance to start implementing some larger changes (for example D3D11/GL4 and the advancements that go with these) with whatever interface breaking changes are needed to see these new features implemented. If projects need modification to work from 3.x > 4.x than so be it. If projects don't need to be modified than great but if they do, well that's the price of advancement. Obviously version 3.x series would all be fully backward compatible.
#12
That was said in response to this:
What I should have said was we're not just accountable to ourselves - we're accountable to every user T3D has. Which means we can't just make unilateral decisions about the engine's future, which is why we have such a process and why we're a little shy of large PRs - because they imply that they might impact every user of the engine.
Also, I want to note that our title is Steering Committee - not Lead Development Team. Our responsibility is steering, i.e. curating and soliciting community work. Obviously we're all active developers working on Torque, so lots of our own work is valuable to the engine and we'll be submitting it as usual. But Torque is not our engine. We've just been given the responsibility of holding the keys.
Timmy: the other thing we'd like to do is have versions 3.5.2, 3.5.3, etc. which contain bugfixes that are applicable to 3.5 ported back from future branches. So if you don't upgrade your project to 3.6 or 4.0, you can hopefully still get some ongoing support.
03/27/2014 (4:00 pm)
Quote:We're not taking ownership of Torque, we're just trying to shepherd it into the future in the best way we can.
Quote:Which is the wrong attitude to have. The committee needs to take ownership of this project and stop being scared of large pull requests.
That was said in response to this:
Quote:Indeed, as I understand it, they are ultimately accountable only to themselves (and GG).
What I should have said was we're not just accountable to ourselves - we're accountable to every user T3D has. Which means we can't just make unilateral decisions about the engine's future, which is why we have such a process and why we're a little shy of large PRs - because they imply that they might impact every user of the engine.
Also, I want to note that our title is Steering Committee - not Lead Development Team. Our responsibility is steering, i.e. curating and soliciting community work. Obviously we're all active developers working on Torque, so lots of our own work is valuable to the engine and we'll be submitting it as usual. But Torque is not our engine. We've just been given the responsibility of holding the keys.
Quote:And that was with a product being backed by a full development team who supposedly knew what they were doing!Exactly. The engine is so large that no one of us has a good overall picture, so we need to take things a bit slowly and carefully to make sure we're being good stewards of the source code.
Quote:That said, on the side of the SC being 'scared' to implement big changes, a part of that is we're very cognizant of the complaint with Torque3D that it's a mess that would confuse a bowl of spaghetti.QFT.
Timmy: the other thing we'd like to do is have versions 3.5.2, 3.5.3, etc. which contain bugfixes that are applicable to 3.5 ported back from future branches. So if you don't upgrade your project to 3.6 or 4.0, you can hopefully still get some ongoing support.
#13
Given the new committee's interest in expansive branching patterns hopefully that will become a moot issue.
03/27/2014 (9:29 pm)
I just have to say that the old committee was never afraid to implement some of those big pull requests... only that noone was ever willing to test and correct known issues with such.Given the new committee's interest in expansive branching patterns hopefully that will become a moot issue.
#14
03/27/2014 (10:54 pm)
Quote:I just have to say that the old committee was never afraid to implement some of those big pull requests... only that noone was ever willing to test and correct known issues with such.+1. We'll also be putting some effort into unit tests and automated build stuff so we can increase our confidence in changes.
#15
If there is any chanche of affecting the opinion of the current group in charge, heard this: get back to something real guys!
The current Mozilla type approach is equally dumb than in mozilla releases, but double idiotic, as was decided in a whim, and closed doors, against the will of the community (paradoxically, in the moment of open sourcing the engine).
Other than that, keep it up!! :)
03/30/2014 (12:23 pm)
Jumping from my cloud, just to mention how annoying the current versioning system is.If there is any chanche of affecting the opinion of the current group in charge, heard this: get back to something real guys!
The current Mozilla type approach is equally dumb than in mozilla releases, but double idiotic, as was decided in a whim, and closed doors, against the will of the community (paradoxically, in the moment of open sourcing the engine).
Other than that, keep it up!! :)
#16
03/30/2014 (2:22 pm)
We hear you.Quote:We're also looking to move to a X.0 and X.Y branch approach, where huge, breaking changes can be moved into the next-major revision branch without having to sit and sputter while we move through the sub-revision updates. That should also improve this sort of situation.Check out the milestones on GitHub - we've already started assigning some issues to 3.6, 3.7, and 4.0.
Azaezel
For what it's worth, I can definitely see both sides of this one, since like I've said before, anything I push, I've used, and it's typically at least a week in production code if not longer before I consider doing so, meaning I'm well aware of the pain in the rear it can be to extract out relevant portions.