Felipe Contreras <felipe.contre...@gmail.com> writes:

> And you are still conveniently avoiding the question:
>
> Based on what reasoning?

Go re-read what was already said in the thread.  I still think
remote-hg and remote-bzr can and will flourish on their own merit,
and unbundling will be better for the end users for the reasons
stated there already.

Having said that, I've been thinking (not because of this thread,
but because I like imerge better and better these days) that there
should be a much better way to have a list of recommended third-party
plug-ins that enrich the Git ecosystem.  We have 

  https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

(Jakub cc'ed as he often nudges those who announce their tools to
add an entry there) but honestly, git-scm.com is the first site the
end users who do not hack on Git would visit, and we probably should
have a catalog there (Scott and Peff cc'ed for that site).  One way
to help it may be to add a Documentation/gitthirdparty-tools.txt in
my tree that would automatically be pulled into git-scm.com site as
a part of the manual.  A richer ecosystem with tools outside my tree
would not materialize unless there is such a mechanism to advertise
the existence of them, and having to include a copy of each and
every third-party tools in my tree and keeping them relatively fresh
is not going to scale in the long run (Michael and Matthieu Cc'ed as
I saw exchanges on multimail in a near-by thread).

Such a file would probably cluster "plugins" into different
categories (post-receive hooks, remote-helpers, mergetools, etc.)
and limit the entry descriptions to a single paragraph of several
lines tops, with URL referring to the third-party maintainer's site
(e.g. a repository at GitHub).

>> > Of course it wasn't a mistake.
>> 
>> I doubt about the "Of course" part.  The first reaction after seeing
>> that the new "changegroup" is used only inside check_version(3,0)
>> and nowhere else was to wonder if that import is necessary (or even
>> safe) for the pre-v3.0 versions.
>
> I don't care about your first reaction. If that was only present in
> newer versions, how do you think it would pass the testing on older
> versions?
>
> https://travis-ci.org/felipec/git
>
> Normally I would explain the details of why this is the case, and send
> the crash regresion fix for v2.0 with a clear explanation,...

Without such an explanation in the log message, how would you expect
anybody to guess correctly?

Seriously, if you do not care about my first reaction, why do you
even want to live in my tree?

> The fact that I'm the maintainer and I say it'ss good should be good
> enough, and if the current version in "master" renders unusable the
> existing Mercurial clones, hey, it's only in contrib, right?

One potential merit I would see for keeping them in my tree is that
your change will see second opinions from others involved in the
project (including me), without giving a total rein based on the
sub-maintainership alone.  All the changes from sub-area maintainers
are vetted by at least two sets of eyeballs that way.

But after having to deal with you and seeing that you do not take
constructive criticism well, I doubt such a possibile merit will
ever materialize in the area where you alone work on.  Letting you
do whatever you want in your own tree may benefit the users of
remote-hg/remote-bzr better as the (bitter) second best option.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to