git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kannan Goundan <kannan@cakoose.com>
To: git@vger.kernel.org
Subject: Re: Make "git checkout" automatically update submodules?
Date: Fri, 23 Oct 2015 03:46:47 +0000 (UTC)	[thread overview]
Message-ID: <loom.20151023T044009-172@post.gmane.org> (raw)
In-Reply-To: xmqq37x2qqzf.fsf@gitster.mtv.corp.google.com

Junio C Hamano <gitster <at> pobox.com> writes:

> We are unfortunately not set up to handle money well.  For a
> background explanation, please go read [*1*], which I wrote my take
> on "money" some time ago.  Note that it is an explanation and not a
> justification.  It explains why we are not set up to handle money
> well and what the issues around money that are troublesome for the
> project are.  It does not mean to say that it is a good thing that
> it is hard to buy feature with money from our project [*2*].

I think the way I described it ("sponsoring a feature") doesn't really
reflect how I was imagining it.  In my head, it looked like this:

1. Figure out whether the Git community and maintainers seem ok with the
overall feature idea.  If not, give up.
2. Come up with a plan for the UI/UX; see if the Git community and
maintainers seem ok with it.  If not, iterate or give up.
3. Implement it, then go through the regular process of getting it merged
upstream.  If it doesn't go well, might have to iterate or give up.

I could try doing that myself, but someone familiar with the Git
codebase/community/history would be better at it (and probably be easier for
you guys to work with :-)

I guess I'm just wondering if there are people who meet those qualifications
and are interested in going through those steps for pay.  Or maybe there's a
company that does this, like the old Cygnus Solutions?

In particular, I don't expect anything to change about the project's
development process.

(This part is not relevant to the Git project, but I understand that it's
hard for anyone to guarantee a feature will make it into an open source
project.  I imagine these kinds of contracts are set up so that you're
primarily paying for the effort, not the outcome.  If it ends up not working
out, you don't get your money back.)

  reply	other threads:[~2015-10-23  3:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15 22:50 Make "git checkout" automatically update submodules? Kannan Goundan
2015-10-15 23:21 ` Junio C Hamano
2015-10-22 23:46   ` Make Kannan Goundan
2015-10-23  2:05     ` Make Junio C Hamano
2015-10-23  3:46       ` Kannan Goundan [this message]
2015-10-23  6:19         ` Make "git checkout" automatically update submodules? Christian Couder
2015-10-23 17:15         ` Junio C Hamano
2015-10-23 17:20 ` Stefan Beller
2015-10-23 19:11   ` Junio C Hamano
2015-10-23 22:51   ` Kannan Goundan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20151023T044009-172@post.gmane.org \
    --to=kannan@cakoose.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).