Thanks Tobias. Taking what I gathered via conversations and from
responses to this thread I'll post a separate email listing what I
perceive is the 1.3 scope to help move things along. The following is
in response to your email.
_
Identify Adopting Organizations Per Release_
It's not clear which organizations needs 1.3 and what is the official
code freeze date. It would be useful to understand who is interested in
deploying 1.3 and what features drive their interest. Obviously the
more institutions committed to a specific release the more likely
resources will be dedicated to make it a success.
I propose we track adopting institutions per release. I added another
column "Adopting Organization" to the Matterhorn Road Map so that we can
track adopting institutions interested in a specific feature. If an
organization is listed under a specific feature as an "Adopting
Organization", it implies that they are committed to deploy the related
release. I'm not sure how to gather this information, but I'll likely
send a separate thread to opencast, users, and matterhorn lists asking
folks to look at the Road Map and identify themselves as release
adopters. I'm not sure how we would qualify delayed adoption like what
Greg had mentioned. My hope would be that we could leverage adopting
organizations to at least be part of the QA process, but if their
adoption of a release is a semester off they may not be as motivated.
_Alignment of Contributing Organizations and Adopting Organizations_
I propose at least one of "Contributing Organizations" should also be
listed as an "Adopting Organizations". otherwise there is a disconnect
between development work and the steps necessary to make it production
ready. If this disconnect exists, imho the feature should be bumped up
to a release/date relevant to at least one contributing organization.
As we discussed awhile back, if contributing organization working on a
specific feature for a specific must provide resources to QA and bug fix
the feature until the final release is cut. If they fail to get the
code production ready, they're responsible for rolling it back. This
applies to patches and general bug fixes as well.
_UC Berkeley's and OIPP Potential Deployment Schedule_
UC Berkeley will deploy a local 1.2.x variant this fall which will
include YouTube/iTunes distribution. Due to significant resource
fluctuations this deliverable will not be ready for Matterhorn by 1.3.
We had to take some short cuts to get it ready for our special events
program in the fall and it is not acceptable for trunk. It is however
available in our msub for anyone to download. We intend to have it
ready for 1.4 assuming its within a January time frame (scope is
available from Road Map) for the expansion of our pilot. Since our Fall
pilot is fairly low key, we will strongly consider upgrading to a
maintenance release mid-semester if major stability and/or performance
problems (many of which are currently under analysis) are identified and
resolved.
On the other hand, UC Berkeley is involved in an effort, Online
Instructional Pilot Project (OIPP), to establish a common distance
learning environment for the UC system. We may need the annotation and
authorization features coming from 1.3 or possibly some variant for
1.4. This could involve some integration with Sakai OAE and could
result in some Sakai instructional/student admin contrib tools.
Aside from the additional information in the road map, it might be
useful for other organizations to give a brief summary of their
deployment schedules. Perhaps I'll include that in my call for release
adopters?
On 8/15/11 11:56 PM, Tobias Wunden wrote:
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]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
