Committee Meeting Notes: 09/04/2013

#1 Hello all,

In my opinion, I think the committee instead of waiting months or years to release a massive patch full of new features for the T3D, might go releasing small patches (binary releases) for true bugs already proven.

However, these fixes should, in fact, be previously tested for ensure the success of correction and also to ensure the corrections do not ruin those features that were working properly before the patch has been applied, thus maintaining the integrity of the quality of the game engine.

I have ever seen programs that when they made updates to fix existing bugs end up ruining those characteristics that used to work fine before, becoming in truly updates of degradation of the product and not to enhancement the software.

Furthermore, it is important for users of T3D, especially for future users have the sense that the software is constantly being updated, even in small doses, and alive.

Please do not tell me similar things like: "you have the source code, fix it yourself and shut up!' alternatively, "it's a free product, and you cannot be asking for anything here and shut your mouth up!"

I swear if I could I would, but I do not have enough knowledge to do that because I am not a professional programmer, besides, I think there are maybe a lot people in this community like me.

There is nothing worse for the image of a product than the user's perception that it is stagnated or what was left behind to die, being this product open source or closed source one.

Regards,

#2 Sure, you've got good points there. The missing factor: manpower. You suggest regular small releases with thoroughly tested bug fixes. This takes manpower. You can't thoroughly test your own fixes; I should know, I've tried.

How do you get manpower? Ask for volunteers. They've done that, and while some are coming forward to help with adding new features only (as far as I know) Harrison is actively hunting bugs (or at least the pesky ones that rattle the build log).

There isn't enough manpower dedicated to the project to do what you suggest. I'm not saying you're wrong; I'm saying they can't do it even though I'm certain that they'd love to.

There's nothing worse for the morale of a team already stretched past their limits than undeserved criticism. They're doing what they can with what they have.

#3 @Richard,

Sorry, but I'm not criticizing anyone here, but just giving my suggestion to the committee regarding to patch releases; it is up to them to choose to accept or reject it. Whatever the choice of them, it's fine for me.

#4 I think that's a great idea, and a great job to give that useless digit after the decimal place ;). I don't think it would take any more manpower than is being applied already to pull fixes into the master branch. I think Joao was just advocating doing that more often, especially where a pull request has included a significant bug fix.

#5 It is quite easy to move pull requests from the development branch to the master, but does that buy us very much? Without going through an actual QA cycle, wouldn't this just make the two branches equivalent, and remove the need for a development one at all?

I believe what Joao is looking for (and please correct me if I'm wrong) are packaged up versions of the engine that have gone through a QA process, include the latest script reference docs, compiled executables, etc. With v2 and v3 of the engine we were able to stick fairly close to the 3-4 month delivery targets the Steering Committee was attempting to hit. Going through a proper QA Test/QA Reaction/QA Test/Package/Release cycle takes time, and as we were relying on the GarageGames QA department we had to work around their schedule. A 3-4 month target (that gives 3 or four releases a year) isn't too bad for a bunch of community volunteers, IMHO.

So far, since Torque 3D went MIT (just under a year ago), we've managed to have 2 releases. Back in June it was hoped that v4 would have been out by now, but unfortunately that plan has faltered. Around that same time the Steering Committee was reduced to one active person (Mike H) and the search was on for new members. That took a while (over a month) and once the new Committee members were brought on board it has taken another four weeks before the whole team has been able to really meet due to various issues. And as you're about to see in this week's Committee meeting minutes, the Steering Committee has had another blow.

Now I'm thinking out loud here, but one possible way to have more frequent releases is to skip a formal QA process and assume that the community has been testing the development branch (I'm not sure how true that is as for two weeks in August the development branch could not be compiled and no one brought it up). We could then have unstable point releases between the major ones. These releases would include the full package as I believe that is what people are after (otherwise you could just use the development branch right now). That would be things like pre-compiled executables for the templates, regenerated script reference docs, bundled Project Manager, docs on what has gone into a release, etc.

Now here's the catch to this idea: we would need someone from the community to take this on. A "Release Manager" of sorts. I don't believe the Steering Committee as it stands today would be able to take this on. As a Release Manager you wouldn't have the same required time commitments as a Steering Committee member, nor would you have the same responsibilities. Your task would be to get point release packages out on some agreed to schedule.

Is there someone out there that wants to be our Release Manager? This idea will still have to go through the next Steering Committee meeting, but it would be great to know if someone is interested before then.

- Dave

#6 I thought that all pull requests were QA tested before going into development - I understood that the master branch was just a formality that defined the release of the engine. If that's not the case, it certainly should be, IMO. Though obviously some amount of integration testing should be done before pushing to master.

