All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	Duy Nguyen <pclouds@gmail.com>,
	git-for-windows <git-for-windows@googlegroups.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3
Date: Tue, 23 Aug 2016 12:25:06 -0700	[thread overview]
Message-ID: <xmqqzio3uw31.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1608231758260.4924@virtualbox> (Johannes Schindelin's message of "Tue, 23 Aug 2016 18:05:32 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> In case it is not crystal-clear, let me clarify one very important point.
> It seems that some people mistake the work I do for something I do on a
> whim. This is not so.
>
> The patch series that triggered this entire unfortunate discussion
> introduced the --smudge option, which I have subsequently renamed to
> --filters and submitted as a patch series to the Git project.

As the "--filters" is meant as a new feature, it will not land on
the maintenance track.  It is very likely that it won't be in 2.10,
so it won't appear in 2.10.x maintenance track, either.

I do not agree with Duy that the "port to Windows" needs a separate
distinct name, though.  Having said that, aside from the issue of
handling of bugreports has been already meantioned, which mostly
costs for Git developers, whatever new feature you unleash ahead of
upstream to your Windows port has cost to your end-users.  Its
implementation or its external interface may have to change when you
upstream the new feature that has already been in the field, and
your end-users would have to adjust their scripts and/or muscle
memory.

One way to avoid that risk may be to release the new feature as
"experimental-and-subject-to-change", so that interested users on
Windows can actually try it out to see if the feature itself
(whatever its interface to them is) makes sense, and you can gauge
the value of upstreaming it, while cautioning these early adopters
that it has not fully been through the usual review process and may
have to change while becoming part of the official release.  This is
no different from various "experimental features" we unleash to the
wild, either via 'master' or keeping it in 'next' (we tend to do
more of the latter, marking "see if anybody screams").




  reply	other threads:[~2016-08-23 19:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13 10:14 [ANNOUNCE] Git for Windows 2.9.3 Johannes Schindelin
2016-08-13 15:50 ` Junio C Hamano
2016-08-17 13:54   ` Johannes Schindelin
2016-08-17 15:29     ` Junio C Hamano
2016-08-18  8:37       ` Johannes Schindelin
2016-08-22 14:04         ` [git-for-windows] " Duy Nguyen
2016-08-23 13:54           ` Johannes Schindelin
2016-08-23 14:41             ` Michael J Gruber
2016-08-23 15:37               ` Johannes Schindelin
2016-08-23 16:05                 ` Johannes Schindelin
2016-08-23 19:25                   ` Junio C Hamano [this message]
2016-08-23 21:42                     ` Junio C Hamano
2016-08-24  1:04                       ` Dakota Hawkins
2016-08-24 15:41                         ` Git for Windows documentation, was " Johannes Schindelin
2016-08-24 16:06                           ` Dakota Hawkins
2016-08-24 23:28                             ` Philip Oakley
2016-08-25 11:42                             ` Johannes Schindelin
2016-08-24 15:39                     ` Johannes Schindelin
2016-08-24  5:09                   ` Junio C Hamano
2016-08-24 15:48                     ` core.autocrlf, was " Johannes Schindelin
2016-08-24 16:45                       ` Junio C Hamano
2016-08-25 11:54                         ` Johannes Schindelin
2016-08-25 12:43                           ` Torsten Bögershausen
2016-08-25 13:50                             ` Johannes Schindelin

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

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

  git send-email \
    --in-reply-to=xmqqzio3uw31.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.