[Red5devs] Offer to the Red5 Community: Continuous building

Wed Oct 1 12:31:28 PDT 2008

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20081001/bc1b38e9/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/20081001/bc1b38e9/attachment-0001.bin 