Open Stack

On Tue, Jun 23, 2020 at 9:55 AM Jeremy Stanley <fungi at 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