[Gt-eos] Determining project collaboration and ownership

[Brian Lin]

Sending to the entire list, take two.

On 10/20/2017 08:50 AM, Brian Lin wrote:
> 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