[Linuxtrent] Re: Microsoft compra GitHub, il 'social' degli sviluppatori
- From: Marco Ciampa <ciampix@xxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 7 Jun 2018 00:37:54 +0200
On Wed, Jun 06, 2018 at 03:48:54PM -0600, Daniele Nicolodi wrote:
Questo post di Joey Hess riassume bene il mio punto di vista:
http://joeyh.name/blog/entry/the_single_most_important_criteria_when_replacing_Github/
Molto interessante ma questo è semplicemente sbagliato:
Instead I'd rather highlight one simple criteria you can consider when
you are evaluating any git hosting service, whether it's Gitlab or
something self-hosted, or federated, or P2P[1], or whatever:
Consider all the data that's used to provide the value-added features on
top of git. Issue tracking, wikis, notes in commits, lists of forks, pull
requests, access controls, hooks, other configuration, etc. Is that data
stored in a git repository?
Github avoids doing that and there's a good reason why: By keeping this
data in their own database, they lock you into the service.
non è che se un sorgente aperto è in un formato allora è aperto se è in
un altro no... una cosa è non fornire le informazioni (come fa github)
un'altra cosa fornirle in un formato invece che in un altro... come fanno
gli altri servizi... il tipo fa casino tra i due concetti.
Tra l'altro, come fanno notare, l'ultima frase è platealmente sbagliata:
Github avoids doing that
Not quite true. Both gists and wiki pages are backed by git.
ma sono soprattutto i commenti sotto che mi trovano daccordo:
1) If $PARTY had chosen Git for $USECASE, it wouldn't have let them
achieve lock-in, does not mean, project extras stored in something
besides Git necessarily results in lock-in. It's possible that Git repos
are the entirely wrong abstraction for this. Indeed, insisting on
stuffing all the auxiliary stuff into Git, too, (and all the implications
of choosing those constraints) strongly smells of that phenomenon where
people pick up one abstraction and then try to shoehorn it in everywhere
else, regardless of whether it's well-suited for that use case or not. I
write this even knowing your affinity and relationship to Git with
git-annex & co.
2) Fedora's Pagure mostly satisfies this requirement. All issues,
comments, PR metadata, etc. are stored as Git repositories internally.
You can pull, commit, and push through it that way. It also supports
"remote pull requests" where the git repository of the source branch
isn't hosted on the same server as the repo being targeted. The source
repo doesn't even have to run Pagure!
3) I wholeheartedly agree on the vendor lock-in with issues and pull
requests. I've had a feeling that GitHub sort of well-intendedly hijacked
open source communities. A few months ago, that pushed me to develop a
resilient, future-proof, decentralized issue tracker that I later
generalized for other problems as well (SIT). I wrote a bit about my
vision when I first announced it: “Under the Covers of Code”
I really wanted to build something as future-proof and resilient as I can
imagine, so SIT ended up not being specific to Git or any other SCM but
instead relies on simple additive sets of files.
e tutti gli altri commenti...
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
------------------------
GNU/Linux User #78271
FSFE fellow #364
------------------------
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a
mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
