[Gt-eos] Determining project collaboration and ownership

[Brian Bockelman]

> On Oct 20, 2017, at 7:32 AM, Frank Scheiner <scheiner at hlrs.de> 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?
> 
> 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.
> 

I would suggest something along the lines of how Apache projects work.

- All contributions go through the GitHub PR workflow.
- Prior to merge, pull requests must have an approved review by a project committer and no rejections.
  - We can setup a "code owners" page in GitHub such as https://github.com/root-project/root/blob/master/.github/CODEOWNERS <https://github.com/root-project/root/blob/master/.github/CODEOWNERS>.  GitHub will *suggest* reviewers based on the contents of the file, but I suggest we *do not require* the owner to be the reviewer.  We will have a very tiny amount of effort for this; it'd be better to not create too much friction.
- There is a person who acts as a "release manager" for each release.  This person will do all the preparation for a release (create pre-release tags, tarballs, review results of automated tests, etc) and put the release candidate up for a vote.
  - This is the part that can rotate between volunteers.
  - Prior to tagging a final release, the release manager calls a vote of the committers.  Voting styles vary, but one example would be to require 3 positive votes for a release and a majority positive.
    - I find the Apache "meritocracy model" useful here.  Individuals are on the PMC and can vote, not organizations.

Basically - it allows lots of people to contribute easily, but has a single person for getting a release out the door.

Again, let's not overthink it.  This isn't a 10FTE project.  I'd be tickled if it was a 1 FTE project split over 5 people (but I'm not that optimistic...).  Look at the git repo history -- there's not an immense amount of active maintenance needed here.

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20171020/465a3670/attachment.html>