On Friday 14. September 2018 09.06.50 Bernhard E. Reiter wrote:
>
> Am Donnerstag 13 September 2018 17:05:41 schrieb Andreas Nilsson:
> >
> > The idea is to make an economical funding platform. The platform itself
> > only communicates between the two parties users and developers,
> > economically
Hi Andreas,
On Thu, 13 Sep 2018 17:05:41 +0200 Andreas Nilsson wrote:
>
> If this is the case then I would suggest to seperate out the parts
> that makes Github and others to have an upper hand and then see how
> the parts can be countered using free software and free innovation.
I wrote a blog
Hi Andreas,
Am Donnerstag 13 September 2018 17:05:41 schrieb Andreas Nilsson:
> By the phrasing "leading provider" I assume that it means a company
> that won't share the software innovations with the rest of the
> community so that all can benefit.
yes.
> If this is the case then I would sugge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Bernhard.
> > Personally, I don't think we need to dive down into completely
> > different
> > VCS software just because a VCS repository provider decided to go
> > evil.
>
> The argument is about how to counter the network-effect that will
>
On Mon, Sep 10, 2018 at 2:25 AM Bernhard E. Reiter
wrote:
> The argument is about how to counter the network-effect that will makes it
> easier and easier for a leading provider to get more ahead of others.
> And it is about what is a more sustainable choice.
One thing that I really appreciated
Hi all,
sorry for being late in the discussion but I still want to comment on
one point:
On Tue, 28 Aug 2018 15:11:06 +0200 Carsten Agger wrote:
>
> I'd say, though, that my experience is that the "social media" aspect
> of Github is not as important as e.g. on YouTube or eBay. People find
> your
Hi all,
Am Donnerstag, den 06.09.2018, 12:21 -0500 schrieb Timothy Pearson:
> On the topic of history rewrite, I'd argue that allowing it on a
> private
> (read: development) repository provides better commits and less
> chance
> of losing work. It allows the developer to incrementally commit
> s
Am Samstag 08 September 2018 15:36:08 schrieb Adonay Felipe Nogueira:
> Personally, I don't think we need to dive down into completely different
> VCS software just because a VCS repository provider decided to go evil.
The argument is about how to counter the network-effect that will makes it
eas
On Saturday 8. September 2018 10.36.08 Adonay Felipe Nogueira wrote:
> I won't cite any past message because I lost some of them during an
> accidental removal of the emails on my computer, so forgive me if this
> was already said by someone else.
Having just done a distribution upgrade and with A
I won't cite any past message because I lost some of them during an
accidental removal of the emails on my computer, so forgive me if this
was already said by someone else.
Personally, I don't think we need to dive down into completely different
VCS software just because a VCS repository provider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/07/2018 08:41 AM, evaggelos balaskas wrote:
> Without derailing too much this wonderful discussion, I would like to make a
> comment on lost commits/code.
>
> IMHO git is not a backup solution, its a version control system. sometimes we
> f
Without derailing too much this wonderful discussion, I would like to make a
comment on lost commits/code.
IMHO git is not a backup solution, its a version control system. sometimes we
forgot this simple but important tiny thing so freq commits (even on a local
cloned repo or branch) is really
Am Donnerstag 06 September 2018 22:40:49 schrieb Timothy Pearson:
> > I think you could do something similar to git with Mercurial but it
> > wouldn't be exactly the same.
> As long as the general class of functionality is present, that's fine.
https://www.mercurial-scm.org/wiki/HisteditExtension
On 09/06/2018 02:46 PM, David Boddie wrote:
> On Thursday 6. September 2018 12.21.17 Timothy Pearson wrote:
>
>> On the topic of history rewrite, I'd argue that allowing it on a private
>> (read: development) repository provides better commits and less chance
>> of losing work. It allows the deve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/06/2018 06:42 AM, David Boddie wrote:
> On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote:
>
>> Today I read some (most?) documents on the project's site, and I see
>> that it's very similar, but on the flip side it looks like interactiv
On Thursday 6. September 2018 12.21.17 Timothy Pearson wrote:
> On the topic of history rewrite, I'd argue that allowing it on a private
> (read: development) repository provides better commits and less chance
> of losing work. It allows the developer to incrementally commit small,
> incomplete,
On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote:
> Today I read some (most?) documents on the project's site, and I see
> that it's very similar, but on the flip side it looks like interactive
> rebases are not as easy as they are with git, and I really use them a
> lot (I write several fe
Am Mittwoch 05 September 2018 21:44:20 schrieb Alessandro Rubini:
> Having two options instead of one is always good.
Yes, this is why my post was about the effect chains if we use and support one
tool or several ones. Because in a lot of situations others are already
completely booked on one to
> Using Mercurial instead of git is also a bit like using another kernel
> instead of Linux. It seems unnecessary to use something else when you already
> have something that works, but it's useful to have working options in case
> you find yourself using a device without a Linux port but with Free
On Fri Aug 31 11:03:22 UTC 2018, Alessandro Rubini wrote:
> > * Use hg or other trackers if you can.
>
> why? It's already oh so difficult to get people make decent commits to
> git, where at least I can point to all the world doing that...
Bernhard gave some good reasons but I can think of anot
Am Freitag 31 August 2018 13:03:22 schrieb Alessandro Rubini:
> > * Use hg or other trackers if you can.
>
> why? It's already oh so difficult to get people make decent commits to
> git, where at least I can point to all the world doing that...
* Because having a choice is good. If git is to becam
On Friday 31. August 2018 13.03.22 Alessandro Rubini wrote:
>
> But I have a question for Berhnard, who says among other things I agree
> with:
> > * Use hg or other trackers if you can.
>
> why? It's already oh so difficult to get people make decent commits to
> git, where at least I can point t
Thanks to all who replied. Let me comment a little on these
recomendations, suggested by Bastien:
>>https://www.gnu.org/software/repo-criteria-evaluation.html
>>https://www.gnu.org/software/repo-criteria.en.html
To which Bernhard (and Sandro) noted:
> Not taking new developments into acco
Am Mittwoch 29 August 2018 07:04:05 schrieb Bastien:
> https://www.gnu.org/software/repo-criteria-evaluation.html
> https://www.gnu.org/software/repo-criteria.en.html
Not taking new developments into account, though
as the last evaluation came from 2016-04-13.
--
FSFE -- Founding Member Sup
On Wed, Aug 29, 2018 at 07:04:05AM +0200, Bastien wrote:
> Hi Alessandro,
>
> Alessandro Rubini writes:
>
> > How does the free software community feels in this respect?
>
> There is this:
>
> https://www.gnu.org/software/repo-criteria-evaluation.html
> https://www.gnu.org/software/repo-criter
Hi Alessandro,
Alessandro Rubini writes:
> How does the free software community feels in this respect?
There is this:
https://www.gnu.org/software/repo-criteria-evaluation.html
https://www.gnu.org/software/repo-criteria.en.html
HTH,
--
Bastien
__
Hi Alessandro,
On Mon, Aug 27, 2018 at 11:35:21PM +0200, Alessandro Rubini wrote:
> So, besides self-hosting (unfeasible for whole-kernel repos)
A remark for non-kernel-hackers: The linux.git tree is so large that
you need a serious amount of RAM (and I/O bandwidth, and CPU) to host
git repositor
On 29/08/2018 11:23, Bernhard Reiter wrote:
Am Mittwoch 29 August 2018 09:22:57 schrieb Ion Savin:
I don't see why UI tools wouldn't make this process as friendly as
GitLab/GitHub MR/PRs but I don't think they exist yet.
Have you checked out what latest Versions of Allura, Phabricator and gerr
Am Mittwoch 29 August 2018 09:22:57 schrieb Ion Savin:
> I don't see why UI tools wouldn't make this process as friendly as
> GitLab/GitHub MR/PRs but I don't think they exist yet.
Have you checked out what latest Versions of Allura, Phabricator and gerrit
and do to solve this use case?
(I am se
Hi Alessandro,I do share your concerns. Hosting your projects is just half the problem.The bigger problem in my view is that a large number of projects don't have an alternate way of accepting contributions, just GitHub PRs which force you to create a GitHub account.I think it is worth convincing p
On 08/28/2018 01:19 AM, Guido Arnold wrote:
What I see as the crucial part is the "social" component. I'm afraid
this somewhat derails Alessandro's intended discussion as my point
totally ignores "who" the current owner of github is.
If you have a project and are looking for more developers t
On Mon, Aug 27, 2018 at 11:36 PM Alessandro Rubini wrote:
> So, besides self-hosting (unfeasible for whole-kernel repos) I moved
> to github. Well, not using it other than as a git repo why should I
> care that the code (that I do not use) is not free?
if you're not using the other pieces of gi
On 28.08.2018 09:29, Bernhard E. Reiter wrote:
> Am Dienstag 28 August 2018 01:19:54 schrieb Guido Arnold:
>> We need a decentralized infrastructure that makes their intentions
>> irrelevant.
>
> This is the direction where I believe we must head.
>
Just want to throw in a relevant link to a p
Am Dienstag 28 August 2018 01:19:54 schrieb Guido Arnold:
> We need a decentralized infrastructure that makes their intentions
> irrelevant.
This is the direction where I believe we must head.
However while doing so, as always in a long struggle, we need to be pragmatic.
So each of us shall take
Hello,
Two cents of a non-qualified non-programmer here.
On Mon, Aug 27, 2018 at 10:54:15PM +0100, David Gerard wrote:
> Lotta people use Gitlab precisely because you can self-host a Gitlab
> instance - but you can use them as a service provider it's easy to
> leave.
The beauty of git is that i
Lotta people use Gitlab precisely because you can self-host a Gitlab
instance - but you can use them as a service provider it's easy to
leave.
On Mon, 27 Aug 2018 at 22:47, Duncan wrote:
>
> With remote git repository hosting we have many options.
>
> You could self-host gogs or gitlab, or use man
With remote git repository hosting we have many options.
You could self-host gogs or gitlab, or use many of the public instances
of these, e.g. notabug.org or 0xacab.org. Or just host good old cgit
somewhere safe. Or indeed keep using github as a place/mirror to put
code. But with repository hosti
This is the question. Or, better, to github or not to github.
Once upon a time, github was a bad hosting site, because the site code
is not free, and we should have rather preferred gitorious. I
did. But then gitorious closed shop and I had to go to the various
projects (hosted elsewhere) that ha
38 matches
Mail list logo