Hi all,
A few things to report from our weekly dev meeting. Please reply if you
have questions or disagree.
-Sept. 30th for 1.3 code freeze.
-Our releases are no longer scope driven. All of the features listed
below will need to be ready for QA by that time. If developers don't
think they will be able to meet this date, they'll need to switch off
their feature or remove it from the 1.3.x branch. This process will
need to be defined by the release managers.
-Greg Logan (University of Saskatchewan) and Rudiger Rolf (University of
Osnabruck) have volunteered to be co-release managers! They will send
out release details and requirements need to make a contributed feature
"QA ready".
-The release managers will help lead the discussion on what "QA ready"
means. Does the code need unit/integration tests to fulfill this
status? If so, is it the RM's job to confirm it does?
-Chris Brooks is leading an effort to merge 1.2.x into trunk. This will
be done before the 30th.
-I still think we need some clarity on 1.3 deliverables. I encourage
committers to consider the following questions when formulating their
documentation and FAQs. A deeper understanding of these deliverables
will help potential adopters decide whether they want to participate in
the 1.3 release.
-We should take the next adopters meeting as an opportunity to corral
the troops for QA testing.
On 9/9/11 12:33 PM, Adam Hochman wrote:
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
*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]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
