Sounds good to me. What does everyone else think? Once we decide to go for it, should we fill out the graduation assessment form? Or?
On Thu, Aug 11, 2016 at 8:51 AM Ian Dunlop <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected] > > > > 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 < > > > [email protected]> 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. > > >> > > > > > >
