Sat, 14 Mar 2015 14:02:18 +0200 John Found <johnfo...@asm32.info>: > > IMO, everything is in reverse. GitHub is not popular, because Git is > great SCM. Git is popular because is used by GitHub! > > Notice that GitHub is not only repository hosting. It is a social > network for developers. That is why it is popular. And every SCM used > in such popular social network will become popular on its own.
It's not just that GitHub dragged Git along to popularity. The real achievement is that it has more or less de-decentralized Git. Putting lipstick on git workflows did certainly help. But I believe their newcomer-friendly tutorials and documentation are underestimated when it comes to GHs success. (Also shouldn't discount free support.) "Social network" is a nice metaphor. But it's also just a side-effect of having a data silo. Most developer interactions center around the issue tracker. Which is pretty. And often just used as discussion board with ticket numbers. Which is not to say that we shouldn't take a few cues here and there. Mon, 16 Mar 2015 09:45:13 +0200 John Found <johnfo...@asm32.info>: > > > But, for example fossil can provide some way to connect the stand > > alone repositories and developers in some kind of distributed > > peer-to-peer network and to provide some interaction - I don't know > > - maybe some voting, messaging, clone tracking, collaborative > > environment, pull requests, whatever will turn a heap of > > independent repositories into mutually connected developers network. > > > > No one is interested, but I will continue a little. :) > > The first step towards such achievement is to allow all Fossil users > to exists in one common username space. > OpenID authentication could help to make this without big effort. If there should be more interactivity between Fossil users and repos, then of course a global user namespace would make sense. OpenID might be an option, but has sort of served its time already. It wasn't originally intended as login system even (homepage URL authorization really). And it's not just Google that depreciated it. It's still trivial to implement a consumer. But I'm concerned this would end up being feature creep for Fossil. - Wouldn't discount it though. I'd think for some social network appeal there should be user avatar support first. - Instead of cross-domain authorization etc. Our `user` table has an unused `photo` column for instance. Not sure that's ever going to get used. So perhaps supporting some form of gravatar in /register might be more practical. - Preferrably even a decentralized and non-proprietary variant like Libravatar. That would implicitly yield a globally unique user hash. > > Another step is to provide some notification mechanism from the > cloned repositories to the parent repository - for example, when the > user make commit to the cloned repository, Fossil sends notification > message to the parent repository. These automatic notifications are > not so useful but may serve as a statistics mechanism and as a > indicator of the project development. Of course, if the project > leader has informations about the changes, he can choose to pull > some/all of these changes without waiting the pull request. > > Even more useful is if the parent repository, notifies the clones > about new commits, because the cloned repository might want to merge > these changes. But if the cloned repository is not hosted on a web > server this can be not easy task. In this case the notification can > be made by request from the cloned repository. Networked commit notification sounds like no little effort. :} Theoretically one could already implement basic commit diffs by polling the JSON API of known remotes. However, we don't even have a network graph of forked repositories yet. Which is something that I'd also like to see. I doubt everyone would want to have this automated. But a /admin page (or a TH plugin) for a central registry seems feasible. For obvious reasons a Fossil repo list would work best on ChiselApp, may just require a remote_repositories table and an AJAX endpoint. (Not sure about push/pull requests ala GitHub. That's mostly just gatekeeper syndrome due to gits volatility. Might be a nice gimmick still.) > > The ticket system can be used as a distributed messaging engine > between developers. A global inbox and cross-repo messages wouldn't be difficult. Just needs an agreed API. (Which might even solve itself with web push notifications in the near future. Could just be a skin feature then.) Of course, a distributed "social network" on top of a DVCS is a little out of scope. But this could just be a TH1 plugin. (And doesn't harm setting up a fx cron job for standard ticket emails etc.) So, going a step back and centralizing it GitHub-style could suffice. - Notification pool on ChiselApp :? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
