Projections for an Apache Taverna Workbench release - comments and help sought.

[Shoaib Sufi <sh...@gmail.com>]

Hi,

(we know some of this is not the Apache way - i.e. closed meeting for
planning - so please feel free to let us know how this should have
been done - this is a learning process for us too).

Alan Williams, Stian Soiland-Reyes, Donal Fellows, Ian Dunlop and I
met yesterday.

We have put together a list of what needs doing (under various notions
of a release, how long
things would take and who is like to be available and for how long).

By a release what is meant is Taverna Workbench (as oppose to just the
command line or Taverna Server) - as the Workbench is the more
difficult but important/alluring case wrt to growing the community and
as a technical milestone.

The types of release
-----------------------------
(M) Minimal - in the release often/release early genre - advocated by
the open source community and seen as the best/quickest way to attract
more developers/effort (it might not run all the workflows people
expect)

(C) Community - Minimal plus extra features which will be immediately
needed by people using Taverna in some anger

(F) Full - this is the style of release of the old none Apache Taverna
2.x line where it's super high quality, gold plated, highly tested,
quite defensive and with a low worry of people saying to us that 'we
tried it and it does not work for x,y or z) or why does it not have a,
b, c support -
it used to.

Note for an (F) release - given the way Apache Taverna should run -
this mega release will probably best come out of a number of staged
releases)


What needs to be done for a release - type of release - ideal time
estimates (assumes most suitable person is available that we know of)
-----------------------------------------------------------------------------------------------------------------------------------------------
(note in brackets we put next to each task what type of release the
task applies to)

Components activity porting to support execution (F) - 10 days

Components activity porting to support UI (F) - 40 days

Soaplab 1 support  (F) - 15 days

Fixing Looping (C)  - 5 days

Licensing fixes that are known (specifically moving the tool service
so ssh vs jsh) (M) - 10 days

Provenance JSON run report to PROV (F) - 10 days

Fixing Build issues (M) - 10 days

Check Workbench for licensing issues (LGPL vs Apache
incompatibilities) (M) - 15 days

Fixing Workbench license incompatibility issues (M) - 15 days to 150
days depending on the severity of what is found (involves replacing
infringing libraries and all their usage with alternative compatible
ones and new usage patterns in the code)

Updating Copyright headers etc (M) - 5 days

Integrating web based repositories of workflows and services (e.g.
myExperiment and BioCatalogue) using a 'Spotify' type URL handler
approach  (F) - 20 days for the proper one this would need changes to
the myExperiment and BioCatalogue web applications

Dmitry's WSDL process (needed as it's Apache compliant) (C) - 10 days.

Availability of developer effort from now until end of 2015
---------------------------------------------------------------------------
Ian Dunlop - 20 days
Stian Soiland-Reyes - 15 days
Alan Williams 15 days (mainly in between things tasks)


Some tasks can be done in between things and some tasks need dedicated
time

Release dates depending on the version (assuming developer effort
availability matches estimates)
-------------------------------------------------------
(M) - by end of Dec 2015

(C) - by end of Feb 2016

(F) - by end of July 2016

Note (M) tasks implied if (C), (M&C) implied if (F)


Comments and a request
----------------------------------
Personally I think as a group we should aim for the (M) release and
get this done
as soon as we can - we can always come back to the (C) release early
2016.

Is anyone happy to help with any of the work items - i.e. take
responsibility for their inclusion - this would help bring the Taverna
release forward (e.g. Dmitry would you be able to do the WSDL merge)?


Best
Shoaib

RE: Projections for an Apache Taverna Workbench release - comments and help sought.

[Christian Brenninkmeijer <ch...@manchester.ac.uk>]

While still at the University of Manchester I am no longer in the team that developed Taverna so can read and reply to this as an external.

I fully agree that splicing the releases by feature but including the workbench is a much better strategy.
Apache Taverna (3) command line without a workbench to create workflows is not very useful.

It is also good to see that important or even vital bits that currently need work are not included in (M) Minimal.
As tempting as it will be do not let these slip back into minimal.

It important that Taverna learns to crawl again, before even trying to walk let alone run.
It does not matter if the first beta Apache release can do no more than run hello world!!!!!!!!!!!!!!!!!!!!!!
It will still be a major accomplishment to get key parts plugged together and all the apache steps followed.

So if it doesn't block hello world or it being an apache release , and it needs work, leave it for release 2!

Christian
University of Manchester
Department of Life sciences



________________________________________
From: Shoaib Sufi [shoaibsufi@gmail.com]
Sent: Thursday, June 11, 2015 12:20 PM
To: dev@taverna.incubator.apache.org
Subject: Projections for an Apache Taverna Workbench release - comments and help sought.

Hi,

(we know some of this is not the Apache way - i.e. closed meeting for
planning - so please feel free to let us know how this should have
been done - this is a learning process for us too).

Alan Williams, Stian Soiland-Reyes, Donal Fellows, Ian Dunlop and I
met yesterday.

