On 6/23/2022 11:30 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Jun 23 2022, Derrick Stolee wrote: > >> On 6/23/2022 6:26 AM, Ævar Arnfjörð Bjarmason wrote: >>> This one-patch series integrates the "scalar" command to the >>> top-level, meaning we build the "scalar" binary by default, and run >>> its tests on "make test" and in CI. We'll also build and test its >>> documentation. We now also have "install" support, both for the >>> program and its docs, but you'll need to: >>> >>> make <install-target> INSTALL_SCALAR=Y >>> >>> I'm sending this out now to avoid needless duplicate work. >> >> As mentioned on the list earlier, Victoria is taking over the >> remaining work to complete the Scalar project. Nothing has been >> sent to the list because we didn't want to cause a distraction >> from the release window. > > I was on the fence about sending this out, but given that the "CI" > thread was going on until the start of that window, and wanting to save > her the work of re-discovering the subtle issues with the integration > I'd already fixed I thought it was better ot send it out. The CI thread was halted not just because of the release window, but because of a change in who was doing the work and taking time to revisit the plan of record. This was communicated on-list [1]. [1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2206132246010.353@xxxxxxxxxxxxxxxxx/ The point is that the end goal is still "Get Scalar out of contrib/" but the questions that are still being worked out are things like: 1. _When_ do we integrate Scalar into CI? 2. _When_ do we move Scalar out of contrib/? 3. _When_ do we implement the remaining Scalar features? All three of these questions depend on what the final result will look like, and Victoria is still working on developing her own opinion on that before presenting it to the list in a complete form. Your patch here is interrupting that process. >> Victoria is taking time to incorporate your previous thoughts on >> how Scalar is built and its location in the codebase and create >> a complete narrative of how to get from our current state to that >> point. > > I wasn't sure she was even aware of it, and given that the WIP patch I > saw in my "git fetch" was pretty much a subset of the upthread v1 it > seemed that there was needless duplicate work going on. > > It seemed clear that that WIP patch was attempting to head in the same > direction, but hadn't yet discovered some of the hurdles with > e.g. documentation building & installation that I'd fixed > already. There's also the CMake integration, which I finished up for > this v2. Poking around in people's forks to discover what they have as WIP is not a good measurement of what work is being done or not. A lot of mental energy is being spent in this area. Saying "What I see in this person's fork isn't good enough" is not a reason to move forward on your own. WIP work is WORK IN PROGRESS and is not assumed to be complete or up to expectation for review on the list. > FWIW I have this local change queued on top of this v2, it's all > cosmetic, but probably a good idea. Please stop motivating current patches by work that you have been playing with in your local tree. You do this frequently but it is not helpful. > The $(SCALAR_SOURCES) bit is something I missed, but which Victoria > didn't in her WIP patch (I stole it from there). You also mention this in your cover letter (but is notably absent from the patch itself). I can only attribute your insistence here as a lack of respect for your fellow contributors. There is no rush for this to happen immediately, so the only reason is that you don't trust that it would be done correctly without you submitting the work. Thanks, -Stolee
