On 4/17/2012 8:58 AM, Tobias Wunden wrote: > Hi Chris, > >>>> It would be a good idea too to separate the CA release cycle from >>>> the core release cycles. It would probably help to get the APIs >>>> more stable. And the CA has other milestones like th release of a >>>> new Ubuntu version, that the Core system. Unfortunately this would >>>> probably mean that we would need a release managment for the CA too >>>> and we would need a QA phase for this. Another pro would be that >>>> testing the CA and the core can be more focused than, as we don not >>>> need to evaluate the whole system. >>> >>> I agree. >> >> I don't agree with this until our QA process is more clear. At least >> right now we test a 1.4 agent against a 1.4 core. If we separate them >> I don't know what it would mean to have a 1.5 agent - it might just >> work with nothing. >> >> In principle I agree, but until our QA practice catches up I don't >> think we can afford to separate them. > > Absolutely correct. I think we are on the same page that at some point it > would be benefical to separate the capture agent more from the core in terms > of source code and build procedure. But we also agree that this needs to be > properly planned, involving good practices around versioning, QA and testing.
I don't see the advantage in separating the release cycles. Heck, I see more disadvantages than anything else. When they're in lock step we will be able to effectively force testing of the CA (since we can just hold the release until all of the tests pass), but once they're decoupled we end up with a mess where the core gets released by the CA isn't ready. Or we end up having to test multiple versions of the CA vs multiple versions of the core. What do we get by breaking this into two projects? More overhead, and testing. I think that rather breaking things up we should move the CA onto a more stable platform (eg: Debian) with a release cycle that's much slower and long term. G > Tobias > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ > _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
