On Sun, 7 Feb 2021 at 13:46, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
On Sat, Feb 06, 2021 at 10:41:16AM +0100, Clement Verna wrote:
> Recordings are available on Fedora's youtube channel
>
> Growing Fedora CoreOS Community :
> https://www.youtube.com/watch?v=HSuBWeosAvQ
> Fedora CoreOS as an Official Edition :
> https://www.youtube.com/watch?v=t5VAw8NRXNc
>
> You can also find the discussions notes here :
> https://github.com/coreos/fedora-coreos-tracker/pull/732/files -
> Pull-request but that should be merged soon :)
Hi Clement,
thanks for making those available.
Thanks for taking the time to watch it and provide feedback :-)
I listened avidly to the discussion, and here's my take on the subject
of "FCOS as Edition":
in the discussion, you asked whether there should be "FCOS 33", "FCOS
34", etc, and the answer was an emphatic "no". My answer is "yes".
What do I mean by that? I think it's fine to have a *goal* of just a
smooth FCOS stream, i.e. to make the underlying Fedora version
unimportant to users. But as a practical matter, it'll not be
achievable and FCOS should instead accept that as long as FCOS is
based on Fedora, the choices that Fedora "proper" makes and the
cadence of releases will be visible in FCOS. As mentioned in the
discussion "the package set is fairly vanilla bodhi stable with a bit
of delay for the two week promotion timing". Even if FCOS is just a
subset of those packages, the semiannual jump in package versions and
configuration choices must be visible to some extent.
I think a lot of the work and thoughts that went into designing the stream release process was to effectively hide
or at least make the semi-annual jump in package versions a non event. The update barrier approach [0]
that is currently in use is a good example. Currently a user might notice a Fedora version bump only because of an extra
update and reboot.
IMO having to worry or know which Fedora version is used as a base for FCOS is defeating the point of FCOS and
automatic updates.
There seems to be a broad consensus that FCOS should participate more in
the Fedora Change process: both to monitor announced Changes and to
announce changes in FCOS using a similar process.
I believe that we are already doing a good job at monitoring the announced changes [1] but
yeah we definitely can do better at announcing changes in FCOS.
But I think FCOS should go a step further, and also *declare* that it
follows the Fedora schedule. I do *not* mean by that FCOS stable
stream should by switched on the same day that other Fedora editions
make a release. The two week delay is quite reasonable. (In fact,
seasoned users of Fedora "proper" know not to update immediately on
the release day, and instead wait two or three weeks for wrinkles to
be ironed out. Since FCOS does updates automatically, I think it's
totally reasonable to bake such a delay into the plan.) But we should
be able to say, in the release announcements, that "Workstation,
Server, etc. release today, and FCOS switch of stable stream will
follow in two weeks, if no last minute bugs are discovered. Users who
want to preview the next version, should use the devel stream."
So I personally don't agree with that, IMO there is nothing wrong with the stable stream not
being on the latest version of Fedora as long as it is using a base version that is supported.
I associate stable with words like slow, solid, robust,etc ... If we provide support for ~1 year why
not make use of that ? FCOS values stability over new features.
That said I think the goal is to make the switch as soon as possible and things like having a rawhide
stream [2] will certainly help.
In the case that we want to tightly couple FCOS stable stream to the latest Fedora version then we should be ready to
delay the GA of other Editions until FCOS as a working stable stream.
About release announcement, I believe that FCOS should follow it's own life and announce changes
and major features as they happen. This is something we have to improve on (we already do some announcement [3])
and ideas like having a monthly newsletter are possibilities.
I don't think that making FCOS an edition means that we have to mention it when
other editions are released.
Matthew said that users should be able to see all editions on
getfedora.org, and it would be great to also have FCOS there, but it
means that FCOS stable must be available on a predictable schedule.
It is already there in the "Emerging Fedora Editions" sections, the website is also automatically updated
when new streams are released every 2 weeks.
I think that tying FCOS to the the release schedule of other editions
will actually be more of a change in perception than any reality,
since FCOS already is following the bodhi update stream. FCOS has the
ability to delay some changes and to apply local overrides. But doing
that burns FCOS maintainer time, and ideally, should not be
necessary. But changes that are bad for FCOS are probably bad for at
least some users of other editions. *If* FCOS embraces the Change
process and the effect of any and all changes on FCOS is evaluated
early enough, those "downstream" overrides in FCOS should be replaced
by fixes in the packages themselves, with a benefit to non-FCOS users
too.
I might be wrong but all the override applied are coming from bodhi we never patch something
directly in FCOS. So I think changes that are needed for FCOS are always available to
non-FCOS users.
If I got that wrong, could you provide an example ?
In summary, becoming an Edition goes both ways: it constrains what
FCOS can do, but it also allows FCOS to influence what happens in
Fedora "proper". Marketing FCOS and other editions together will offer
our users a more complete choice and strengthen the Fedora brand.
It'll also make FCOS more visible and more trusted.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
