[Red5devs] Offer to the Red5 Community: Continuous building
Art Clarke
aclarke at vlideshow.com
Thu Oct 2 12:20:15 PDT 2008
With the exception of the one test mentioned below, I have sent
patches to Jira that get all other 130+ tests to run:
http://jira.red5.org/browse/DT-4
Thijs, if you could let me know about the account for the build server
I'd set that up to at least auto build while I wait for people to
review my commits?
Enjoy,
- Art
On Thu, Oct 2, 2008 at 10:11 AM, Art Clarke <aclarke at vlideshow.com> wrote:
> Hi folks,
>
> Quick progress report and a question: We now have 96% of all existing
> JUnit tests passing successfully all of the time with tip of tree (out
> of 126 tests still enabled; I removed some invalid tests and added a
> few new ones). I'll submit the patch later today (will do sooner if
> people would rather see the changes to get 96% rather than waiting for
> 100%).
>
> However, I am running into a lack of understanding on my part with one
> of the AMF-IO tests. In particular, a test that serializes an object
> with a circular reference and then deserializes it fails
> (AbstractIOTest.java#testCircularReference). Why? Because the AMF
> reference ID it writes to the stream for the self-reference is being
> adjusted by -1 by the following code when deserializing, but there is
> no equivalent adjustment when serializing:
>
> org/red5/io/amf/Input.java: 562-568
> public Object readReference(Type target) {
> if (referenceMode == ReferenceMode.MODE_RTMP) {
> return getReference(buf.getUnsignedShort() - 1);
> } else {
> return getReference(buf.getUnsignedShort());
> }
> }
>
> I've been through the AMF specs and can't figure out why we're doing
> this. However, this code has been in the tree since Joachim's initial
> AMF3 implementation:
> http://code.google.com/p/red5/source/detail?r=1660&path=/java/server/trunk/src/org/red5/io/amf/Input.java
>
> So I'm assuming that the test is wrong and the server code is right,
> but does anyone know why this behavior would be occurring (i.e.
> adjusting the AMF's reference ID by -1 when deserializing, while not
> doing a +1 when serializing)?
>
> Any suggestions/tips appreciated.
>
> - Art
>
> On Wed, Oct 1, 2008 at 12:31 PM, Thijs Triemstra | Collab
> <lists at collab.nl> wrote:
>> Hi Art,
>>
>> I'm happy to do this as patches (although a sandbox area is a lot
>> easier for me and keeps traffic off the devs list while I do it; still
>> not a big deal). Another suggestion I have is if someone on the red5
>> team wants to be a point person for me I can go through them on
>> submissions and avoid polluting the lists with interim patches.
>>
>> Please post the patches in our bugtracker on http://jira.red5.org to avoid
>> 'polluting' the list.
>> We now have a dedicated mailinglist for the red5 tickets which you'd might
>> want to subscribe to:
>> http://groups.google.com/group/red5tickets?hl=en
>>
>> That said, I disagree that continuous builds aren't really useful
>> already for three reasons:
>> First: it did allow us to catch a bug that's been ignored for
>> 13-days even with existing tests (ok, admittedly the tests I'm talking
>> about checking in).
>>
>> ;)
>>
>> Second: if we don't have anyway to enforce 100% test running the
>> existing tests will fall out of compliance quickly.
>> Third: Having it sent up might encourage some folks (like, I don't
>> know, maybe Robert and me) to submit tests as a best practice for any
>> bugs we fix as part of our submission process. How's that for
>> enticement?
>>
>> Thijs, can we take offline the generous offer of the ubuntu server?
>> I'd love it. My e-mail is aclarke(at)vlideshow.com. I would also
>> prefer to set this up initially there (I agree it's much more reliable
>> that way, plus it keeps non-donated code out of the question). To get
>> this to work no long-term root access is needed, but I will need a
>> user account (I usually use 'hudson' for the continuous build), I do
>> need to be able to bring up red5 on that server, so other applications
>> should not be using ports 5080 and 1935 on that machine, and I will
>> need to install hudson to run on startup on a given port (which you
>> can specify). Still, probably better to take this offline.
>>
>> Sounds good, I'll email you offline (that server in question isn't using
>> port 1935, and if it did I could add a new dedicated IP for this builder.
>>
>>
>> As for AsUnit, the trick is how to include the AsUnit ActionScript
>> without infecting with GPL. In our build system here we have the
>> source code for AsUnit checked into a tainted tree, and then we
>> compile the .as files for AsUnit directly into the resulting test swf
>> file from there. What I'll do for now is create something similar to
>> a red5_example application that does everything and then send the
>> patch to the list. This will be a big patch once I get to it. We can
>> then figure out iteratively the best way to integrate it.
>>
>> Sounds good..
>> Thanks,
>> Thijs
>>
>> n Wed, Oct 1, 2008 at 11:57 AM, Thijs Triemstra | Collab
>> <lists at collab.nl> wrote:
>>
>> Hi Art,
>>
>> Option A) I'd like a continuous Red5 build server that rebuilds the
>>
>> server whenever a check-in occurs and e-mails the person who checked
>>
>> in last if the build fails.
>>
>> Option B) I'd like someone to go through the "ant run-tests" tests and
>>
>> make them all run successfully
>>
>> The lack of unit tests has been an issue in Red5 since day one, and it's
>>
>> unlikely 'someone' will fix it. And continuous builds aren't really useful
>>
>> when there aren't any unit tests imo. Patches are always welcome! I think
>>
>> unit tests are more important then documentation at the moment.
>>
>> Option C) I'd like to have the continuous Red5 build server also run
>>
>> the Java tests and let folks know if they succeed or fail
>>
>> Again, there aren't (sufficient) unit tests to make continuous building
>>
>> useful.
>>
>> Option D) I'd like a set of standalone flash-based (not RTMP-Client)
>>
>> unit tests that test connecting to the server, playing back video
>>
>> files, publishing files, and calling a method on objects, as a way to
>>
>> do minimal end-to-end validation of a check-in.
>>
>> Option E) I'd like the continuous build server to execute those
>>
>> flash-based tests in a headless (i.e. no windows) environment
>>
>> Option F) I'd like world peace.
>>
>> :)
>>
>> Option G) I'd like the continuous build server to auto build of the
>>
>> javadoc for the server
>>
>> Good idea. We could do the same for nightly builds. I prefer buildbot
>>
>> (http://buildbot.net) but this might be less useful for java apps..
>>
>> If we end up decided to do any of these, all I ask for right now is a
>>
>> sandbox area I can check code into (asked for username: aclarke). If
>>
>> you want grimy details on what I'm proposing, please ready on.
>>
>> I think it would be best to start out with supplying patches, and posting
>>
>> them on Jira. As soon as you start overwhelming us with patches, and it
>>
>> becomes a 'burden' for us, then commit access sounds like a good idea.
>>
>> <h2>Option A:</H2>
>>
>> Our continuous server is based on Hudson
>>
>> (https://hudson.dev.java.net/), and already builds and e-mails us if
>>
>> the red5 build breaks. What I'm suggesting is that someone let me
>>
>> know the e-mails to add to the distribution list, and I'll make it
>>
>> send e-mails there as well when builds break. I can also provide
>>
>> login-accounts for people to browse the hudson server, and will try
>>
>> initially setting it up so anonymous users can see the results of
>>
>> builds (but may need to curtail that if load is too high: Right now
>>
>> this would be hosted off our dev-server (which is a Fedora 8 box
>>
>> sitting in my apartment) but if folks have a Linux environment that
>>
>> they wanted to volunteer I'd be happy to talk offline about making a
>>
>> more "hardy" version).
>>
>> I would be able to provide a ubuntu server that lives in a data-center. A
>>
>> dev-server in an apartment doesn't sound like a good long-term solution.
>>
>>
>> <h2>Option B</h2>
>>
>> This will require some work but I think it's valuable. Right now
>>
>> (after fixing the build file to compile the tests) 64% of unit tests
>>
>> pass. My proposal is that we at Vlideshow go through the unit tests
>>
>> and get us to 100% by either (a) fixing the test (preferred) or (b)
>>
>> removing the test if it's beyond our ability to fix right now (I'll
>>
>> e-mail any such cases to the list).
>>
>> Sounds great. Again, please post patches to Jira so we can evaluate them.
>>
>> This option is a little tricky as asunit is GPL licensed. What I'm
>>
>> proposing is that we make a top-level source directory
>>
>> svn/test/flash/trunk/autotest/ and in there we'd put our source code
>>
>> as well as a reference to ASUnit. This part of the tree would be
>>
>> GPL-infected, but by organizing it in this way we can assure that
>>
>> people only get GPL-infected if they decided to go into this area.
>>
>> You can release the unit tests under the LGPL, like the rest of the
>>
>> codebase, and still use asunit afaik.
>>
>> Thanks for the help!
>>
>> Cheers,
>>
>> Thijs
>>
>> _______________________________________________
>>
>> Red5devs mailing list
>>
>> Red5devs at osflash.org
>>
>> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>>
>>
>>
>> _______________________________________________
>> Red5devs mailing list
>> Red5devs at osflash.org
>> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>>
>>
>> _______________________________________________
>> Red5devs mailing list
>> Red5devs at osflash.org
>> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>>
>>
>
More information about the Red5devs
mailing list