[Red5devs] Offer to the Red5 Community: Continuous building

[Art Clarke]

Many points:

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.

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.

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.

- Art

On 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
>
>