From: Jeff King <firstname.lastname@example.org> To: Stefan Beller <email@example.com> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, Eric Wong <firstname.lastname@example.org>, email@example.com, "firstname.lastname@example.org" <email@example.com> Subject: Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Date: Mon, 22 Aug 2016 15:21:52 -0400 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAGZ79kb9x6RHdFeA8WXpq4NFYr-G+B1R7_8u883LO8zvPyr+CQ@mail.gmail.com> On Fri, Aug 19, 2016 at 09:55:54AM -0700, Stefan Beller wrote: > It was not my intend to start this discussion again with my initial email. > I rather wanted to point out how I make progress in doing my own > tooling. > > I mean if email works well for Junio (both as a maintainer as > well as a contributor) and Jeff as a contributor, then I can adapt > my workflow to that, because these two have brought in > 8300 of 33000 non merge patches. (i.e. they had 25% of the > patches over the life time of the project and are with the project > longer than others IIUC). So why would I demand they change > their style just to accommodate one newcomer like me? Even though I do really like the mail-based workflow, I think this is a dangerous line of reasoning. If the project were just me and Junio, working as efficiently as two people possibly can, then sure, asking us to change from what works for us would be silly. But it's not. We have to make sure that the project community thrives. That includes catering to some degree to occasional contributors, and doing things to attract new members to the community as old ones drift away. You'll notice that I hand-waved away "to some degree" there. There is definitely a balance to be found in managing the time of the maintainer and the reviewers, versus making things easier for new contributors. As a reductio ad absurdum, the simplest thing for contributors would be to make a vague bug report and have the maintainer produce a polished patch. That obviously does not scale. :) Likewise, it is not just a matter of time spent, but workflows impact _who_ will join. Contributing to git is very friendly to a certain niche of Unix die-hards, and that impacts who bothers to do so, and consequently, what contributions we see (both to code and to discussion). There's value in diversity of opinions, and we should be wary of becoming an obsolete and out-of-touch mono-culture. So I say "dangerous" because that is one way that open source projects can die: the number of contributors dwindles, development slows, there are no new ideas in the community, etc. I don't think git would ever die off completely; there are too many users. But there have been projects that seem to ossify for many years, and are rejuvenated only when they shake up some elements of the community or workflow (e.g., mutt is recently seeing such a resurgence; sometimes it even takes the form of a follow-on project, like CVS->SVN, with new people). I don't think we're at that point with git. But it is something to be mindful of. It's not clear to me if mutt-loving luddites like myself are the last of a dying breed, or if there will always be enough of us to churn out contributions to projects like git. -Peff  I think Dscho feels this much more acutely on Git for Windows than we do on the regular git mailing list, because the "who" audience for GfW is much different than the Unix world.  I also think there's such as a thing as "too many opinions" in a project. If we started rewriting bits of git in Haskell (just to pick on a random pretty-far-from-C language), things would get very complex very quickly. So again, it's about finding a balance.
next prev parent reply index Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-16 16:55 Stefan Beller 2016-08-16 17:10 ` Junio C Hamano 2016-08-16 17:20 ` Jeff King 2016-08-16 17:54 ` Junio C Hamano 2016-08-16 17:22 ` Stefan Beller 2016-08-16 17:47 ` Junio C Hamano 2016-08-16 20:44 ` Eric Wong 2016-08-16 20:56 ` Eric Wong 2016-08-18 12:42 ` Johannes Schindelin 2016-08-18 20:49 ` Eric Wong 2016-08-18 21:41 ` Junio C Hamano 2016-08-19 15:18 ` Johannes Schindelin 2016-08-19 15:30 ` Johannes Schindelin 2016-08-19 16:55 ` Stefan Beller 2016-08-19 22:35 ` Eric Wong 2016-08-22 13:38 ` Johannes Schindelin 2016-08-22 19:21 ` Jeff King [this message] 2016-08-19 22:35 ` Eric Wong 2016-08-22 13:18 ` Johannes Schindelin 2016-08-22 18:05 ` Jakub Narębski 2016-08-25 13:21 ` Johannes Schindelin 2016-08-28 18:23 ` Jakub Narębski 2016-08-29 10:46 ` Johannes Schindelin 2016-08-22 22:55 ` Eric Wong 2016-08-25 12:58 ` Johannes Schindelin 2016-08-27 22:38 ` Jakub Narębski 2016-08-28 8:36 ` Working with public-inbox.org Johannes Schindelin 2016-08-28 11:41 ` Jakub Narębski 2016-08-29 5:35 ` Johannes Schindelin 2016-08-19 15:03 ` Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Jeff King 2016-08-20 19:57 ` Jakub Narębski 2016-08-23 4:47 ` Arif Khokar 2016-08-24 15:34 ` Johannes Schindelin 2016-08-24 18:49 ` Eric Wong 2016-08-24 19:12 ` Jeff King 2016-08-24 19:27 ` Eric Wong 2016-08-25 3:40 ` Arif Khokar 2016-08-25 2:41 ` Arif Khokar 2017-02-10 16:10 ` Johannes Schindelin 2017-02-13 5:52 ` Arif Khokar 2017-02-13 14:37 ` Johannes Schindelin 2017-02-14 3:56 ` Arif Khokar 2017-02-14 3:59 ` Arif Khokar 2017-02-14 7:13 ` Eric Wong 2017-02-13 19:21 ` Junio C Hamano 2017-02-14 3:55 ` Arif Khokar 2017-02-14 4:41 ` Junio C Hamano 2017-02-14 5:09 ` Arif Khokar 2017-02-14 5:14 ` Jeff King 2016-08-22 13:06 ` Johannes Schindelin 2016-08-22 13:15 ` Duy Nguyen 2016-08-22 20:38 ` Philip Oakley 2016-08-24 13:04 ` Johannes Schindelin 2016-08-24 19:16 ` Eric Wong 2016-08-25 13:08 ` Johannes Schindelin 2016-08-25 3:57 ` Arif Khokar 2016-08-25 13:01 ` Johannes Schindelin 2016-08-25 23:14 ` Arif Khokar 2016-08-26 8:08 ` Johannes Schindelin 2016-08-27 22:26 ` Jakub Narębski 2016-08-28 8:38 ` Johannes Schindelin 2016-08-28 13:45 ` Announcing Git User's Survey 2016 [was: Working with public-inbox.org] Jakub Narębski 2016-09-09 13:06 ` Johannes Schindelin 2016-09-09 18:51 ` Jakub Narębski
Reply instructions: You may reply publically 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: https://public-inbox.org/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
user/dev discussion of public-inbox itself Archives are clonable: git clone --mirror https://public-inbox.org/meta git clone --mirror http://czquwvybam4bgbro.onion/meta git clone --mirror http://hjrcffqmbrq6wope.onion/meta git clone --mirror http://ou63pmih66umazou.onion/meta Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta nntp://ou63pmih66umazou.onion/inbox.comp.mail.public-inbox.meta nntp://czquwvybam4bgbro.onion/inbox.comp.mail.public-inbox.meta nntp://hjrcffqmbrq6wope.onion/inbox.comp.mail.public-inbox.meta nntp://news.gmane.org/gmane.mail.public-inbox.general note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git