[Gt-eos] Determining project collaboration and ownership

[Frank Scheiner]

Hi Brian,

On 10/19/2017 08:33 PM, Brian Lin wrote:
> Hi all,
> 
> Parallel to the source code org/repo location discussion, we should 
> start discussing the details of the collaboration effort. We have put 
> together a list of OSG packages that require Globus and which Globus 
> packages we require here 
> <https://jira.opensciencegrid.org/browse/SOFTWARE-2887?focusedCommentId=346471&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-346471>. 
> Are there similar EGI/WLCG/etc lists so we can find where we can split 
> the support load?

For PRACE not yet, but in general all packages GridFTP depends on and 
all packages GSI-OpenSSH depends on.

An issue is that some centers in PRACE compile e.g GridFTP server and 
client manually from the upstream source code, others use RPM SPEC files 
to create their own packages (CEA I believe) and others use packages 
from EPEL or Globus. I personally prefer packages to save time, although 
I cannot use them on all local hosts at HLRS that provide Globus related 
services, e.g. I have to fall back to manual builds of the Globus 
GridFTP client (guc) for our supercomputer front ends.

A general question:

Is OSG also the source of the Globus related packages in the EPEL and 
Debian/Ubuntu repositories?

For HLRS alone only packages required for GridFTP are relevant. In June 
I performed a manual rebuild of GridFTP server and client from the SRPMs 
provided by Globus to get the total size of the needed source code. Does 
OSG use the exact same package names and dependencies as Globus for its 
packages?

 From the lists provided on [1], I wonder why that 
`globus-xio-gridftp-driver` package is not a dependency of the GridFTP 
server. The naming is a little irritating then.

[1]: 
https://jira.opensciencegrid.org/browse/SOFTWARE-2887?focusedCommentId=346471&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-346471

> 
> For all the shared items we'll need to decide on the ownership model. 
> Here are some ideas:
> 
> - Single-owner: there has been a suggestion where the "owner" of the 
> piece of software would rotate amongst the various orgs where the 
> "owner" would be responsible for support, development, and releases. 
> We'd have to have some sort of system in place for critical/intensive 
> issues where other organizations could be called on for assistance.
> - Multi-owner model: Since I imagine most issues will originate from 
> within each orgs already established support channels, the org that gets 
> the issue owns the development for it (with the ability to pull in other 
> orgs for critical/intensive issues). Then the development, testing, and 
> release all have to be signed off by each collaborative organization.
> - Some combination of the above
> - Something else entirely

I'd prefer the Multi-owner model, because if an organization that is the 
single owner of a piece of software leaves for some reason (missing 
funds, missing manpower, etc.) we'd have a similar situation than now 
with Globus, although on a smaller scale. With the multi-owner model, 
multiple organizations can build up expertise on a single piece of 
software, which makes it less of a problem if an organization leaves.

Regards,
Frank

-- 
Frank Scheiner

High Performance Computing Center Stuttgart (HLRS)
Department Project User Management & Accounting

Email: scheiner at hlrs.de
Phone: +49 711 685 68039

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2293 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20171020/97a118c7/attachment.p7s>