Hi Adam, I agree with your assessment, and second your proposal to review the 1.3 roadmap.
However, I do not think that twe should consider moving away from the timeline. There was (amongst others) one very good reason to it, which I think is still valid: Giving institutions a way to do their upgrade planning, which is only possible if we as a community manage to get our releases out in a timely fashion. In addition, as more and more vendors step into the market basing their products on Matterhorn, it is of great importance to provide a decent amount of reliability in terms of release planning. So far, we have not been great at that, but I think if we learn our lessons, it will be possible to improve by quite a bit in the near future. 1.3 with its likely lack of lots of new features will give us a great opportunity to streamline, test, practice and document our release process. There are many things that we need to get right, including - Proper assignment of resources and responsibilities ahead of the release process - Determination in disabling features that fail to work for two consecutive release candidates (as proposed at the Chicago meeting) - Further improvements on automated testing Tobias On 16.08.2011, at 02:21, Adam Hochman wrote: > Hi all, > We had originally discussed releasing 1.3 at the end of September, but I > think that time line is too aggressive. It would be helpful to clarify what > folks are working on, the scope of their projects, and when they they'll be > ready to get their code production ready. We had originally started a list > of Release 1.3 efforts on the Matterhorn Road Map page, but this page is > fairly basic and potentially out of date. > http://opencast.jira.com/wiki/display/MH/Matterhorn+Road+Map > > I was going to map out what I thought was in scope, and what institutions and > resources were involved and their project's latest status, but before I take > on that difficult task I'd like to give the primary sources the immediate > opportunity to inform the list about their efforts. > > That way we can identify and align resources around QA and Release and assess > whether our current time line makes sense. This will help us determine > whether projects in trunk will need to be branched, and potentially identify > the need for more dev resources to ensure strategically important projects > happen within our given time frame. > > Thanks in advance for sharing. > > Adam > Matterhorn Community Liaison > _______________________________________________ > 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] _______________________________________________
