[Soc-coordination] Status of the Taverna/BOINC/Wrapper/GeneticCloning projects

[Steffen Möller]

Hello,

On 04/08/2011 09:12 AM, Ana Guerrero wrote:
[...]
> Hi Dominique!
> Thanks a lot for helping. You were accepted as mentor in melange yesterday
> night so maybe you got a chance to read the students proposals and specially
> the comments to the proposals pointing to problems in the original
> project. Just for the sake of completion, since you quoted 2 project,
> the one you are willing to mentor is:
> http://wiki.debian.org/SummerOfCode2011/BOINC right?

+ co-mentoring on Eucalyptus, so I hope. BOINC itself is already well
staffed (not all showing up in Melange) but Dominique is of course
welcome.

> I guess you have read in this list that project proposal is not
> accepted and we have told the students this decision. What you would like to do
> here exactly?

[Dominique]

> The deliverables of the project are not clear and they do
> mostly look as a packaging project.

[given the fast approaching deadline and Dominique's -6h timezone, I make
  an attempt to help out]

Please differentiate. The pkg-escience _is_ a packaging project. I obviously
do not understand why you do not want that, but, well.

BOINC instead is a technology. That comes with a client. That is all nicely
packaged already and well accepted
	http://qa.debian.org/popcon.php?package=boinc
. No project work to do for the client side.
The technology to prepare the server side is basically still as mystery.
To prepare new projects, upstream expects you to work with their source tree.
It is not clear from upstream's many dispersed Wiki pages and tutorials
how to create the binaries for the various platforms to be
supported (nice link to the cross building GSoC project for this year)
and neither where to place them and how to create those various
configuration files and keep the database in sync and where to place one's
project descriptions how to manage result files and not ruin everything
when there is an update of the infrastructure that for security reasons
one needs to not just ignore.

Yes, of course we want to prepare packages for BOINC's server side. To have
that would mean that everything we would transform from 'not clear' to
'well formalised' and 'comparable between different installations'. This
is quite a challenge and not just some *.install files. Those I have already
done, based on Frank's work half a decade ago. But we lack all the scripts
and user guidance to apply it all for non-toy long term examples ... and
even the toy examples are not set up at the moment.

> Could you please address what are the
> challenges that the students are supposed to address in this project?

  * develop everything that would be required to build scientific BOINC
    projects with Debian's recent boinc-server-maker package as a build
    dependency and/or runtime environment.
  * prove it by taking the fragments for BOINC support hiding in Debian's
    autodocksuite source package.

A very tangible newsworthy outcome (aka 2nd delivery) would be that every
university's small or not so small biochemistry group would be granted
basically the very same infrastructure as what is behind
www.worldcommunitgrid.org's FightAids at Home ... directly applicable to
many different diseases on all the machines of that and neighbouring
institutes and its students. But this is only the proof for the first
and primary deliverable to be functional: the provisioning of
the core infrastructure to do this all, distributed as a all. It is an
infrastructure project, not a science project. The science is done in
the biochemistry labs.

Has that helped?  Does that make you think differently? I personally like
the description and comments on the BOINC wrapper project, but maybe
you could point to difficulties on the understanding front?

We have yet (24h after your announcement) not found an alternative
organisation to host the project. If you stay with your decision, please
help us finding one.

Best regards,

Steffen