On Sun, 7 Feb 2021 at 13:46, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 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. > [0] - https://github.com/coreos/fedora-coreos-tracker/issues/480 [1] - https://github.com/coreos/fedora-coreos-tracker/issues/704 [2] - https://builds.coreos.fedoraproject.org/browser?stream=rawhide [3] - https://twitter.com/FedoraCoreOS/status/132958663213628211 > Zbyszek > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
