Revamping the Release Readiness meeting
by Ben Cotton
(Posting to many mailing lists for visibility. I apologize if you see
this more times than you'd like.)
You may have already seen my Community Blog post[1] about changing the
Release Readiness meeting process. The meeting has questionable value
in the current state, so I want to make it more useful. We'll do this
by having teams self-report readiness issues on a dedicated wiki
page[2] beginning now. This gives the community time to chip in and
help with areas that need help without waiting until days before the
release.
I invite teams to identify a representative to keep the wiki page up
to date. Update it as your status changes and I'll post help requests
in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC
meeting. The Release Readiness meeting will be shortened to one hour
and will review open concerns instead of polling for teams that may or
may not be there. We will use the logistics mailing list[5] to discuss
issues and make announcements, so I encourage representatives to join
this list.
[1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/
[2] https://fedoraproject.org/wiki/Release_Readiness
[3] https://communityblog.fedoraproject.org/category/program-management/
[4] https://apps.fedoraproject.org/calendar/council/#m9570
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 1 month
Fedora Release Engineering Meeting Summary for 2020-03-03
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2020-03-04)
======================================
Meeting started by mboddu at 16:00:58 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-03-03/releng.2020...
.
Meeting summary
---------------
* init process (mboddu, 16:00:59)
* New Schedule (mboddu, 16:02:46)
* We will change the meeting time to 11:00 AM EST every Tuesday
(mboddu, 16:06:43)
* quay.io access denied while uploading containers (mboddu, 16:11:20)
* We will try to debug the 503 error on registry.fp.o later today and
probably move it to cloudfront (mboddu, 16:26:16)
* #9266 prune EOL content from OSTree repos (mboddu, 16:29:01)
* LINK: https://pagure.io/releng/issue/9266 (mboddu, 16:29:06)
* #9169 Block unretirement commits (mboddu, 16:33:13)
* LINK: https://pagure.io/releng/issue/9169 (mboddu, 16:33:23)
* #9246 Please block `fedora-cisco-openh264` from pungi composes
(mboddu, 16:42:38)
* LINK: https://pagure.io/releng/issue/9246 (mboddu, 16:42:44)
* As a precaution, we will filter out the packages in pungi configs
and test it in rawhide compose by disabling sync. (mboddu,
16:46:32)
* Open Floor (mboddu, 16:51:47)
Meeting ended at 17:00:31 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (92)
* nirik (50)
* cverna (22)
* decaren (8)
* smooge (7)
* zodbot (7)
* puiterwijk (5)
* sharkcz (2)
* jednorozec (0)
* pbrobinson (0)
* dustymabe (0)
* pingou (0)
* ksinny (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 1 month
Re: a special Fedora spin
by Ben Cotton
Hi Vojtech,
I don't have an answer for your questions, so I have copied the
Release Engineering team who can give you the answers you need. I love
this spin idea, and am happy to help in whatever way I can.
Thanks,
BC
On Tue, Feb 4, 2020 at 11:59 AM Vojtech Polasek <vpolasek(a)redhat.com> wrote:
>
> Hello Ben,
>
> my name is Vojta and I am a blind software engineer working for RH in
> Brno, Czech Republic. I am working in platform security, but this is not
> that important for this mail.
>
> Me and several other friends from RH are working on a special Linux
> distribution for blind and visually impaired users. This distribution is
> currently based on Fedora. We would like to make a spin from it. But I
> have a special question, see below.
>
> I know that if I apply for a spin, the lab infrastructure can create ISO
> live images from kickstarts. That is nice. But...
>
> While demonstrating our distro to potential users, we chose a bit
> different way than others. Instead of live images shipped on USB drives,
> we chose to create a full installation of the system and place it on the
> USB drive. This has several benefits compared to live images:
>
> - changes made by users are persistent and not limited to 4 Gb
>
> - it is possible to partition the USB drive and create an additional
> partition formatted as Exfat for transfering data between Linux and
> non-Linux world
>
> - users can come to whatever computer and boot the system with their
> personal configuration, data, software...
>
> - users can have almost the same experience as if the system was
> installed on their primary hard drive
>
> It can have its drawbacks but we used this approach already two times
> while presenting our "spin" on special workshops and we think it worked
> very well.
>
> I am not against live images and if we create a Fedora spin, we will
> definitely offer them as well. But I believe the described alternative
> approach has its benefits-
>
> The whole process is described here:
>
> https://github.com/vojtapolasek/Fegora
>
> Currently we use a VM to perform an automated kickstart installation and
> then we transfer the raw image on an USB drive.
>
> My question now is: could the infrastructure used for production of
> Fedora spins be used to create not only live images but also our custom
> raw disk images? If not, could we at least use those resources to store
> such images?
>
> Feel free to ask if you need further clarifications etc.
>
> Best regards,
>
> Vojta
>
>
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 1 month
