wiki:developers-meeting-20111109

[part of a series of meetings]

Participants

Antje, Jan, Gerd, Paul, Tigran, Tanja, Patrick, Christian, Karsten; Al, Dmitry

Agenda

[see box on the right-hand side]

Postcards

Up to two minutes (uninterrupted) per person where they can answer two questions:

  • What I did last week (since the last meeting),
  • What I plan to do in the next week.

No questions until we get through everyone :)

Dmitry: working with Al on liquibase; implementing this for SRM cell it is called on startup. LHCb migration work; issue is setting tokens ... ~bug/by-design: no activity on files if space expires. This is what LHCb want. Don't want to move

Al: looking at liquibase. Have this for billing. Needs some more testing then submitting patch to RB. Also working on SQL script for migrating fine-grain billing to aggregated billing tables. After this is done, moving onto something new, maybe gPlazma. The migration 50--60,000,000 entries for billing at Fermi.

Christian: SL6 packaging, learning about Maven.

Patrick: lot of small things: negotiations with company that wants to use dCache commercially (hence license discussion) + admin.

Tanja: working on billing patch (fighting with parser).

Tigran: releasing 1.9.12-11. Fixing race-condition in pools. Merging Tanja's referral patch into pseudo-fs + NFS chapter in book.

Paul: Splitting info DGA.

Gerd: finishing the Maven stuff and committing it. Discussing with Tigran about things. Discussing Maven with the rest of the team. Making groovy scripts available from within dCache.

AP/ Gerd to send some information about Maven to team.

AP/ ~15 minute on Q&A on Maven.

Jan: import feature (for pool). Playing with maven. Looking at the new find-bugs .. fixing 'em.

Antje: documentation. Web-pages.

Karsten: reviews, small patches, playing with maven & eclipse.

Plans for patch-releases

Should we make a new patch release?

Currently 2.0 is currently being tested. Once usual process is complete, we'll have the next release. Then start for 1.9.12 to fix the mover race condition.

Also be a patch about GridFTP patch (mover timeout).

Trunk activity

Progress with new features...

Unit tests

200 unit tests are not running.

Missing ones webadmin + gPlazma.

Perhaps we can exclude the parboiled tests from Emma.

Other Jenkins targets that are currently failing (srmclient, dcap, ...)

Pulling out things

dcache-core (former 'dCache' directory). There's all kinds of stuff in there.

Gerd wants to pull out things: webdav, space-manager, srm can be in separate modules. This allows the dependencies to be more obvious.

Would this result in them appearing in different jar files? Yes. We can merge them if we want to.

This has already happened for gPlazma: we now have gplazma-1, gplazma-2 (core), the gplazma plugins: (Argus, etc...). The dependencies are in

Must be careful not to include the version number in a sub-module dependencies. If we did this then which jar file is used will become load-order dependent.

There are three more modules that can be split off: NFS, Chimera, ONC/Sun-RPC code.

If we have one component talking to another, what is our strategy? Currently we just use them. With OGSi, you have to document such interfaces (==interactions, not necessarily a Java Interface).

xrootd

Plan is to move this to github. This needs a clean interface.

Currently just the protocol handling that's generic, so this shouldn't be too difficult.

Issues from yesterday's Tier-1 meeting

Keep old pnfs-chimera migration instructions for 1.9.5.

Issues from EMI

Nothing urgent.

Issues from OSG

Brian B. sent mail asking about HTTPS transport. Apparently the priority of this has risen within OSG.

Patrick also got email from him about WebDAV.

These questions are coming from his membership of WLCG Data TEG.

License thing

Patrick

We are part of EMI, components are supposed to be sustainable. This has happened. They're interested in using dCache + enstore. The problem here is with dCache's license; they want something that's good for the community (i.e., open-source) and good for the company (i.e., a private license).

We had a meeting to discuss this. They explained what they are interested it. Things became a little clearer. Releases from the dCache 1.9.12 branch is available to them for commercial use, but not any other branches.

Current plan is to use GPL, but might be LGPL or Apache.

Very last moment for this decision is April 2012.

github clone

As soon as license thing is sorted. We can put a clone of dCache on a public system. The github seems the one with the bigest momentum at the moment.

Probably, as a consequence, we will switch to git.

Clone of github will be HEAD without any history: history would be too much data for github, since old versions contains binaries (external dependencies, etc).

This doesn't force us to loose our history as we keep this on our own personally hosted repository.

Currently our dCache is ~1.5 GiB in size. People might not want to clone with this amount of data.

There's a free book on a web-page,  progit, that describes git nicely.

Maybe we should think about alternatives: Google Code ...

But, lets get the license sorted first.

Outstanding RT Tickets

[This is an auto-generated item. Don't add items here directly]

Review of RB requests

DTNM

Same time, next week.