taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Dunlop <ianwdun...@gmail.com>
Subject Re: Towards graduation?
Date Thu, 11 Aug 2016 15:51:52 GMT
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 <GaleN@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 <GaleN@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.fellows@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.
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message