<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>On 18 Mar 2014, at 01:32, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:</div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div>To further this lets continue working on <a href="https://etherpad.openstack.org/p/taskflow-mistral">https://etherpad.openstack.org/p/taskflow-mistral</a> and see if we can align somehow</div></div></blockquote><div><br></div>Sure.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div> (I hope it's not to late to do this,</div></div></blockquote><div><br></div><div>Never late IMO.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div> seeing that there appears to
 be a lot of resistance from the mistral community to change.</div></div></blockquote><div><br></div><div>Could you please let us know how you made this conclusion? Im frankly surprised.. Its not just my curiosity or something, I want to keep improving in what Im doing.</div><div><br></div><div><br></div><div>Generally, just to clarify the situation let me provide our vision of what were doing at the very high level.</div><div><br></div><div>As mentioned many times, were still building a PoC. Yes, it turned out to take longer which is totally fine since weve done a lot of research, lots of coding exercises, talks, discussions with our customers. Weve involved several new contributors from two different companies, they have their requirements and use cases too. Weve gathered a lot of specific requirements to what should be a workflow engine. This all was the exact intention of that phase of the project: understand better what we should build. If you look at Mistral list of blueprints youll see around 40 of them where 80-90% of them come from real needs of real projects. And not everything is still captured in BPs because something is still not shaped well enough in our minds.</div><div><br></div><div>Thought #1: <b>In POC weve been concentrating on use cases and requirements. Implementation has been secondary</b>.</div><div><br></div><div>TaskFlow or anything else just hasnt mattered a lot so far. But, at the same time, I want to remind that in December we tried to use TaskFlow to implement the very basic functionality in Mistral (only dependency based model). Honestly, we failed to produce a result that we would be satisfied with since TaskFlow lacked, for example, the ability to run tasks in an asynchronous manner. This was not a problem at all, this is the real world. So I created a BP to address that problem in TaskFlow ([0]). So we decided to proceed with it with an intent to rejoin later.</div><div>And may be even the most important reason not to use TaskFlow was that we did want to have a clear research. We found that less productive to try to build a project around an existing library than concentrating on use cases and high-level requirements. From my experience, it never works well since in your thinking you always stick to limitations of that lib and assumptions made in it.</div><div><br></div><div>So we actually talked to people a lot (including Josh) and provided this reasoning when this question raised again. Reaction was nearly always positive and made a lot of sense to customers and developers.</div><div><br></div><div>Thought #2: <b>A library shouldn't drive a project where its used.</b></div><div><br></div><div>Project needs should define the requirements to a library. Even being adopted in lots of places (this is apparently not true for TaskFlow right now which is fully understandable, a pretty young project as well) a library is just one of many tools used within a project. But not vice versa.</div><div><br></div><div>Thought #3. <b>We 100% admit were not ready for incubation right now</b>.</div><div><br></div><div>We prepared an incubation request already with most of the formal requirements met by the project. And even thought the interest to Mistral is serious (at least 5-6 projects intent to use it, one already started playing and prototyping with Mistral) we want to be honest with the community in that were not really ready for incubation since even our own solid understanding of core requirements and API/DSL is only on its way. This is just one more argument that spending significant time on thinking how to fit TaskFlow into our unstable Mistral vision is not affordable for us at the moment. Despite of that, last week we started spending that time after Josh started bombing us with his concerns :).</div><div><br></div><div><br></div><div>If thats all harsh, sorry. Were interested in keeping in touch with Josh and others.</div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/taskflow/+spec/async-tasks">https://blueprints.launchpad.net/taskflow/+spec/async-tasks</a></div><div><br></div><div><div apple-content-edited="true"><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div></div></div></div></body></html>