[ClusterLabs Developers] FYI: github policy change potentially affecting ssh/app access to repositories

[Jan Pokorný]

On 14/04/19 22:48 +0200, Valentin Vidic wrote:
> On Wed, Apr 10, 2019 at 05:44:45PM -0500, Ken Gaillot wrote:
>> Florian Haas and Kristoffer Grönlund noticed that the ClusterLabs
>> organization on github currently carries over any app access that
>> members have given to their own accounts.
> 
> Related to github setup, I just noticed that some ClusterLabs repos
> don't have Issues tab enabled, but I suppose this was intentional?

I think that's very intentional, for several reasons:

* proliferation of issue trackers to watch for a single component is
  just a distraction (also for all those nice reporters that care
  about not filing duplicates), some started before GitHub (or as
  a replacement of a prior non-GH tracking), and will likely stay
  ever after (which is good, see below);
  also, speaking for clufter, I chose to use pagure.io as a primary
  home, so only kept issue tracking enabled there, which makes
  a tonne of sense (aligned with the above concern)

* as we know in HA, it's no good to put all the eggs in one basket
  (a.k.a. SPOF avoidance) -- git is trivial to move around since
  it's distributed by nature, and is continuously mirrored by many
  individuals, so the outliers (important points mentioned just as
  PR commentarie etc.) shall preferably be as spare as possible[1];
  the tracked issues themselves would not be that easy to recover
  back if GitHub stopped working this minute (however unexpectedly),
  I'd actually suggest that ClusterLabs projects with issue tracking
  enabled would opt-in to communication collection to some extra
  read-only mailing list that'd be established for that archival
  purpose (dev-pulse at cl.o?  technically, likely another GH account
  with casual communication email address set to that of this list,
  and subscribed to all these projects; note that bugs.clusterlabs.org
  Bugzilla instance could also forward there) and possibly also
  mirrored with some 3rd party services (too bad that Gmane passed out)

* partly related to that is the flexibility wrt. which forge to choose
  as authoritative, but I believe the data migration freedom is quite
  reasonable here, so there's no data lock-in per se
  (still a proponent of switching to GitLab, recent lengthy PR
  at GH demonstrated how unscalable these ongoing iteration within
  single PR are there)

[1] see point 1. at
https://lists.clusterlabs.org/pipermail/developers/2018-January/001958.html

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20190415/35ebc58a/attachment-0002.sig>