Re: What's cooking in git.git (May 2014, #02; Fri, 9)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]