Re: CFT: snmalloc as libc malloc

On 9 Feb 2023, at 19:46, Warner Losh <imp@bsdimp.com> wrote:
> 
> And that is why we can't just start using submodules. They are not automatically used.

They are not used automatically, but if we were using them then we would have infrastructure in the build system for ensuring that they exist and checking them out if they are not.  

I have written some (trivial) scripts to do this in a dev container recently for another project, the developer experience there is go to github, hit ., hit ‘open in code space’, start writing code in the browser.  

I didn’t do something like that here because I didn't want this tree to contain things that I definitely couldn’t upstream and you’ve made it quite clear that upstreaming will require me to do something different.

> People have to do different things that need to be publicized and well documented.

As with anything involving revision control.

> And there are about a half a dozen decisions that need to be made about the details of their use, many of which have no clear obvious choice for the project. Without a good plan, clear comms and good docs it will be a support nightmare. 

Something I would be happy to work on, but the message that I consistently get is ‘we won’t use submodules, we are not open to a plan to use submodules’.

> Now please stop making these passive agressive comments about submodules. All they do is demotivate me to work on the plans to adopt them. There are a lot of details, many of which need to be play tested, before we can even get a plan to adopt. The snarky comments are why I quit working on things a year ago... they don't move the ball forward and just piss people off...

I will very happily stop making comments about submodules if there is either:

 - A working group that I can participate in to propose a plan for using them.  Or even a willingness, if I write a plan for using submodules, for it to be discussed and not rejected out of hand.

 - An alternative proposal that doesn’t have the downsides that we currently have (for example, forcing everyone to duplicate the history of all every LLVM version that FreeBSD ships in a git clone, difficulty of CI testing contrib components in isolation, complex steps to import a new version from upstream, and so on), or worse down-sides than submodules (e.g. depending on additional tooling that doesn’t integrate with other tools, impossibility of using the tooling on some platforms, massive clone sizes, and so on)

I am frustrated by the fact that the project has real problems that can be solved by submodules, does not want to use them, and does not want to solve them in another way either. I don’t particularly like submodules, I just like the problems that are caused by not using them even less.

David