Emerging editions, Fedora 32 Beta, and bureaucracy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So, today is the Fedora 32 Beta release date. If you examine the
release announcement:

https://fedoramagazine.org/announcing-the-release-of-fedora-32-beta/

and the current state of the download site:

https://getfedora.org/

there are three fairly significant things entirely missing. Those three
things are the things that getfedora.org calls our 'Emerging Fedora
Editions' - the things that are allegedly the 'future of Fedora': IoT,
CoreOS and Silverblue.

This is approximately how I currently understand things regarding those
editions:

1) Silverblue - this is kind of the simplest. Silverblue is built as
part of the regular Fedora composes. Silverblue image builds failed in
the actual Beta compose, which was unfortunate but not release-blocking 
as SB is not yet tagged release-blocking, so the Beta we signed off has
no SB images. At the go/no-go and readiness meetings, IIRC, we agreed a
rough plan that we would nominate images from a nightly compose built
after the packages in Beta had been pushed stable to release alongside
the Beta.
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200314.n.0/compose/Silverblue/
should work fine for that purpose, but it seems not everything
necessary to actually get that plan implemented has happened, at least
not yet - I see no mention of this in the release announcement or on
getfedora.org .

2) IoT - as I've been trying to annoy people about for a few weeks now,
IoT is not built as part of our main 'Fedora' composes:
https://pagure.io/fedora-iot/issue/24
this is a significant difference from just about everything else in
Fedora. We have several of these kinda 'variant' composes, but the
others are only used to do nightly builds of specific images for stable
releases *after* the release happens. For Rawhide and Branched
releases, those images are built in the main 'Fedora' compose. IoT is
the first and only thing (aside from CoreOS...which we'll get to in a
minute) which is being built outside of the 'Fedora' compose for
Branched and Rawhide. This means we don't have IoT images in the Beta
compose or indeed in any of the main Fedora 32 Branched composes and it
falls effectively entirely outside the existing processes for testing
and releasing stuff. That wouldn't be a problem if IoT were some
unimportant thing we didn't care about, but that doesn't seem to be the
case. It also wouldn't be a problem if this had all been figured out
ahead of time and a plan had been put in place for how exactly we were
going to validate and ship IoT releases, but that doesn't seem to have
been the case either. I keep filing tickets and bugging people and
there have been some back channel discussions and things, and a few of
us as individuals are making up a validation process as we go along as
best as we can, but there doesn't seem to be anything on paper aside
from
https://docs.fedoraproject.org/en-US/iot/edition-promotion/ , which
doesn't really address QA and release process stuff much and seems to
be rather old. As far as F32 Beta goes, again we roughly decided at
Go/No-Go and readiness to identify a specific compose that 'matched'
Beta and ship the bits from that -
https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-32-20200314.0/compose/IoT/
would seem to fit the bill, and pwhalen has done validation testing on
it at
https://fedoraproject.org/wiki/User:Pwhalen/QA/IoT/Fedora-IoT-32-20200314.0 ,
but again this plan doesn't seem to have got as far as getfedora.org or
the Beta release announcement.

3) CoreOS - CoreOS is just a *whole* other thing. It is not built like
the rest of Fedora at all. It's not built as Pungi composes, whatever
compose process it does have doesn't run alongside our other compose
processes or output to the same locations, it's like a whole other
product. It also doesn't seem to be terribly well documented (I can't
find any detail on the wiki, docs sites, or any of the git repos I
happen to know of) or even introspectable - for instance, ISO locations
look like
https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200223.3.0/x86_64/fedora-coreos-31.20200223.3.0-live.x86_64.iso
, but if you try and browse around that tree by visiting URLs like
https://builds.coreos.fedoraproject.org/prod/streams/ , you just
get 'Access Denied'. So if the process appears to have broken down and
some poor monkey like me is left trying to help people figure out where
they can get a 'Fedora CoreOS 32' image to try - it isn't very easy.
Right now I simply have no clue if there is something you could
reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it.

