Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

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

 



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@xxxxxxxxx/)
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@xxxxxxxxx/

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@xxxxxxxxx

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.



[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]

  Powered by Linux