I'd like to announce a new project of the QA team and an extension of the
BlockerBugs App . The blocker and freeze exception proposals can now not
only be discussed during regular blocker review meetings , but also at
any time through discussion tickets hosted on Pagure . So even if you
don't have time to participate in the meeting, you can still participate
and vote in those discussion tickets.
This will be mostly interesting to people who participated in blocker
review meetings in the past, but we hope we can attract new participants
this way. It is also very useful for package maintainers and developers,
because they can now easily provide feedback regarding a proposed blocker
or a freeze exception without attending a meeting at a particular time or
diluting a technical discussion in Bugzilla.
To participate, open the BlockerBugs App for a particular milestone (e.g.
F33 Beta ) and you'll see "Vote!" and "Discuss" links for
proposed/accepted blockers and freeze exceptions. Follow the links to see
tickets where you can express your opinion (which should ideally reflect
our release criteria ). You can vote according to the guide present at
, please read it carefully. A bot is following each ticket, updating the
voting summary, and accepting certain commands. Watching the Pagure repo
 also gives you the option to get notified about every new proposed
We've been using these discussions for a week or two now (I apologize for a
late announcement) and so far our existing practice seems to be to vote for
proposals throughout the week using these discussion tickets, close those
which we can easily get enough votes and agree on, and discuss the
remainder during the next blocker review meeting. So the regular blocker
review meeting hasn't been replaced, but we use the discussion tickets to
cut down on the meeting length. We're still trying to figure out the best
approach to take here, so nothing is set in stone. The voting functionality
itself is also still in development, we'll try to provide new features and
improve the experience based on your feedback.
I'll be happy to answer questions, if there are any.
PS: Development credits go to Lukas Brabec, Frantisek Zatloukal, Tim Flink,
Josef Skladanka and Adam Williamson.
Good Morning folks,
As you likely remember, a little while ago now, was announced the decision to
move dist-git to a gitlab instance. This decision was the results of different
factors which included a wish for Red Hat to have a consistent tooling and
experience across the different distribution it works on or with, meaning:
RHEL, CentOS-Stream, CentOS Linux and Fedora.
Since then, a number of technical requirements needed to use gitlab in Fedora,
were gathered and a ticket was opened at gitlab to track them  but up until
now the progress on the Fedora side has been fairly slow. This is mostly due to
the feedback from Fedora that followed this decision, leading to a focus on the
first two distributions in the list above.
However, in order to progress the evaluation of gitlab, we have organized an
"Ask Me Anything" (AMA) session with the gitlab folks on Thursday September 10th
2020, at 13:30 UTC on #fedora-meeting-1 on irc.freenode.net.
The idea is to have an open floor for anyone in the community to discuss with
GitLab the technical merits that GitLab has, as well as the requirements we, the
Fedora community, have.
In order for this session to be productive, we believe that it may be wise to
start gathering questions to GitLab early on, so they can also look into them
and prepare their answers (I'm sure we all prefer to have actual answers rather
than: "hm, I don't know, let me check and I'll get back to you on this"). Of
course, we will still be able to ask question at the last minute or even during
Gathering them as early as possible is just a way for GitLab to see what
interests us, who may be the right persons to attend this session and overall to
make this hour as productive as possible.
So there are two ways for you to submit your questions to the GitLab folks on a
potential deployment of GitLab as a front-end to our dist-git (ie:
- A public hackmd document:
Underneath each questions you will also be able to vote (simply add a ``+1`` to
the ``Votes:`` line), the most popular questions will be asked first.
Since this document is public, please be mindful of what previous
- A discussion on forum.gitlab.com at:
The questions that we will not have time for, or cant be answered during the
session, will be answered afterward. The AMA minutes will be sent in the CPE
weekly mail, the hackmd will be updated and and summary published on
Looking forward to the discussion,
Community Platform Engineering Team
Red Hat EMEA
Good Morning Everyone,
I wanted to share with you some information regarding the current
state and future of Communishift. The infrastructure team presented on
this project back in 2019 during Nest  , and since then, we have
deployed it, started using it and had to shut it down for
As a number of people have noted, it has not come back up yet, and
during Nest this year, we had hinted that communishift is not going to
come back alive looking
the same as when we shut it down, and that is unfortunately true.
The idea for communishift was to give to anyone in the community a place where
they could run any application they wish to provide to the community.
This was a proper place where Joe and Jane could offer the service foo to the
foo SIG without engaging the infrastructure's team responsibility to keep the
service up and running. The infrastructure team would have been able to say:
"well the openshift cluster is running, so if the app isn't, talk to the
application maintainer, there is nothing we can do about it".
Basically, it gave a place where we could experiment with new apps
without adding too
much work to the infrastructure team.
However, the General Data Protection Regulation (GDPR)  and the California
Consumer Privacy Act (CCPA)  basically makes the Fedora Infrastructure team
(and thus Red Hat) responsible for the content hosted by any services running in
our infrastructure. In other words, the Fedora Infrastructure team would be
responsible to answer all GDPR/CCPA related requests and requirements for any
and all services running in communishift (services that the team has 0 knowledge
about, that's the whole goal of communishift).
For these reasons communishift is not going to come back to life in the same way
it was shut down for the colo move.
We have not given up on the original idea though (ie: providing a place where
community members can deploy applications without adding work on the
infrastructure team), however, as with anything involving legal, this is going
to be a slow process. We will share any information as soon as we are able.
We're sorry for the inconvenience this causes, we really would like the
situation to be different but we also appreciate these regulations for what they
are (protecting our personal information) so we want to respect them.
Hoping this clarifies the situation around communishift a bit.
Aoife, Kevin & Pingou
- On behalf of the Fedora Infrastructure team
Community Platform Engineering Team
Red Hat EMEA