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
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
NEED some HELP on getting dependency info among fedora rpms
by Fu Wei
Dear Fedora release engineers,
I am trying to working on a bootstrap on a new arch for Fedora, but I
would like to know the big picture of dependency info among a lot of
fedora rpms.
I know how to get this info of one rpm. But for 10s, 100s, or even
1000s rpms, Do we have existing scripts to help engineers to figure
out the dependency info among a lot of them?
Maybe there are some existing scripts we can use, or please provide
some advice or suggestion??
Great thanks!
--
Best regards,
Fu Wei
Senior Software Engineer
Red Hat Software (Beijing) Co.,Ltd.
Ph: +86 18102768846 (mobile)
IRC: fuwei
email: wefu(a)redhat.com
Level 9, North Tower C,Raycom Infotech Park,
No.2 Ke Xue Yuan Nanlu, Zhongguancun,
Haidian District, Beijing,China
4 years, 1 month
Re: URGENT: users prompted to upgrade to F32
by Adam Williamson
On Sat, 2020-02-22 at 12:42 -0800, Kevin Fenzi wrote:
> On Tue, Feb 18, 2020 at 09:33:42PM -0700, Ken Dreyer wrote:
> > On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson
> > <adamwill(a)fedoraproject.org> wrote:
> >
> > > Since this is an API endpoint of a real system which needs to be
> > > updated correctly when the release events actually happen, it
> > > should
> > > have the benefits pkgdb used to be (the information should be
> > > reliable
> > > and timely)
> >
> > Do we have stats on how many hits per second that current endpoint
> > receives?
>
> It looks like it gets less than 100k/day. So, one or less per second.
Are they evenly-spaced, though? I don't recall exactly how fancy the
GNOME Software code is, but it seems at least possible that these
check-ins aren't evenly spaced out but come in clumps...
BTW, I've ported fedfind from collections to Bodhi in 4.4.0, 4.4.1 is
in updates-testing now.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 1 month
Change in RelEng meeting time
by Mohan Boddu
Hello all,
We are planning on changing the RelEng meeting time as its not
feasible to some of the people anymore. Here's the framadata link [1]
with available days and times. Please fill it in and we will find the
best time that works for all of us.
Please let me know if you want to add any other time and I will look into it.
[1] https://framadate.org/fedorareleng
Thanks,
Mohan Boddu.
4 years, 1 month
Fedora Release Engineering Meeting Summary for 2020-02-19
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2020-02-19)
======================================
Meeting started by mboddu at 16:00:18 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-02-19/releng.2020...
.
Meeting summary
---------------
* init process (mboddu, 16:00:19)
* #9266 prune EOL content from OSTree repos (mboddu, 16:03:17)
* LINK: https://pagure.io/releng/issue/9266 (mboddu, 16:03:23)
* We will work on migration first and then pruning, nirik will start
working on migration tomorrow and then dustymabe will work on
pruning later (mboddu, 16:24:40)
* #7400 Rethink how we handle networking config with createImage (oz /
ImageFactory) (mboddu, 16:28:05)
* LINK: https://pagure.io/releng/issue/7400 (mboddu, 16:28:12)
* mboddu will create a upstream koji ticket and will check with mikem
(mboddu, 16:31:50)
* #7555 scratch permission to build livecd for users (mboddu, 16:34:27)
* LINK: https://pagure.io/releng/issue/7555 (mboddu, 16:34:34)
* Open Floor (mboddu, 16:55:24)
* LINK: https://pagure.io/fedora-project-schedule/issue/175
(bcotton, 17:03:24)
Meeting ended at 17:04:39 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (70)
* nirik (55)
* dustymabe (37)
* zodbot (14)
* bcotton (12)
* kalev (7)
* Southern_Gentlem (4)
* jednorozec (0)
* pbrobinson (0)
* pingou (0)
* ksinny (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 2 months