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. >> >
