You are here
Retreat 2015 Discussion Items
- Decide the retirement root-talk mailing list. Keep it only for announcements.
- Decide the replacement of the current Forum with a new one having a mailer interface. Can 'Discourse Forum' do the work?
- Decide on the continuation of the ‘user support’ weekly shifts.
- Investigate ways to promote more the FAQs and facilitate their authoring.
Collaboration and Contributors
- Objective to make the contributions as easy as possible. With clear instructions and process including code reviews.
- Clarify what will be the responsibilities the core development team keeps and what we would like to open to contributors. In particular, and maybe to be discussed about CERN (SFT? SFT+IT-DSS+IT-SDC(?)?) members only, what are the core responsibilities we want to keep at CERN and/or in the group and the ones we want to collaborate with the external world.
- Decide what is our strategy for assigning new tasks and responsabilities to SFT,IT-*, US-CMS/FNAL, Diana or HSF members.
- Decide if we want to seriously invest in the support of non HEP-science and, if yes, how we can concile this direction with the objectives of CERN.
- Decide If "ROOT as a Service" becomes a new line of work, and since this implies a collaboration with IT, we need to clarify our role and IT's role in such collaboration.
Modularization and BOOT
- Agree that the modularization as presented several occasions is a re-prerequisite for attracting collaboration
- Decide what are the requirements for BOOT and attach a timescale to the project as well as identify a rough small set of intermediate deliverables assuming the effort we can afford.
- Encourage contributors that are packaging ROOT in standard distributions (ubuntu, Mac, fedora, etc.). Collect information and provide recognition.
Interoperability with other languages and libraries
- Decide what to do with PyROOT now that the contribution of Wim is to be considered at the "best effort" level
- Decide about the interoperability of ROOT with other libraries and languages. We could do that discussing at different levels:
- Python packages: we could decide if we want to investigate the integration in the math area (scikit, numpy, sympy), in the IO area (pandas), in the UI area (ROOTPy), in the graphics area (Matplotlib).
- IPython: we could decide if the ipython shell shall become a 1st class citizen, if the notebooks shall become our main documentation format and a co-primary interactive analysis interface
- We could decide or "decide to study in order to be able to decide later" if R deserves a level of interoperability at the level of Python
- Regarding IPython, we also need to discuss how to integrate it with ROOT (e.g. builtin module) in order to facilitate as much as possible the local installation and tests with ROOT notebooks. This also includes the discussion about how to instantiate the local server (i.e. root notebook command).
- Decide the level of interoperability with Julia as a language for scientific software.
- Decide on the completion of the Doxygen. What needs still to be done.
- Decide if we want to continue maintaining the users' guide or if we think a different approach to documentation could be beneficial. If we decide to keep it, we could decide how to tackle its rewriting since, as of now, it is in a less than optimal shape.
- Clarification of the role and presentation of the ‘how to’, ‘tutorials’, ‘gallery codelets’, ‘notebooks’, ‘FAQs’,
- Decide if we write a paper about ROOT6 and with what timescale.
- Decide how to proceed with the incorporation of the new look and feel of the website, its implications on the infrastructure as long as the responsabilities involved.
- Decide on the organization of the CERN training courses
- Decide if we have enough information, who prepares what slides for the CERN trainings
New C++ interfaces
- Decide clear selling arguments for the improved usability and additional functionality.
- Decide the introduction strategy: smooth transition versus the migration all at once, with a tool helping in the migration.
- Decide intermediate deliverables as well as resources and responsibilities.
- Decide what is the runtime environment ROOT adopts for multithreaded execution: e.g. TBB, GranDispatch, our thread pool solution or, if we cannot/don't want to decide for some good very concrete technical or strategic reason, an abstract interface to task submission.
- We could write down a list of the operations we want to do in parallel or in a thread safe manner, attach a deadline and a person to the delivery of the implied features, always isolating intermediate rough deliverables. For example:
- Transparent interoperability of ROOT and stl threads: TThread-per-thread, TThread::Initialize()
- MultiObject and/or thread local gDirectory
- Parallel compression with the LZ4 algorighm
- Implicit parallel reading from trees
- Explicit parallel reading from trees, i.e. n user managed threads reading from a tree
- Implicit parallel writing to trees
- Explicit parallel writing from trees, i.e. n user managed threads writing from a tree
- Application of the Process Pool: RooFit, RooStats, TTreeAnalysis
- Regarding multi-threaded parallelisation, we need to agree on the use case/s to tackle next. In order to make this decision, we should figure out where the big problems are what would be more useful for the users, and give priorities accordingly.
- Decide the evolution of PROOF-lite
Input and output (partially treated also in the parallelisation section):
- Decide which technologies to better support in the future, for example SSDs, Kinetic and also how we see the cooperation with DSS and if a potential interplay is possible, e.g. provide native software support for the storage backends which will be provided to users and experiments. As usual, deadlines with intermediate deliverables as well as resources and responsabilities could be discussed.
- Decide what is the strategy to support the new readout mode of some experiments, e.g. LHCb in RunIII.
Interpreter, reflection, core and typesystem:
- Decide a plan for PCMs, realistic intermediate deliverables, realistic coupling with releases (6.6,6.8,6.x?).
- Decide if a type system (plan B) is a component of ROOT 7, by when and the intermediate deliverables.
- Decide if it is realistic to further leverage the llvm technology, for example:
- The CUDA backend
- The Julia frontend
Graphics, Gui and Visualisation
- Decide about the future of JSROOT and its interplay with the "standard" ROOT graphics. The potential of JSROOT is clear to us (notebooks, cernbox, indico) and is well understood by the users as well. The question is now if we want to keep the current functionality set or if we want it to become the backend of a new interactive visualisation, allowing saving images, resetting to the original plot, change style...
- If we agree on promoting JSROOT and making it richer in functionalities, what are we going to do about the current divergence between the standard ROOT graphics and JSROOT?
- Decide if the graphics UI need some rethinking and/or simplification: leaner interface, helper tools (classes/functions) for plotting, automatic color/line/marker/legend schemes.
- Decide the future of the interface with QT, for example if we want to freeze it or support QT5.
- Decide the future of our GUI builder
ROOT as a Service
- Decide what should be core team involvement in the development of the Service
- Decide if and how we commit as a team and as single individuals to ROOT 7
- Decide the strategy to identify the feature set of ROOT 7 as well as the timescales of the project: final delivery, intermediate steps.
- For example: new C++ interfaces, adoption of a task-oriented model, language bindings, I/O formats, Graphics and GUI solutions, Math, ...
- Decide what effort we put in ROOT7 and in ROOT6 and how much we want to evolve ROOT6 and how much we want to dedicate exclusively to ROOT7.
- We could decide how much we see the present work of interface renovation an R&D and to what extent we want to incrementally evolve ROOT 6 according to its findings.