We have put together a list of what needs doing (under various notions
of a release, how long
things would take and who is like to be available and for how long).

By a release what is meant is Taverna Workbench (as oppose to just the
command line or Taverna Server) - as the Workbench is the more
difficult but important/alluring case wrt to growing the community and
as a technical milestone.

The types of release
-----------------------------
(M) Minimal - in the release often/release early genre - advocated by
the open source community and seen as the best/quickest way to attract
more developers/effort (it might not run all the workflows people
expect)

(C) Community - Minimal plus extra features which will be immediately
needed by people using Taverna in some anger

(F) Full - this is the style of release of the old none Apache Taverna
2.x line where it's super high quality, gold plated, highly tested,
quite defensive and with a low worry of people saying to us that 'we
tried it and it does not work for x,y or z) or why does it not have a,
b, c support -
it used to.

Note for an (F) release - given the way Apache Taverna should run -
this mega release will probably best come out of a number of staged
releases)


What needs to be done for a release - type of release - ideal time
estimates (assumes most suitable person is available that we know of)
-----------------------------------------------------------------------------------------------------------------------------------------------
(note in brackets we put next to each task what type of release the
task applies to)

Components activity porting to support execution (F) - 10 days

Components activity porting to support UI (F) - 40 days

Soaplab 1 support  (F) - 15 days

Fixing Looping (C)  - 5 days

Licensing fixes that are known (specifically moving the tool service
so ssh vs jsh) (M) - 10 days

Provenance JSON run report to PROV (F) - 10 days

Fixing Build issues (M) - 10 days

Check Workbench for licensing issues (LGPL vs Apache
incompatibilities) (M) - 15 days

Fixing Workbench license incompatibility issues (M) - 15 days to 150
days depending on the severity of what is found (involves replacing
infringing libraries and all their usage with alternative compatible
ones and new usage patterns in the code)

Updating Copyright headers etc (M) - 5 days

Integrating web based repositories of workflows and services (e.g.
myExperiment and BioCatalogue) using a 'Spotify' type URL handler
approach  (F) - 20 days for the proper one this would need changes to
the myExperiment and BioCatalogue web applications

Dmitry's WSDL process (needed as it's Apache compliant) (C) - 10 days.

Availability of developer effort from now until end of 2015
---------------------------------------------------------------------------
Ian Dunlop - 20 days
Stian Soiland-Reyes - 15 days
Alan Williams 15 days (mainly in between things tasks)


Some tasks can be done in between things and some tasks need dedicated
time

Release dates depending on the version (assuming developer effort
availability matches estimates)
-------------------------------------------------------
(M) - by end of Dec 2015

(C) - by end of Feb 2016

(F) - by end of July 2016

Note (M) tasks implied if (C), (M&C) implied if (F)


Comments and a request
----------------------------------
Personally I think as a group we should aim for the (M) release and
get this done
as soon as we can - we can always come back to the (C) release early
2016.

Is anyone happy to help with any of the work items - i.e. take
responsibility for their inclusion - this would help bring the Taverna
release forward (e.g. Dmitry would you be able to do the WSDL merge)?


Best
Shoaib

Re: Projections for an Apache Taverna Workbench release - comments and help sought.

[Stian Soiland-Reyes <st...@apache.org>]

No, but I think having something released makes it easier to join in,
as it shows project vibrancy rather than closed "just wait for the
existing committers to sort things out" .

I don't think (M) is truly minimal, but it is a "you get what's
already there" release - we sort out whatever license and build
problems still exist, but if it runs, and doesn't explode in your
face, then it's good enough to go in my view. I'm not advocating
releasing rubbish code, but an incremental release process where we
release continually, and can be open about what is "finished" and what
still needs improvement.

The classic way we used to do this in Taverna was to think like
Microsoft, and not release anything until it was all shiny shiny.. but
this meant one release pr year or so, and also the inevitable feature
creep as "that can also be included in the next release". I don't
think that was sustainable before, and even less so under the Apache
umbrella.


As long as we have a Taverna Command Line and Taverna Server that can
run SOME real workflows (not just Hello World), then that is good
enough for a release for me - even if certain activity plugins have
not yet been updated to the Taverna 3 architecture. Last time I tested
the command line, it could do just that with WSDL and Beanshell
services. It might not be able to use all the services you would want
politically - but now that we are at ASF we should presumably be able
to prioritize code and community over political tick-marks and
academic allies.  I know this is a bit naive given that I and several
others are still funded through the University of Manchester - but if
we all pretend, it becomes true. :)


Similarly, if we have a Taverna Workbench that can design and run SOME
real workflows (even if it can't design all workflows the command line
can run yet), then that is similarly good enough for me. It might not
yet  do say looping configuration, some buttons that were there in
Taverna 2 might be missing, but that is OK. If you miss a particular
feature a lot, engaging with the project would help us in working on
the right important features rather than just picking from memory.


