[Red5devs] Offer to the Red5 Community: Continuous building
Thijs Triemstra | Collab
lists at collab.nl
Thu Oct 2 12:47:47 PDT 2008
Thanks for all the patches Art! I'll follow up on your email offlist.
Cheers,
Thijs
On 2 okt 2008, at 20:20, Art Clarke wrote:
> 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
>>>
>>>
>>
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20081002/44386a87/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://osflash.org/pipermail/red5devs_osflash.org/attachments/20081002/44386a87/attachment-0001.bin
More information about the Red5devs
mailing list