[Red5devs] Offer to the Red5 Community: Continuous building

[Thijs Triemstra | Collab]

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