Hello, I don't think we need to release the server or workbench to consider graduation. I think Taverna is ready now. We don't want to hover in that perpetual state of "just one more bit of functionality" (you know like you always wait to buy a new laptop or phone because the next version has the new widgetron that makes life amazing). I guess in a nutshell the workbench is the UI that can be used to design and run workflows interactively rather than via the command line. The server allows you to run workflows on a remote machine. I think the current code gives enough of the functionality that we should just go for it :)
Cheers, Ian On 11 August 2016 at 16:46, Gale Naylor <ga...@noventussolutions.com> wrote: > Thanks, Donal, for the description of Server issues that need to be > addressed. > > On Thu, Aug 11, 2016 at 8:45 AM Gale Naylor <ga...@noventussolutions.com> > wrote: > > > I was thinking it would make sense to fill out the Graduation Maturity > > Assessment ( > > https://cwiki.apache.org/confluence/display/TAVERNADEV/ > 2016-03+Taverna+Graduation+Maturity+Assessment) > > and then evaluate where we think we are relative to graduation. > > Interestingly, at least the way I read the maturity assessment, it's > geared > > more towards process and structure (also important) rather than released > > content - specifically, it doesn't mention how much of the code we want > to > > release and doesn't mention soft goals, such as engagement. > > > > Perhaps we should add something about released content to the assessment? > > > > Shall we plan to release the Server and evaluate engagement at that time > > (with an eye toward graduation) or do we think we need to release the > > Workbench as well? (Are we talking user engagement vs developer > > engagement?) I'd love to know what specific user functionality is added > > with the Server and what will not be available until we release the > > Workbench. > > > > Gale > > > > > > > > On Wed, Aug 10, 2016 at 7:56 AM Donal K. Fellows < > > donal.k.fell...@manchester.ac.uk> wrote: > > > >> On 08/08/2016 20:31, Andy Seaborne wrote: > >> > What do others on the PPMC think? > >> [...] > >> >>> I remember we said the 3 most important points were > >> >>> > >> >>> 1. Community growth > >> >> > >> >> Taverna is like many ASF projects - the size of the active (I)PMC is > >> not > >> >> that great. This, in my experience, is normal. We hear and see the > >> ASF > >> >> mega-projects but in terms of numbers of projects, they are a > minority. > >> >> > >> >> It would be good to see some of the IPMC active. The critical thing > >> here > >> >> is whether people are available to get releases out, not "3 days, > now" > >> >> but "in the next month could you...". > >> > >> At the moment, my workload is pretty high with other things going on, so > >> I can only occasionally pay proper attention here. I'm afraid I've been > >> relying on others to pick things up and let me know explicitly when my > >> input is desired, and that's a bit naughty of me. > >> > >> I'll parachute effort and attention in when I can. > >> > >> >>> 2. Release more of the imported code to create engagement > >> >> > >> >> What is the current state of imported/released? > >> > >> There are two main items out of the imported set that haven't yet made > >> it to release: the Server and the Workbench. With the Server, I think > >> the effort to release it isn't too massive, under the assumption that we > >> don't take on doing a huge functionality revision. While there's some > >> bits that need work, I'm guessing that it isn't too much unless we go > >> for some of the more elaborate ideas that we've mooted in the past (and > >> I'm not convinced any more that they're the right way). > >> > >> Concretely, the key things are: > >> > >> * Review the internal message bus mechanism for security. JRMP is > >> convenient, but it requires very tight security and isn't really > >> designed to work that way. Attention required and not just from me > >> because I'm probably too close to the existing code to see any dumb > >> problems in it. > >> > >> * Reworking the server so that it supports something less horrible > >> than baclava files for packaged data import and export. For export, > >> most people have been just downloading zip files, but the import > >> side is more of an issue. > >> > >> * Throw out the mess that was the listeners and the notification > >> mechanism. That never really worked right. The bits that did work > >> are already mostly partially elsewhere, but we ought to clear this > >> bit of swamp instead of keeping the alligators for ass-backward > >> compatibility reasons. > >> > >> Aside from the usual release engineering stuff (license checks, etc) of > >> course. > >> > >> The Workbench is a whole different problem. > >> > >> Donal. > >> > > >
