[Gt-eos] Determining project collaboration and ownership

[Brian Lin]

Sending to the whole list this time:

Frank,

On 10/20/2017 07:32 AM, Frank Scheiner wrote:
> 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?

No, Globus itself is the source for EPEL. I'm not sure about the 
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
>

I believe it's a supplementary driver, which is not in use in the OSG.

>>
>> 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.
>

The key part of the single-owner model is that one organization in the 
collaboration would own a package for a set amount of time and then pass 
that ownership onto the next organization in the rotation. If the owner 
of a piece of software leaves, I would think that the next org in the 
rotation would take ownership. Perhaps this is unrealistic but I thought 
I'd throw it out there.

The issues I see with the multi-owner model is that we would be 
sacrificing agility by adding friction at decision points. The more 
people you add to the collaboration, the harder it is to come to an 
agreement (see source repo naming thread :)).

Thanks,
Brian