On 07/06/2017 02:58 PM, Owen Taylor wrote:
On Thu, 2017-07-06 at 13:39 -0400, langdon wrote:
On 06/29/2017 11:30 AM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:
So my expectation is that the number of "collections modules"
that have no strong connection to a particular upstream release
process will be small and well defined - say Platform, Runtime,
System Tools, and a few more. As such, I think it *would* be
reasonable to say that they all are versioned at the same tempo
and even keep the F<N> stream naming.
Langdon? Rebuttal? :
I think containers are just a packaging type. In other words, whether
the "thing" is delivered as a docker container, flatpak,
rpm, something-not-though-of-yet, it is still the same module. This
is kind of the point, we want to disconnect the "content needed to
provide the service" from the "packaging mechanism to deliver the
content" (very loosely). As a result, we may see many different
module collections of stuff even if they are only being shipped as
containers (or whatever).
I think you make different decisions depending on how you expect your
module to be packaged/deployed.
So, I am not sure. I think Owen may have a point, but I think whether
we have "many" collections will evolve over time. However, I
definitely would not agree with the f<n> naming because why would it
need to "stream change" because of the fedora base? In other
words, a new stream indicates a new ABI/API but, I can tell you, no
matter how many versions of fedora go by, we are never gonna drop
emacs OR vi from the system-tools type collection so why would the
stream change? The module should be allowed to make decisions on its
content based on its own timescale not an arbitrary release boundary.
I think this applies to "collections of stuff" just as much as the
more obvious "single applications."
But dropping emacs out of the system-tools collection would only be one
form of ABI/API breakage. The following can also be breakages:
* Upgrading a package, if the package changes its ABI, API,
configuration files or command line options.
* Adding a new package (the new package may conflict with packages
from other modules with unpredictable results)
And if module A depends on module B, and module B changes its ABI/API,
that also effectively changes the ABI/API of module A in the general
case.
One of the main ways we have of handling this fragility is to
distribute in a container (or container-like thing). If you design for
distributing in a container, and always distribute in a container, then
consumers can ignore a lot of things that happen inside the module.
But for a module that is not containerized, that has a lot of packages
in it, that depends on the Fedora Platform module, I think that the
only realistic model that provides API/ABI stable streams is to release
new streams often, probably in sync with the Platform model, and not
change the streams much after release.
I think the modules:
a) need to assume, as much as possible, that they are independent from
all other modules that they don't depend on. We may need to provide some
tooling that makes this "true" but that is ok
b) a module should depend on as few other modules as possible, in other
words, just host&plat and shared-userspace. Otherwise, your lifecycle,
as you say, is bound to the other module.
I think you are probably right, at first. However, I expect, over time,
that this will shift. Either more things will be containerized, the
dependency set will get cleaner, better bundling methods will be
supported, etc.
Whether those streams are called F<n> or 201806 or whatever is a
somewhat arbitrary choice.
so ^^ yes.. but as in the rest of this thread.. I strongly disagree with
the perception of binding to a "release" even if, for some period of
time we most of the time do. If we don't carefully & quickly move away
from the "release" terminology, the flexibility will be lost because
people will think there is a requirement of a lock when there may not,
in fact, be.
Langdon
Owen
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
