-
Notifications
You must be signed in to change notification settings - Fork 23
HowToContribute
You don't need to be an expert dev to contribute, here a list of tasks where you could contribute and help us tremendously.
See Contributor Jobs for easy contributing tasks.
- Don't underestimate the Redtamarin project
something that may seem "simple" could end up
being extremely "complicated" to implement- take the time to familiarise yourself with the project
build from sources, generate the documentation, understand the ant build, how to test the runtime, how to test AS3 code in the runtime, etc. - understand the toolchain
this is about the command-line, using compilers and other tools
things are a bit more harder and raw than in the Flash/AIR world. - respect the goal and direction of the project
don't try to convince us to go into another direction
it will simply not work and we will show you the "fork" button.
- take the time to familiarise yourself with the project
- It is about trust
you have to make the effort for us to trust you
and to do that you need to listen, understand and probably learn- about working inside an open source project
we accept anyone but you have to learn "our ways" - about working with others
mainly the benevolent dictator which is me
I try to be nice and welcome anyone but like any
other human being my patience can run thin - about respecting the work that has already been done
you may discover this project just now
but this project exist for 8 years
eg. we have very good reasons to do things a particular way
- about working inside an open source project
- It is about source code
sure we can talk, argue, whatever about how this or how that, but at the end of the day what really matters is the code- the "source code" is everything related to
the build, the C/C++ sources to compile the runtime, the AS3 implementations, the comments/documentations asdoc in the code, the documentation/wiki, etc. - contributing is about adding/removing/changing to this source code
- you have to understand the direction to be able to contribute
- nothing is too small
it's not about how hard or complicated the contribution is,
but more how it fit well with the global need and direction of the project
- the "source code" is everything related to
If you never worked with an open source project before, learn the basics of checkout, commit, merge, pull requests, diff, patch, etc. — we can not do that for you.
Favor small changes first, anything between 1 line to 10 line of code or comments is good, it allow us to quickly review it, quickly interact with you, etc. — it is basic but it can not be ignored, it is how you gain trust as "OK this person know how to work inside an open source project".
Small changes is the only way you will get to do big changes, we will never accept big changes out of the blue from someone we don't trust or have worked with before.
For example, just downloading and installing one of the deb packages in our releases, and let us know it works (or doesn't).
It's very easy, you just need a bit of time and open an issue to tell us for example
"hey I tested the the install of redtamarin-sdk_0.4.1_win32.deb on My Windows 7 32-bit and it worked"
Ideally, the more you can tell us about the system: OS version, CPU speed, amount of RAM, etc. the better.
TODO (post a small script to test and diagnostic an install)
There are plenty of improvements that could be done in the documentation.
Especially the asdoc, and yes it could be seen as grunt and daunting work, but literally anyone can do it:
- correct our english errors
- improve the doc with small examples
- add asdoc comments if they are missing
- this is important work and it show you care about the project
we will not ignore it or look down on it, quite the opposite
It does not have to be only asdoc, it could also be wiki or tutorials, etc.
TODO
We have 3 API layers
- the C API
- the Native Redtamarin API
- the AVMGlue API
In any case, if you want to do such contributions
- you will have to do small contributions first
this is mandatory, we can not accept big hunk of native code from someone we don't trust yet - you will have to show us that you understand the direction of the project
native implementations can go in 1000s of directions, we can not follow all of them - you will have to do the effort to provide cross-platform implementations
HAVE TO work for Linux, Mac OS X and Windows (unless very specific case)
This is extremely hard work, don't think you can just jolt into the project and contribute about anything you fancy.
Please consult Mozilla Bugzilla for Tamarin.
Even if we are working with the AVM2 code base, we are mainly adding native API.
Our goal is to stay compatible with Flash Player and AIR and ActionScript 3.0 in general.
Some of the Bugzilla Tamarin bugs could have been already patched privately by Adobe, in order to stay compatible with their closed source runtimes (Flash Player and AIR) we may need to go into those reported bugs in Bugzilla and apply our own fixes and patches.
Here some examples:
Bug 475438 - flash.utils.getQualifiedClassName is missing
we already implemented this in getQualifiedClassName.as
good to note is one comment
anything in the flash.* namespace doesn't belong in the avmplus/core area
for that Redtamarin have a different opinion and direction
Bug 775260 - debug condition/mutex calls are too verbose, should disable DEBUG_CONDITION_MUTEX
this is also a "bug" or something we would like to change for Redtamarin
In any cases, the general approach would be
- first, confirm the bug
is it still valid/applicable in Redtamarin code base? - second, replicate the bug
essential for testing and fixing - Create an issue
refer to the bugzilla bug number and link
provide comments/plans/explanations/etc. - after discussion
either provide a pull request or patch
No project is perfect, bugs happen.
But the classic "it does not work" comment is kind of useless to us, we do need more details.
Is it ASC, MXMLC ? something else ?
and if so, from which SDK ? the redtamarin-sdk? the Flex SDK? which version?
We need to know this kind of details to be able to replicate the bug.
If you try to execute some AS3 and it dos not work, we also need the code.
You don't have to provide the whole source code of your program but you will have to at least isolate and show us the part that is generating the error.
Again, we need to be able to replicate the bug in the same condition you experienced it.
Your operating system, the version, the architecture, etc.
Did it happen while running as3shebang, redtamarin, a projector, or one of the redshell ?
or Submitting Patches.
Our main repository is under Subversion, and we use Github as a mirror.
But we made it in such a way that we can take in Github pull requests.
If you can not submit a pull request we will also accept a diff file submitted as an attachment of an issue.
There are small and big patches, in all cases we need to be able to test them before integrating them.
If you did not communicate with us, if your patch is too big and coming out of the blue, it is unlikely we will integrate it.
If you don't communicate, you may spend a lot of time working on a patch that will be rejected because it does not align with what is planed for Redtamarin.
For example:
you may find it cool to do GUI rendering under OpenGL and so submit a patch to do that.
We will not be able to accept such patch as it is not Redtamarin goal to do GUI rendering.
If your patch is too big, meaning you worked on it in isolation and ended up adding/updating/deleting a lot of files from Redtamarin.
Even if your patch could be a great contribution, if you drop it on us out of the blue we could simply reject it as it is way too big to review.
For example:
you may want to add support for another platform like Solaris.
And so you work on porting all the VMPI during the next 6 months without communicating with us about your plans.
If you do that, it is almost guaranteed your big patch will be rejected.
Please do favour communication and as much as possible small iterations.