All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (May 2014, #02; Fri, 9)
Date: Sun, 11 May 2014 10:51:19 -0700	[thread overview]
Message-ID: <xmqqk39suru0.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <536d4bd48e3f9_585ea5308b2@nysa.notmuch> (Felipe Contreras's message of "Fri, 09 May 2014 16:42:44 -0500")

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

> Junio C Hamano wrote:
>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>>  - remote-hg: trivial cleanups
>>  - remote-hg: make sure we omit multiple heads
>>  - git-remote-hg: use internal clone's hgrc
>>  - t: remote-hg: split into setup test
>>  - remote-hg: properly detect missing contexts
>>  - remote-{hg,bzr}: store marks only on success
>>  - remote-hg: update to 'public' phase when pushing
>>  - remote-hg: fix parsing of custom committer
>>   (merged to 'next' on 2014-04-22 at fed170a)
>>  + remote-helpers: move tests out of contrib
>>  + remote-helpers: move out of contrib
>>  + remote-helpers: squelch python import exceptions
>> 
>>  As there were announcements for these two to be maintained as
>>  independent third-party projects ($gmane/248561, $gmane/248583),
>
> Clarification: after Junio unlilaterally blocked any further progress
> towards grauduation to the core, which was the intention since the very
> beginning.

After seeing your repeated attempts to spread misinformation, I was
planning to totally ignore you, but because "What's cooking" is one
of the important project-wide report, I'll respond one last time.

Even though I was originally leaning towards moving them into core
(after all, why would I have merged the bottom three commits to
'next' otherwise?), I was later convinced, during the discussion
that started with John Keeping's objection [*1*], that I was wrong,
and if they moves outside contrib/, the best direction for them to
go is not to the core but to become independent third-party plug-in
for allow users to pick up the latest without being restricted by
our release schedule to ensure no-regressions to the entire system.

At some point I have to decide what would be the best next step, and
your counter-arguments did not make much sense to me.  The decision
is that the best course for these two is either staying in contrib/
if they are not ready, or becoming independent third-party projects
if they are.

Is making that decision as the maintainer unilateral?

I would not mind asking the others, as your discussion tactic seems
to be "repeated voices start sounding like a chorus, and a chorus is
project concensus".

Those who are observing from the sideline, please raise your hand if
you think the three-line "Clarification" Felipe gave us is a fair
and accurate clarification.  Anybody?

I also do not mind seeing hands raised of those who do not agree,
even though I already know that they would be a silent majority.

Remember, I intend to make this message the "one last time" one.  In
the past, any time you made absurd claims by twisting facts and what
other people said, I tried to contain the damage to innocent
bystanders (who may not know Git and the history of the discussion
well enough to make their own judgment) by double-checking facts and
correcting you.  These days, I still do the same fact-checking,
which steals time from the project that would be better spent in
other ways, but because I know your counter-arguments will be
nitpicking on subissues that do not matter in the larger picture and
resulting back-and-force will end up wasting a lot more time without
anything to improve the project, I started to apply the "do not feed
a troll".

I'll stop wasting time even on fact-checking from now on whenever
you say anything.  It's not worth the project's time.


[Reference]

*1* http://thread.gmane.org/gmane.comp.version-control.git/248641/focus=248643

  reply	other threads:[~2014-05-11 17:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 21:06 What's cooking in git.git (May 2014, #02; Fri, 9) Junio C Hamano
2014-05-09 21:42 ` Felipe Contreras
2014-05-11 17:51   ` Junio C Hamano [this message]
2014-05-11 18:06     ` David Kastrup
2014-05-11 23:03     ` Felipe Contreras

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=xmqqk39suru0.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.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
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.