I also think getting such a minimally-working functionality release
out will help with community growth, as it means the 'difficult' bits
(e.g. ensuring the build and OSGi plumbing works) are sorted, and
there are many smaller trophee "leaf" tasks, e.g. if you have a
particular Taverna 2 feature you are missing, then trying to update
that could be a good way into the project. Adding new plugins is also
a good way in, as we've seen in the past and considering the
continuing shift in the scientific domains of the user base.

Re: Projections for an Apache Taverna Workbench release - comments and help sought.

[Andy Seaborne <an...@apache.org>]

Having discussions is normal - it should be done so as not to 
disadvantage the wide community e.g. it's the decisions that must be 
community.

Taverna, as a new project, also has the issue of creating/growing the 
community.  This is the top priority graduation issue now that a release 
is being done.  There is no requirement for the project to have released 
everything to graduate (though all the code should to be legally clean).

Just how minimal is (M)?  Which workflows would be possible?  What's the 
"Minimum Viable Product" here?

How can other people help to get to (C), and influence-by-contributing 
the scope of (C)?

	Andy

On 11/06/15 12:20, Shoaib Sufi wrote:
> Hi,
>
> (we know some of this is not the Apache way - i.e. closed meeting for
> planning - so please feel free to let us know how this should have
> been done - this is a learning process for us too).
>
> Alan Williams, Stian Soiland-Reyes, Donal Fellows, Ian Dunlop and I
> met yesterday.
>
> We have put together a list of what needs doing (under various notions
> of a release, how long
> things would take and who is like to be available and for how long).
>
> By a release what is meant is Taverna Workbench (as oppose to just the
> command line or Taverna Server) - as the Workbench is the more
> difficult but important/alluring case wrt to growing the community and
> as a technical milestone.
>
> The types of release
> -----------------------------
> (M) Minimal - in the release often/release early genre - advocated by
> the open source community and seen as the best/quickest way to attract
> more developers/effort (it might not run all the workflows people
> expect)
>
> (C) Community - Minimal plus extra features which will be immediately
> needed by people using Taverna in some anger
>
> (F) Full - this is the style of release of the old none Apache Taverna
> 2.x line where it's super high quality, gold plated, highly tested,
> quite defensive and with a low worry of people saying to us that 'we
> tried it and it does not work for x,y or z) or why does it not have a,
> b, c support -
> it used to.
>
> Note for an (F) release - given the way Apache Taverna should run -
> this mega release will probably best come out of a number of staged
> releases)
>
>
> What needs to be done for a release - type of release - ideal time
> estimates (assumes most suitable person is available that we know of)
> -----------------------------------------------------------------------------------------------------------------------------------------------
> (note in brackets we put next to each task what type of release the
> task applies to)
>
> Components activity porting to support execution (F) - 10 days
>
> Components activity porting to support UI (F) - 40 days
>
> Soaplab 1 support  (F) - 15 days
>
> Fixing Looping (C)  - 5 days
>
> Licensing fixes that are known (specifically moving the tool service
> so ssh vs jsh) (M) - 10 days
>
> Provenance JSON run report to PROV (F) - 10 days
>
> Fixing Build issues (M) - 10 days
>
> Check Workbench for licensing issues (LGPL vs Apache
> incompatibilities) (M) - 15 days
>
> Fixing Workbench license incompatibility issues (M) - 15 days to 150
> days depending on the severity of what is found (involves replacing
> infringing libraries and all their usage with alternative compatible
> ones and new usage patterns in the code)
>
> Updating Copyright headers etc (M) - 5 days
>
> Integrating web based repositories of workflows and services (e.g.
> myExperiment and BioCatalogue) using a 'Spotify' type URL handler
> approach  (F) - 20 days for the proper one this would need changes to
> the myExperiment and BioCatalogue web applications
>
> Dmitry's WSDL process (needed as it's Apache compliant) (C) - 10 days.
>
> Availability of developer effort from now until end of 2015
> ---------------------------------------------------------------------------
> Ian Dunlop - 20 days
> Stian Soiland-Reyes - 15 days
> Alan Williams 15 days (mainly in between things tasks)
>
>
> Some tasks can be done in between things and some tasks need dedicated
> time
>
> Release dates depending on the version (assuming developer effort
> availability matches estimates)
> -------------------------------------------------------
> (M) - by end of Dec 2015
>
> (C) - by end of Feb 2016
>
> (F) - by end of July 2016
>
> Note (M) tasks implied if (C), (M&C) implied if (F)
>
>
> Comments and a request
> ----------------------------------
> Personally I think as a group we should aim for the (M) release and
> get this done
> as soon as we can - we can always come back to the (C) release early
> 2016.
>
> Is anyone happy to help with any of the work items - i.e. take
> responsibility for their inclusion - this would help bring the Taverna
> release forward (e.g. Dmitry would you be able to do the WSDL merge)?
>
>
> Best
> Shoaib
>