git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Cc: git@vger.kernel.org, Alexandre Julliard <julliard@winehq.org>,
	Dorab Patel <dorabpatel@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	David Kågedal <davidk@lysator.liu.se>,
	Kyle Meyer <kyle@kyleam.com>,
	Martin Ågren <martin.agren@gmail.com>,
	Ami Fischman <fischman@google.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Todd Zullinger <tmz@pobox.com>
Subject: Re: [PATCH v4] git{,-blame}.el: remove old bitrotting Emacs code
Date: Thu, 12 Apr 2018 18:23:02 +0900
Message-ID: <xmqqa7u83hjd.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <87fu40c3xe.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> On the other hand, the 6-lines of e-lisp you wrote for git.el
>> replacement is something the packagers could have written for their
>> users, so (1) if we really want to go extra mile without trusting
>> that distro packagers are less competent than us in helping their
>> users, we'd be better off to leave Makefile in, or (2) if we trust
>> packagers and leave possible end-user confusion as their problem
>> (not ours), then we can just remove as your previous round did.
>>
>> And from that point of view, I find this round slightly odd.
>
> I think the way it is makes sense. In Debian debian/git-el.install just
> does:
> ...
> RedHat does use contrib/emacs/Makefile:
> ...
> But they can either just do their own byte compilation as they surely do
> for other elisp packages,...

In short, Debian happens to be OK, but RedHat folks need to do work
and cannot use what we ship out of the box, *IF* they care about end
user experience.

That was exactly why I felt it was "odd" (iow, "uneven").  We bother
to give a stub git.el; we do not bother to make sure it would keep
being installed if the packagers do not bother to update their
procedure.

If we do not change anything other than making *.el into stubs, then
it is a lot more likely that end user experience on *any* distro
that have been shipping contrib/emacs/ stuff will by default
(i.e. if the packagers do not do anything to adjust) be what we
design here---upon loading they'd see (error) triggering that nudge
them towards modern and maintained alternatives.  If we do more than
that, e.g. remove Makefile, then some distros need to adjust, or
their build would be broken.

I suspect that the set of people Cc'ed on the thread are a lot more
familiar than I am with how distro packagers prefer us to deliber,
so I'll stop speculating at this point.

Thanks.

  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <EKzyQbDEJGG4Lm5YboF8xg@mail.gmail.com>
2018-03-10 18:45 ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2018-03-13 18:53   ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2018-03-13 22:14     ` Junio C Hamano
2018-03-27 16:57   ` [PATCH v3] " Jonathan Nieder
2018-04-11 20:42     ` [PATCH v4] " Ævar Arnfjörð Bjarmason
2018-04-12  2:19       ` Junio C Hamano
2018-04-12  6:52         ` Ævar Arnfjörð Bjarmason
2018-04-12  9:23           ` Junio C Hamano [this message]
2018-04-18 20:16             ` Todd Zullinger
2018-03-03  3:48 [PATCH] git.el: handle default excludesfile properly Dorab Patel
2018-03-03  8:42 ` Eric Sunshine
2018-03-04  1:36   ` Dorab Patel
2018-03-04  2:12     ` Eric Sunshine
2018-03-04  2:57       ` Dorab Patel
2018-03-04  4:34         ` Eric Sunshine
2018-03-05  2:36     ` Junio C Hamano
2018-03-06 11:54       ` Alexandre Julliard
2018-03-07 21:52         ` Dorab Patel
2018-03-08  9:41           ` Ævar Arnfjörð Bjarmason
2018-03-08  9:45         ` [PATCH] git{,-blame}.el: remove old bitrotting Emacs code Ævar Arnfjörð Bjarmason
2018-03-08 17:27           ` Junio C Hamano
2018-03-10 12:30             ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2018-03-10 16:50               ` Martin Ågren
2018-03-13 18:40                 ` Junio C Hamano
2018-03-08 17:55           ` [PATCH] " Kyle Meyer
2018-03-06  4:38 ` [PATCH v2] git.el: handle default excludesfile properly Dorab Patel

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: 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=xmqqa7u83hjd.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=davidk@lysator.liu.se \
    --cc=dorabpatel@gmail.com \
    --cc=fischman@google.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=julliard@winehq.org \
    --cc=kyle@kyleam.com \
    --cc=martin.agren@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=tmz@pobox.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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox