[Gt-eos] Determining project collaboration and ownership

[Baptiste Grenier]

>On 10/19/2017 08:33 PM, Brian Lin wrote:

Hit Brian,

>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 EGI we are currently tracking an assessment of this on the following 
wiki page: https://wiki.egi.eu/wiki/Globus_EOL_assessment

And please at the end of the email the list of dependencies used by 
products in UMD (Thanks to Joao Pina for collecting this).

>>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 was personally under the assumption that the development would be done 
using the GitHub org as a central repository used to track issues and 
have all interested parties making Pull Request as needed, more or less 
like some community-supported projects are managed collectively.

All interested parties would be able to see what is done in the repo and 
discuss issues and PR. And all the members of the organization would be 
more or less collectively be owner/responsible of the software.
With the effect that people actively using or dependent on a component 
are more likely to be the most interested in following/managing it and 
investing some time in maintaining it.

It could be more clear/confortable to have one clear responsible per 
product, but it might be difficult to get all parties to agree, and 
partners probably don't want to be stuck/blocked if the responsible is 
not able to manage something in due/expected time (as long as there is a 
consensus/accepted review).

It will probably be quite important to define a clear process for 
accepting changes and merging PR, ie. having a clear review model 
(finding some people able (time and knowledge) to review and validate 
changes as they will in fact impact all the users) and all the usual 
coding rules, testing requirement, SQA, release process... Starting from 
what was done previously for the toolkit.

In fact the owners you mentioned could be the reviewers, github also 
offers the possibility to host a wiki or even a static/generated site to 
document things so once there will be an organisation and project name 
it will be possible to start formalizing this in the wiki.
If there is only one big repository for the toolkit all the 
reviewers/admins will probably have the same rights and be able to 
manage all the repository without being limited to the specific 
component/part they have been agreed responsible for (especially as a 
feature/patch could affect multiple components/parts of the source 
tree).

Best,
Baptiste

## Globus products

* GRAM5
* GridFTP
* MYPROXY

## ARC-CE

globus-callout
globus-common
globus-ftp-client
globus-ftp-control
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-error
globus-gssapi-gsi
globus-io
globus-openssl-module
globus-xio
globus-xio-gsi-driver
globus-xio-popen-driver

## BLAH

globus-callout
globus-common
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-gsi
globus-openssl-module

## CREAM-CE

globus-authz
globus-authz-callout-error
globus-callout
globus-common
globus-ftp-control
globus-gfork
globus-gridftp-server
globus-gridftp-server-control
globus-gridftp-server-progs
globus-gridmap-callout-error
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gssapi-error
globus-gssapi-gsi
globus-gss-assist
globus-io
globus-openssl-module
globus-proxy-utils
globus-usage
globus-xio
globus-xio-gsi-driver
globus-xio-pipe-driver
globus-xio-udt-driver

## DPM

globus-callout
globus-common
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-gsi
globus-openssl-module

## Storm

globus-authz
globus-authz-callout-error
globus-callout
globus-common
globus-ftp-client
globus-ftp-control
globus-gfork
globus-gridftp-server
globus-gridftp-server-control
globus-gridftp-server-progs
globus-gridmap-callout-error
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gssapi-error
globus-gssapi-gsi
globus-gss-assist
globus-io
globus-openssl-module
globus-usage
globus-xio
globus-xio-gsi-driver
globus-xio-pipe-driver
globus-xio-popen-driver
globus-xio-udt-driver

## EMI-UI/WN

globus-callout
globus-common
globus-common-progs
globus-ftp-client
globus-ftp-control
globus-gass-copy
globus-gass-copy-progs
globus-gass-transfer
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-cert-utils-progs
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gssapi-error
globus-gssapi-gsi
globus-gss-assist
globus-io
globus-openssl-module
globus-proxy-utils
globus-usage
globus-xio
globus-xio-gsi-driver
globus-xio-popen-driver

## FTS3

globus-callout
globus-common
globus-ftp-client
globus-ftp-control
globus-gass-copy
globus-gass-transfer
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-error
globus-gssapi-gsi
globus-io
globus-openssl-module
globus-xio
globus-xio-gsi-driver
globus-xio-popen-driver

## gfal2

globus-callout
globus-common
globus-ftp-client
globus-ftp-control
globus-gass-copy
globus-gass-transfer
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-error
globus-gssapi-gsi
globus-io
globus-openssl-module
globus-xio
globus-xio-gsi-driver
globus-xio-popen-driver

## glexec-wn

globus-callout
globus-common
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gss-assist
globus-gssapi-gsi
globus-openssl-module

## xrootd

globus-callout
globus-common
globus-gridmap-callout-error
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gssapi-error
globus-gssapi-gsi
globus-gss-assist
globus-openssl-module

-- 
Baptiste Grenier
EGI Foundation - Operations Officer
Phone:              +31 627 860 852
Skype:         baptiste.grenier.egi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1867 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20171020/afa12866/attachment.p7s>