I'd love to volunteer as some sort of release manager, but time commitment is definitely a factor for me. What I will do is see how feasible it would be to set up build environments for several Windows versions, possibly even automated to some degree, along with a docco server. And maybe we can finally make some engine unit tests.

#7

Quote:"...the Steering Committee has had another blow."

Oh, here we go again.

Quote:"I'd love to volunteer as some sort of release manager"

Dan, Dan
He's our boy
If he can't do it
No one....
...will.

#8 How about for people who want all updates and fixes fast to pull the development branch, but with no guarantee and for the average user the normal full packed and tested releases?

#9 @Daniel:
The Steering Committee does test out the specific Pull Request before merging it in to make sure it does what it is supposed to do. However, this isn't the same as regression testing the whole engine. It is amazing how small, innocent changes can sometimes have far reaching consequences.

@Duion:
That's how it works today. You want the latest and greatest version of Torque 3D? Work with the development branch. You want what is considered the latest stable release? Either work with the master branch or download the bundled up package.

To review, if you want the latest and greatest but don't want to deal with Git, do the following:

1. Go to github.com/GarageGames/Torque3D.
2. Click on the drop down in the top left corner that reads "branch: master" and change that to the development branch.
3. Click on the Download ZIP button on sidebar to the right.

With those steps you'll now have the most recent changes ready for you to compile. And if you're looking for a pre-compiled version of the development branch, that's what I was proposing the Release Manager position for.

- Dave

#10 So why do we need more releases then? Maybe we need more communication and tutorials, so people can understand better what is already there.

#11 @Duion:
The reason we've been discussing how to ramp up the number of releases is because people in this thread are asking for it. If this is truly something the community wants, then with my proposal it can happen without impacting anything else. However, in order for it to happen we must move away from "should" and "want" towards "do". If no one steps up then there the proposal will sit.

As for more communication and tutorials: yes, yes and YES! When I was full time on the Steering Committee I had a series of update blogs to keep the community informed of the changes going on in the development branch. With my time now on service work, and the shake-up of the Steering Committee in the Spring and Summer, this line of communication has been broken. It would be great if this was started back up again.

For tutorials: any and all would be great. But again we have to move from "should" and "want" towards "do". Proper tutorials take real time and effort, but that's what we need to get them done.

Personally, I'm not sure what else to suggest. Without people stepping up and making things happen, nothing will happen.

- Dave

#12 @Dave:

With the current scenario of the committee now, with the lack of human resources with the recent leaving of one of its members, the proposal for minor updates for the T3D, it is presently impractical and almost impossible to be accomplished by the committee.

However, in my opinion, never the quality of a program should not be sacrificed for the hurry, if possible, of course.It's better we have a program with a few updates, but working properly than having a program with many updates and many defects (bugs) as well, turning into a nightmare for their users and damaging the image of the software.

Anyway, thank you for your attention regarding my proposal and do not worry about this now, maybe when the moment is more favorable, perhaps you might think about it again.

Cheers,

#13 I think that more tutorials on how the c++ side of the engine and how it works would help. When the average user works with the engine they are using torque script to make everything work. This is great for creating games using the editor and is how it is supposed to be done.If you want more of the community to help make changes and fixes some explanation of what is going on behind the scenes would be nice. It is very hard to understand by just jumping into the source file and reading.

#14 I found this, some youtube channel that says "Torque 3D source code analysis" www.youtube.com/channel/UCehLd8bwYI7YQmmKrstQEsA?feature=watch, is this helpful anyhow?

#15 I started watching that series and it is informative, but you must also listen to some rambling before he gets to a point that he is discussing. In fairness, during the videos he does say that he was making them for personal use. I was thinking more in terms of - this is how torque loads a model or material, this is how torque handles rendering models, primitives, or whatever drawable is to be include in the seen, this is how torque adds animations, etc.

Just some of the basics would help and then I could start to experiment with simple items, add scripting to them, from c++ and getting them in the game in working. Then maybe from there adding physics shapes and constraints. Once a person can understand the basics of what is going on then they can jump into the code and hopefully figure out the rest.

Right now, I just do not see how someone can just take the source folder and just start helping out. Maybe it just takes a more experienced coder.

#16 @Randy Brown

Yeah, its not easy to just jump in and try to figure it out. I should know, that's how I'm learning it. It's fun when you're trying to figure out what something does and you look at the comments in the code and it says. //TODO - Find out what this does

:D

I make my living programming C++ and a lot of JavaScript, so its probably a lot easier for me than someone that has no experience.