On Tue, Jun 23, 2020 at 9:55 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-06-23 09:25:40 +0900 (+0900), Akihiro Motoki wrote: [...]
Regarding a topic of packaging raised by zigo, I am not sure it is a problem the OpenStack community should solve. I know legacy packagers would like to use single versions of libraries in their contents at the same time so they don't like npm/yarn based JS dependencies. [...]
It's rather insulting to refer to distribution package maintainers as "legacy packagers" implying that distros are somehow outmoded. I'm sure you're a fan of just cramming random source into a container and crossing your fingers, but what non-distro sort of platform do you build and start that container on? Something which doesn't use "legacy packages" I suppose?
I think it's perfectly valid to want software which is mature enough to have ABI versioning and generous compatibility ranges for its dependency chain, and which sticks to a minimal set off well-established requirements rather than just grabbing whatever's shiny and new. Traditional Linux distributions and Unix derivatives understandably struggle with the chaos in programming language ecosystems like Javascript and Golang which are still very much in infancy and haven't settled into particularly mature and supportable patterns yet. This sort of fast and loose mentality may be great for prototyping new software, but the constant churn in dependencies and frameworks makes such solutions essentially unsupportable except by their upstream developers. For now you basically get to decide between being technical support for anyone who wants to use your software, or building it with languages and dependencies which can actually be supported by "legacy packagers." -- Jeremy Stanley
I am really sorry for my poor word selection. I didn't have an intention to give such negative impression. It is totally my bad. I think I understand what distributions provide. They provide working sets of softwares verified from various perspectives. We cannot setup most deployments without distributions easily. The point I would like to mention is why we need to avoid using the well-known dependency management systems in the JavaScript community from the beginning. I think the problem is not which system(s) we use for dependency management. What we need is to define a proper versioning strategy in the project at some point of maturity of a software. I think we are in a dilemma between the current state of JavaScript community and supportability (packaging perspective highlights it first). Minimum set of dependencies would be great and it would help maintaining a software, but it is one of the considerations when selecting technologies. I am also worrying about the number´of developers in the dashboard. While I am not sure that adoption of recent technologies attract more developers or not, I would not block this kind of efforts to improve the GUI. 10 years passed since OpenStack started, so JavaScript world changes a lot and things are done more easily in recent technologies. Back to packaging, I am also not sure whether the xstatic mechanism should continue. All updates in their upstreams need to be checked (manually now) and we usually tend to be behind it even if there is a security update. "Double packaging" is not efficient. Horizon upstream packages JS libraries into xstatic and distros packages it into their packages. --amotoki