After talking with others in the community, I came up with the following
1.3 scope as well as criteria to move forward with a 1.3 release. Sorry
this is so verbose, but there is a lot to consider. Please
review/comment. I hope this dialogue can largely happen on list, but
we'll likely need to use Tuesday's F2F meeting as well.
_Criteria for 1.3 Release _
In order for 1.3 to happen, I propose following criteria needs to be
met. Please put your name beside a criteria point if you relate or
volunteer as a candidate. If we plan to do a code freeze by Sept. 30th,
I *propose we need work through these items by eod Sept. 16th (Friday)*.
-scope needs to be understood and agreed upon. see questions and
stories below (committers and other 1.3 core volunteers).
-merge conflicts between 1.2.x and trunk need to be resolved (see Chris'
email:"Merging back 1.2.x to trunk, please read #proposal")
-all commiters involved in 1.3 commits need to be identified and on
board to help QA and fix bugs. (please identify yourself in thread.
I'll run an svn log as well). imo, "on board" means committers need to
be responsive on a daily basis until QA is complete. If a developer
can't make this commitment, they need to move their commits into a
branch until the release and merge them back into trunk once the release
is cut. Or they need to assess with the release manager and committers
whether their can remain with no impact to 1.3's performance or core
functionality.
-a release manager needs to be identified from an institution planning
to deploy 1.3 (Ruediger?). This person needs to also play the role of
QA facilitator, unless....
-the rm identifies someone to play this role. imho we also need a QA
engineer as well who writes/runs integration or unit tests and performs
load tests. When bugs are fixed without these tests, history will
likely repeat itself.
-QA help from adopting institutions need to be identified. These folks
need to be available to take on assigned QA tasks and complete them
within their designated time period. A release candidate cannot be cut
until all of the tests pass.
-QA environments need to be established (Usask in conjunction with RM?)
-Lastly establish a code freeze date. Sept 30th was suggested we need
to meet the criteria needs before this date is "real".
_Process Questions_
It has been awhile since I built trunk but my first impression wasn't
promising. For example, I tried to schedule a recording and it threw a
404 error after submission. After I return to the main admin screen, it
looks like the recording successfully scheduled. I click on edit, and
another 404 is thrown. As process goes, do we do a round of QA on trunk
prior to cutting the 1.3 branch? This would help us avoid porting
fixes. If the initial branching is considered a release candidate I
would think this is a necessity. Should we consider fixing bugs in
trunk first and porting over to 1.3 rather than our current process?
_1.3 Scope_
I listed some clarifying questions underneath each user story. Am I
missing anything ?!?
*Blocker and Critical Tasks/Bugs that affect 1.2.x, 1.1.x and presumably
trunk*
For the most part, these issues have not been assigned to individuals.
If you are assigned to a critical with fixed version 1.3, can you
confirm that you'll address the issue prior to the agreed upon code
freeze date? Does anyone think any of these deserve more attention than
others? I moved all release blocker issues not assigned to a fix
version to blocker status. Are the release blocker bugs assigned to 1.3
really more important than the criticals? We should take into account
unfinished tasks that if completed would likely have a big impact on QA,
like MH-8092 because it affects both the CA and core. Are they worth it
given our potentially short timeline?
http://opencast.jira.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MH+AND+resolution+%3D+Unresolved+AND+priority+%3D+Critical+ORDER+BY+key+DESC
*Administrative Authorization*
It's not abundantly clear what is available ootb to restrict the
management of recordings. After reviewing the features listed in the
1.3 Authz Requirement docs, I have a lot of questions!
http://opencast.jira.com/wiki/display/MH/Authorization+Work+For+Matterhorn+1.3+%28DRAFT%29
-How does a service determine authority? My understanding is that the
course grained capability to manage recordings primarily come from
specifying access in the series UI which are then propagated to each
recording. The series service contains acls to view/manage and another
set of acls is set in each recording's mediapackage. Does the latter
acls inform each service whether they can provide information to a
specific role or the former? Does one supersede the other?
-Currently there is no way to limit r/w access to a recording unless it
is limited to a series. Is this a shortcoming of the architecture or is
capability simply not exposed in the UI yet? If a user uploads
something without a series, do they still have r/w access to it within
the admin UI? How is it restricted for personal ownership? How is this
expressed in the mp xacml?
-If the series is restricted to "view" for a specific role, will the
series UI still display the edit link or does it adjust based
view/manage access? Same applies to the rest of the UI. If the user
has read access but not write access, are they able to view the workflow
instance filters? Will the UI still show the edit links, etc.
-Are workflow definitions limited by role?
-there is currently a hidden "users" tab. Is this UI currently limited
by series, or can anyone with admin privileges access it? If it is
restricted by series, what kind of role can use this tab and how is it
limited? Can they associate any user with any role? Is there a simple
way through spring security for 1.3 to limit this tab to the super admin
role?
-in the case where users need to be provisioned to matterhorn because
their local roles aren't sufficient for matterhorn, how does matterhorn
deal with campus sso?
-the super admin role does not appear in the users tab. where is this
role established?
-is the creation of series restricted to super admins? if not, how is
it determined which roles/users the user can associate with the newly
created series?
-it appears that an ootb demo_capture_admin role is given to the super
admin. what if you want to assign the capability to schedule capture
agents to everyone in a specific department. Would you need to give
each user this role? For some reason I had conceptualized assigning
arbitrary roles to the CA instead, but I guess this works.
-does the CA have to be assigned a series role to successfully ingest a
mediapackage associated with a series?
-under processing, it is stated that only admin roles can using
processing service directly. Does this mean that a user with a
non-admin can still initiate a workflow containing processing services,
but they can't call the service rest end points directly? I am thinking
along the lines of personal content. Would there be a personal admin role?
-how is ingest limited via the inbox? is the user required to include
an xacml there is no series? How does the system know they're a user
associated with a trusted role?
*MH-8128 "HTML 5 player plugin"*
-considered an easter egg unless there are resources to write up
documentation and provide supporting workflows+encoding profiles.
-are there any limitations to this plugin vs. the flash player?
*MH-177 "As a learner I want to tag interesting events in the media with
kewords to find them be later and help others to notice this events"*
-does the annotation service incorporate authorization? for instance,
can you limit comments to users within your series?
-are comments plain text or can you add html links or other content?
-it appears from the comments.mp4 that comments can be added via the
timeline, spatially, or directly under the comment tab. Under the
comments tab, the comment listing doesn't differentiate these comment
types. How does the user know when I comment isn't tied to the timeline?
-is the commenting feature only in flash can it be reused in an html
player? is it "accessible" (keyboard navigation and screen reader)?
*MH-8005 "As a user i want to find and use Matterhorn recordings on my
mobile device"*
-does it incorporate authn/authz or does it only display published
public content available via the engage search service?
-considered an easter egg unless there are resources to write up
documentation and provide supporting workflows+encoding profiles.
*MH-8084, MH-8131 "The Episode Service"*
-does the episode service incorporate authorization?
-my understanding is that the episode list in the UI mockup represents
recordings not workflow instances. If so, workflow info like the
"process column" should be removed in light of this, as there is already
a place to review workflow instances. This makes sense especially if
simultaneous workflow instances are running against the same recording.
-aside from referring to the workflow instance filters, it might be
helpful to know which workflows were formally run against each
recording and what their status was (failed, finished, etc) within the
episode UI. Otherwise users will need to refer to the Finished and
Failed tab as the source of authority for formally ran workflows when
determining which workflows to run in the episode context. Not a big
deal but a nice to have.
-it's unclear why actions are displayed in this context if the list
represents recordings. I see no harm in a view page per recording, but
actions should be dependent on the chosen workflow. If edit were
available for a recording without choosing a workflow, how would changes
to its metadata impact associated "running" workflow instances? Would
edit be turned off in this scenario? Even if no workflow instances were
currently running, it seems like the edit action should prompt other
actions like redistributing the recording. Aside from view and edit,
I'd think other actions would derive from hold states, and would make
most sense within the context of the workflow instance filters.
-If a workflow is chosen and it needs options set prior to initiation
(i.e. flavor identification) will the user be presented with required
options prior to worfklow initiation? I could see a scenario where the
user originally ran the default workflow with a subset of avail options
and later they want to run the same workflow with other options chosen.
In the context of the episode UI, it might make sense to have granular
workflows in place that don't rely on options.
-which date is represented in the date column? upload date? creation date?
*MH-7779 OAI-PMH Repository Provider*
-All of the tasks remain open. Is this ready to go? Any documentation
available?
*MH-7903 Load test Matterhorn to determine how it scales in both
processing and playback*
-Any documentation? What should adopters expect to do with these? The
"Workflow Load Tests" page is sparse. Was this the intended page for
documentation?
*MH-7882 Enhance Matterhorn User Tracking System*
-Any documentation? How does an adopter access this information? Is
there a UI?
*Upgrade Path from 1.2 to 1.3*
There was agreement to provide this but I didn't find any assigned tasks.
*Confidence monitoring, Updating StudIP integration, Sharepoint
integration, Admin UI fixes *
Other items listed on roadmap that don't have any information associated
with them, all attributed to Osnabruck.
-Any documentation? Scope statement? Jira stories/tasks?
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
