Also worth mentioning is the discussion during the dev meeting about eventually pushing workflows to the "gear shop" but since this is still in a "concept" stage the agreement was made to propose the available wiki.
There was also a discussion about how to test the workflows but for now there doesn't seem to be anything "easy" way (which for me means automated) and the result is what Tobias already pointed out that is workflow that are part of out the box installs that are not working. In other words workflows that are not tested/approved should not be distributed. One way or another I can safely say that having _known_ broken workflows part of a default install is not helping adopters, by default one will expect such essential part to be working and when a workflow fails the first assumption will be of a misconfiguration not an out of the box dysfunctional workflow. When thinking about other "workflow" based applications that have arrived at a stable GUI based workflow configuration (e.g. Jenkins) the typical out of the box number of workflows you get is: 0. Ultimately what matters to the adopter is not so much a default functional workflow in the out of the box install than actual documentation on how to construct her own *and* that the documented pieces available for the construction (the operations and handlers in Matterhorn nomenclature) are also working as expected. J. On Sep 19, 2012, at 11:43 AM, Tobias Wunden wrote: > Hi Rüdiger, > > I can see your point. However, having the workflows in the wiki will make it > much easier for adopters to keep them up to date (and contribute > improvements) than if they are in the source directory, because it's much > easier to get access to the wiki than becoming a committer, which may not > even make sense to them. From my experience, developers are running one and > the same workflow over and over, which is why most of the workflows in there > are not maintained, leading to frustration on the adopters side because there > ist stuff there out of the box that is not working. > > Tobias > > On 19.09.2012, at 10:33, Ruediger Rolf <[email protected]> wrote: > >> -0 >> >> I don't see a benefit in moving the workflows somewhere, where they will not >> be tested for sure and will certainly deprecate. When they remain in the >> distribution they can be part of the QA. >> >> On the otherhand I would see a benefit of a good documentation of every >> workflow in the wiki and how these can be connected. But simply putting the >> workflow into the wiki will not help from my point of view. >> >> The next question would be, what the default workflow definition will >> contain? Will we add as many workflows to this file as possible? >> >> So I am not opposing this but I would say that we need some more clarity on >> what will be done here. >> >> Rüdiger >> >> Am 18.09.2012 17:51, schrieb Tobias Wunden: >>> Hi all, >>> >>> at the developer meeting we discussed that it makes sense for Matterhorn to >>> be shipped with one working and documented workflow only instead of many >>> workflows, most of which are not working since barely used. Instead, the >>> #proposal is to put additional workflows into the wiki. >>> >>> The respective ticket has been created at [1] >>> >>> Tobias >>> >>> [1] http://opencast.jira.com/browse/MH-9187 > _______________________________________________ > 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] _______________________________________________
