Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> On Fri, 19 Aug 2016, Eric Wong wrote:
> > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > > On Thu, 18 Aug 2016, Eric Wong wrote:
> > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > > >
> > > > > Old dogs claim the mail list-approach works for them. Nope.
> > > > > Doesn't. Else you would not have written all those custom
> > > > > scripts.
> > > >
> > > > git and cogito started as a bunch of custom scripts, too.
> > >
> > > The difference is that neither git nor cogito were opinionated. Those
> > > custom scripts are. They are for one particular workflow, with one
> > > particular mail client, with a strong bias to a Unix-y environment.
<snip 3 lines I was not responding to>
> > I guess this is a fundamental difference between *nix and Windows
> > culture.
>
> I do not understand how you get from "I wish to make it fun to contribute
> to Git" to "there is a fundamental difference between *nix and Windows
> culture".
Sorry, I over-quoted by 3 lines.
<snip more digression..>
> > > We do not even have a section on Outlook in our SubmittingPatches.
> > >
> > > Okay, if not the most popular mail client, then web mail? Nope, nope,
> > > nope. No piping *at all* to external commands from there.
> > >
> > > So you basically slam the door shut on the vast majority of email users.
> >
> > Users have a choice to use a more scriptable mail client
> > (but I guess the OS nudges users towards monolithic tools)
>
> You call that choice. Are you serious?
>
> > > That is not leaving much choice to the users in my book.
> >
> > Users of alpine, gnus, mutt, sylpheed, thunderbird, kmail,
> > roundcube, squirelmail, etc. can all download the source, hack,
> > fix and customize things. It's easier with smaller software,
> > of course: git-send-email does not even require learning
> > the build process or separate download.
>
> Now I am getting upset. This is a BS argument. Sure, I can hack the source
> of these tools.
>
> But why on earth do I *have* to? Why can't we use or create an open
> contribution process *that works without having to work so hard to be able
> to contribute*?
The process we have is already open. It may be *nix-centric,
and *nix may be picky about it's friends, but it is open:
Anybody can still contribute today without any sort of
registration, credentialism, or terms-of-service(*).
I am looking beyond git.
I hate signing up for websites. For many years, I have used
Debian as a proxy for other projects with less open contribution
processes:
apt-get source ...; <hack>; reportbug ...
Of course, going through Debian maintainers is not always
reliable or efficient.
I foolishly hoped git-svn would put an end to all the
registration-required bug tracker instances so I could just
send my changes directly to upstream maintainers without any
sort of registration. Did not happen :<
> So unfortunately this thread has devolved. Which is sad. Because all I
> wanted is to have a change in Git's submission process that would not
> exclude *so many* developers. That is really all I care about. Not about
> tools. Not about open vs proprietary, or standards.
>
> I just want developers who are already familiar with Git, and come up with
> an improvement to Git itself, to be able to contribute it without having
> to pull out their hair in despair.
We want the same thing. I just want to go farther and get
people familiar with (federated|decentralized) tools instead of
proprietary and centralized ones.
(*) I wish git could get rid of the DCO, even. But at least
it's far better than the "papers, please" policy for some
GNU projects.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html