Hi,
I'm just recovering the email backlog after vacation! Agree that we are in a fair state to graduate (even if we are not a particularly fast or big Apache project) - I am not sure the incubator can teach us much more at this point, as we seem to be getting to grips with both governance, community building and IP/licensing review, and we had to chase additional reviewers to get our release candidates through the incubator PMC. It would be ideal to have the Server and Workbench released as well - but I agree with Ian that should not be a blocker for graduation. Thilina and Edi have both had a look at code updates for the Workbench, and while these have helped progressed its state, it is not quite there yet; mainly in terms of updates to Taverna 3 Engine API to have it in a cleanly buildable state (which we need for it to be releasable). Much of the ungrateful work remaining there is that of build maintenance (e.g. editing pom.xml and Spring configurations) rather than adding features or fixing bugs - perhaps this is something we lack a bit of skills or motivations for. :-( I guess our challenge on that is that I think now we don't really have any full time equivalent person dedicated to the project (except the GSOC students) - but that would be the case for many open source projects. For myself the time available for Taverna has been shrinking a bit this spring, and recently I've focused mainly on the excellent contributions by the students, thanks all of you! I guess I should do like a day a month looking at evil pom.xml files as well. :) So how about just let's get cracking on the graduation form [1] and then we can progress towards holding a Graduation [VOTE]? Shoaib mentioned to me today that he would like to have a look as well. I had a go at the first section. [1] https://cwiki.apache.org/confluence/display/TAVERNADEV/2016-03+Taverna+Graduation+Maturity+Assessment On 11 August 2016 at 17:25, Gale Naylor <[email protected]> wrote: > 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. >> > >> >> > > >> > >> -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
