On Mon, Nov 4, 2019 at 1:36 PM Jordan Schidlowsky <[email protected]>
wrote:

> Is everyone here forgetting git is not svn?  git is a DISTRIBUTED
> versioning system.  As in, when you use checkout a repo you have a copy of
> the ENTIRE repository.  Github is really just another remote for the repo.
> It's absolutely TRIVIAL to setup a mirror on whatever other service you
> like (including hosting your own solution).
>

No, I'm not forgetting.


> If people are really concerned about the bug/issue tracking being tied to
> github's platform, then just do in-repository tracking.  Pretty simple.  If
> you wanna take advantage of the GitHub platform for pull requests and issue
> tracking then do it.  If you are concerned about ANY part of the project
> being tied to a service/hosting provider then just add some process to
> track those things in-repository as well...    (include the wiki and the
> website as well?)
>
> https://github.com/MichaelMure/git-bug  (GPL BTW)
>

I like this because it means we can take our bug list with us.  I wish
there was a way I could export the bugs from Savannah and import them here.

>
> TBH most of this thread is FUD.  git itself solves almost all these
> problems.  IMHO, use GitHub as a remote for the repo (the advantages are
> clear).  If some don't like GitHub or have issues with it, mirror.  If
> there are concerns about vendor lock-in, then track (or additionally track)
> in-repository.
>

I was simply trying to move things forward.  If people really want me to
open back up savannah's bug tracker I will do so, but I believe it's best
to use the one here as the main one and that was for older bugs.  No new
bugs should be opened there.

>
>
> On Nov 4, 2019, at 4:46 AM, Ivan Vučica <[email protected]> wrote:
>
> I’ll answer as if you are asking the question and not asking rhetorically.
>
> Whoever hosts the project takes over the responsibility for:
>
> - storing user credentials
> - abuse management
> - security and service upgrades
> - data migration when moving from service A to service B
> - possibly even GDPR and other privacy requests (data portability, right
> to be forgotten)
> - backups AND restores
> - service uptime and monitoring (remember, no SLO means 100% uptime which
> is a terrible impossible-to-reach target)
> - administrative overhead and user support
> - complaints when things aren’t going right
> - deciding who gets administrative credentials to execute all of the above
> - deciding how to finance all this ($5 droplet on digital ocean or
> something more?€
> - technical planning for all the above
>
> They take this on even if they are not aware of it.
>
> I’m hosting my own stuff. Aside from development work, for three weeks a
> quarter hold a pager and/or respond to tickets in my professional life
> and/or shepherd automated or semiautomated software deployment processes.
> Something like GNUstep hosting would be less labor than that — but it’s
> still quite some stuff to be responsible for.
>
> This is even before we get into technical choices you should make and how
> long it takes to deploy them.
>
> apt-get install $LISTOFPACKAGES won’t cut it.
>
> On Mon 4 Nov 2019 at 10:26, Umberto Cerrato <[email protected]>
> wrote:
>
>> Why don’t you self host your project in your own website? Something like
>> a self hosted Savannah or similar (there are few around). Then you could:
>> modify the UI to make it more GitHub-like and user friendly and leave some
>> landing projects on GitHub, GitLab etc. that redirect to your e.g.
>> subdomain with hosted files and bug tracker etc.
>>
>> Hello there anyway…
>
> --
> Sent from Gmail Mobile
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Reply via email to