git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
Date: Wed, 10 Nov 2021 14:42:22 +0100	[thread overview]
Message-ID: <211110.86czn8hyis.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2111101343570.21127@tvgsbejvaqbjf.bet>


On Wed, Nov 10 2021, Johannes Schindelin wrote:

> Hi Junio,
>
> On Tue, 9 Nov 2021, Junio C Hamano wrote:
>
>> * js/scalar (2021-10-27) 15 commits
>>  - scalar: accept -C and -c options before the subcommand
>>  - scalar: implement the `version` command
>>  - scalar: implement the `delete` command
>>  - scalar: teach 'reconfigure' to optionally handle all registered enlistments
>>  - scalar: allow reconfiguring an existing enlistment
>>  - scalar: implement the `run` command
>>  - scalar: teach 'clone' to support the --single-branch option
>>  - scalar: implement the `clone` subcommand
>>  - scalar: implement 'scalar list'
>>  - scalar: let 'unregister' handle a deleted enlistment directory gracefully
>>  - scalar: 'unregister' stops background maintenance
>>  - scalar: 'register' sets recommended config and starts maintenance
>>  - scalar: create test infrastructure
>>  - scalar: start documenting the command
>>  - scalar: create a rudimentary executable
>>
>>  Add pieces from "scalar" to contrib/.
>>
>>  What's the status of this thing?
>
> It is on hold, for two reasons: we're in the -rc phase now, and I think we
> all need to focus on it.
>
> Ciao,
> Dscho
>
> P.S.: The second reason is that I was uncertain as to your decision
> regarding Stolee's thread about the optimal final location for Scalar.
> Since it seems that we can actually go forward with `contrib/scalar/` even
> if you eventually decide you prefer another place, I plan on submitting a
> new iteration with adjustments for v2.34.0, after that release.

Whatever anyone thinks about Stolee's thread/proposal
(https://lore.kernel.org/git/b67bbef4-e4c3-b6a7-1c7f-7d405902ef8b@gmail.com/)
it's clear that the proposals outlined there describe an entirely
theoretical end-state for scalar that don't line up with the state of
these patches.

That's not just my opinion, here's Stolee agreeing with that:
https://lore.kernel.org/git/9eb8fd45-c8a5-0320-6d38-56389bef193d@gmail.com/

Re: the "status of this thing" I think it's the same it's been for the
last two months:

I've been pointing out things that are objectively broken, and the
response has been pretty much everything except inline commentary on
proposed fixups I've suggested to fix those observed bugs.

The latest being this patch ready to apply on top of js/scalar with no
response for almost 2 weeks now:
https://lore.kernel.org/git/patch-1.1-86fb8d56307-20211028T185016Z-avarab@gmail.com

I'll be the first to admit that *parts* of that are definitely an
opinionated change-on-top.

I also think anyone who'd look at it would agree that it raises issues
that I think could most generously be described as a disconnect between
your commit messages & patches.

Up to and including them making suggestions of running certain commands
either can't work, or don't work as described.

I'll let this be my last word on this whole scalar series saga. I'll
hedge that & say that if you'd like to meaningfully respond to the
fixups I've been suggesting I'm happy to re-engage with you.

"Meaningfully" as in inline commentary on the patch I'm suggesting
explaining why certain things are not OK, don't provide an example of
specific things that don't work/work before/after etc.

That being said no E-Mail like this would be complete without a plainly
worded last few paragraphs, so here goes:

I find it hard to square your comments in other areas about inclusivity
& assuming good faith from other contributors with my experience in
trying to help in moving this scalar thing along.

My honest intentions in this area are just to help what I see as a
useful feature in need of some fixes along.

I've really not been obstinately insisting that you take all my
suggestions. I'd have been fine with most of the points I've raised just
being addressed with something to the effect of "we know <X> is broken,
but that's OK due to <Y>" in relevant commit messages.

But getting even something terse like that in reply has taken a lot of
time & energy on my part.

No hard feelings on my side, although admittedly some baffled
frustration. I do respect you and the work you do, I suspect that on
your side (at least on this topic) that's now closer to "routing the
E-Mails to /dev/null", at least it seems that way from my side.

If you'd like to talk about it (even privately, or over other media) I'd
be happy to. Right now it feel like I've done something to end up your
your shitlist, and I honestly don't know what that could be.

  reply	other threads:[~2021-11-10 14:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10  0:59 What's cooking in git.git (Nov 2021, #03; Tue, 9) Junio C Hamano
2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
2021-11-10 13:42   ` Ævar Arnfjörð Bjarmason [this message]
2021-11-11 18:25   ` Junio C Hamano
2021-11-12  9:32     ` Johannes Schindelin
2021-11-10 13:04 ` jc/fix-pull-ff-only-when-already-up-to-date, " Johannes Schindelin
2021-11-10 17:20   ` Junio C Hamano
2021-11-10 19:00     ` Alex Henrie
2021-11-10 19:09     ` Johannes Schindelin
2021-11-10 19:17       ` Junio C Hamano
2021-11-11 22:19 ` Emily Shaffer
2021-11-11 22:40   ` Emily Shaffer
2021-11-11 22:58   ` Junio C Hamano
2021-11-11 23:44     ` Glen Choo
2021-11-13  9:17   ` ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9)) Ævar Arnfjörð Bjarmason

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

  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=211110.86czn8hyis.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).