From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, William Giokas <1007380@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] remote-hg: getbundle changed in mercurial 3.0
Date: Tue, 13 May 2014 15:59:55 -0500 [thread overview]
Message-ID: <537287cba3013_76dad6b2f8dd@nysa.notmuch> (raw)
In-Reply-To: <xmqqzjilmnad.fsf@gitster.dls.corp.google.com>
Junio C Hamano wrote:
> The way I envision the longer term shape of git-remote-hg.py in the
> contrib/ is either one of these two:
>
> (1) manage it just like contrib/hooks/multimail/, keeping a
> reasonably fresh and known-to-be-good snapshot, while making it
> clear that my tree is not the authoritative copy people should
> work off of;
>
> (2) treat it just like contrib/emacs/vc-git.el, which found a
> better home and left my tree at 78513869 (emacs: Remove the no
> longer maintained vc-git package., 2009-02-07); or
>
> The first one may be more preferrable between the two, if only because
> distros would need time to adjust where they pick up the source
> material to package up, but it still needs cooperation with the
> "authoritative upstream" and this project to allow us to at least
> learn when the good time to import such good snapshots.
I will not do that.
If you want my help to improve *your* tree, you have to start by
answering the *one* question I've repeatedly asked you to clarify.
In fact if you go for this I would consider it an act of sabotage
against these new projects.
If you hadn't made me waste all this time chasing a non-attainable goal,
these projects would already be packaged by distributions, instead of
hidden in some corner of /usr/share.
Distributions wouldn't even be aware of the move, and it might take bug
reports to make them realize that. There will be already enough damage
to the reputation of these tools with Git v2.0 shipping them broken.
Not aligned at all with your previous statement that you wanted these to
"flourisn".
In fact, I think you should remove them already from v2.0. Because this
doesn't need release candidates. Unless you think user feedback will
make you change your mind about not graduating them, moving them in 2.0,
or 2.1 will be the same, since you are going to ignore the feedback
anyway.
This also has the advantage that you won't be shipping them broken in
v2.0.
At the very least there should be a big fat message warning each time
the tools are run, warning the users that they are unmaintained, and the
right location for them. And yes, I also think this should be done for
v2.0.
--
Felipe Contreras
prev parent reply other threads:[~2014-05-13 21:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 19:12 [PATCH] remote-hg: getbundle changed in mercurial 3.0 William Giokas
2014-05-13 20:21 ` [PATCH v2] " William Giokas
2014-05-13 21:00 ` Junio C Hamano
2014-05-13 20:33 ` [PATCH] " Junio C Hamano
2014-05-13 20:59 ` Felipe Contreras [this message]
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=537287cba3013_76dad6b2f8dd@nysa.notmuch \
--to=felipe.contreras@gmail.com \
--cc=1007380@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).