Ruben, your assumption is correct. If you submit a new feature, which doesn't work, and you (or somebody else) doesn't get it fixed in time for the next release candidate, it will be removed / deactivated.
Tobias On 14.03.2012, at 16:28, Rubén Pérez <[email protected]> wrote: > I wasn't at the meeting, but I guess that means that if you add a new feature > to the code you have also to commit to have enough resources (yourself or > other developers who know about that feature) to fix any bugs that may arise. > It's not sufficient with implementing a new feature, check it does not break > the builds, and then disappear. :P > > Anyway wait for others who actually attended to explain it better. > > Regards! > > 2012/3/14 Micah Sutton <[email protected]> > +1 from me. I agree that faster cycles means that pushing off a feature to a > latter release isn't as painful. > > I do have one question about the 3rd point: > > On Mar 13, 2012, at 5:01 PM, Tobias Wunden wrote: >> >> 3) Only features that have resources attached to fix arisign issues may be >> merged > > Could you clarify this point a little bit? > > > _______________________________________________ > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