So, in practical terms for Fedora 32 Beta: it would be good if we could
complete the plan of identifying SB and IoT nightly images to place
alongside the Beta release, and update getfedora.org (and maybe the
Beta release announcement) to refer to these. For CoreOS, it would be
good if we could...I don't know...do something? To call something
'Fedora CoreOS 32 Beta' and let people install it? Or at least
explicitly say that there isn't one for $REASONS?

In wider terms: I've been bugging specific people/teams about this in
less public channels for a while now, but mattdm said I can be more
annoying about it, so now I'm gonna bug people about it in these more
public channels! For our so-called Emerging Editions (especially IoT
and CoreOS, Silverblue pretty much gets a pass here) - the 'future of
Fedora' - we need better process than this. We need more bureaucracy
than this!

I know bureaucracy isn't exciting and there are always 'real' problems
to fix instead. I know our existing compose/test/release process is
old-fashioned and unwieldy and monolithic and takes forever. But it has
the advantage that it is a complete, end-to-end, more-or-less-fully-
documented process that all the teams involved understand. The
developers of the existing Editions (and other spins/labs), releng, QA,
websites and communications folks all understand the existing sausage
factory and all the bits are joined up well enough that when we push
the big red button, everything works. The bits get built, the release
validation process kicks in, the bits get tested. The Beta release
announcement talks about Workstation and Server and the spins and labs.
getfedora.org provides download links for them.

I totally get that the existing process can be constricting and it's
reasonable to want to do things a little differently (IoT) or a lot
differently (CoreOS). But if we're gonna do that *and make these things
important parts of Fedora and not just sandbox projects*, then we need
to start working on making the new way of doing things as well-oiled
and integrated with other teams as the old way of doing things. The new
processes doen't just have to work for the team that are making the
things, they have to work for other teams all the way down the line so
that this kind of situation doesn't happen; there needs to be clarity
on how we are actually going to build and validate and ship and
announce these things. It doesn't have to work the same way we've been
doing it the last few years at all. We can experiment with different
schedules for different editions, we can experiment with different
release approaches that make sense for different products, we can do
all kinds of stuff. But in order to do it properly, we need better
process.

Some specific ideas: FESCo and/or the Council should be taking a
stronger lead here. I'd view the Fedora.next process as a good model
for this. In Fedora.next there was a really strong model set up for how
we were going to create these 'Editions': every Edition had to have a
PRD and a tech spec, every edition had to be built and tested and
shipped together in the same release process, we had to have release
criteria and validation testing for every edition, and all the editions
had to be presented together with good strong unified branding on
download pages and so on. The whole process of bootstrapping the
editions was extensively tracked with issues and meetings and regular
status updates and all of that kind of stuff. FESCo kept strong lines
of communication between the teams working on the editions and teams
like releng and QA and websites and docs so that everyone understood
what was happening and what the schedules were and what needed to be
done by when.

This is what I feel like we're missing with these 'emerging Editions'.
I like that as a catch-all for these three things that are obviously
important to Fedora's future, but right now all it seems to be is a
phrase on the download page. There doesn't seem to be a process for how
an 'emerging Edition' becomes a fully-fledged Fedora edition and takes
its place alongside (or replaces one of) our existing ones. I can't,
for instance, find a FESCo or Council ticket somewhere for 'Fedora IoT
becoming an official Edition' where the concrete things necessary to
make that actually happen are defined and tracked. No-one has really
come to a QA meeting and said "hey, so we have this idea to make IoT
and CoreOS fully-fledged, release-blocking Fedora editions in future,
how do you think that would look from a QA perspective? What needs to
happen? Want to come to a FESCo meeting and talk about it?" and then
followed up on it, IIRC. All of that happened for the initial
Fedora.next process. I've had various conversations like that
informally with individual people, but there is no paper trail, little
of it seems to be written down anywhere, and it seems to be very easy
for different people to have different understandings of what's going
on and what the current status of things is and what the future
expectations are. I just went through the last two months of meeting
logs for FESCo -
https://meetbot-raw.fedoraproject.org/teams/fesco/ - and the Council -
https://meetbot-raw.fedoraproject.org/teams/council/ - and unless I'm
missing something, the string 'coreos' doesn't appear one time and the
string 'iot' appears only in the word "Patriots" in a discussion of the
NFL playoffs. This doesn't seem like how things ought to be.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux