CPE Weekly: 2020-04-04

[Aoife Moloney]

# CPE Weekly 2020-04-04
---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-03-06

Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Check out our teams
info here https://docs.fedoraproject.org/en-US/cpe/


## GitForge Updates
Idea for note:
*There has been a lot of discussion this week on the devel and infra
lists about the decision to move to GitLab in the near future.
Firstly, let us apologize again to the communities for our drop in
communication between the requirement collecting phase and the
decision making phase. As we have said before, it was in no way, shape
or form an intentional lapse of communications. However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.
We do want to let you know that we deeply appreciate the requirements
you have given us and would like to ask you to continue engaging with
us while we are moving through our next steps with GitLab.
While the discussions on the lists are deeply emotional, they are
still incredibly valuable to us to truly comprehend the importance of
our next steps in ensuring we make the right choices in the coming
months.
Now more than ever, your guidance is needed to make sure we achieve
the best possible result for you and our team from this decision.
CPE management and I, our team's product owner, are also actively
engaging with the Fedora Council and soon the CentOS Board to make
sure that ALL of the developments and progress between us and GitLab
are publicly available.
We have a long way to go in this process and your feedback on our
progress will be vital to make sure we remain on course.
We hope in time you can understand our decision was made in good
intent for the betterment of both our team and the communities we
serve, and we hope to still be able to rely on you all as peers and
friends for feedback and guidance during this journey.*



## Fedora Updates
* Final Freeze starts 7th April 2020 @ 1400 UTC
* Pagure 5.9.1 release pushed to both staging and pagure.io
* the-new-hotness configuration was updated
https://pagure.io/fedora-infrastructure/issue/8783
* Michal Konečný has been working on mapping the fedora infrastructure
applications, his project, (which sounds really cool and useful!) can
be found here https://github.com/Zlopez/fedora-infra-map


### Data Centre Move
* Please note Communishift will be down from 13th April - 8th May to
facilitate the first shipment wave of our datacenter
* We are also still on track to switch to a reduced Fedora offering
from 25th May until est. 1st July\*.
* For a list of services we are planning to have available during this
window, please see mail thread in archive
https://lists.fedoraproject.org/archives/list/[e-mail]...
* We will not have staging available so we will not have capacity to
review or deploy new or upgraded features and applications during this
time.
* As always, please view our public schedule here for more a more
detailed overview
https://hackmd.io/@fedorainfra2020/rJpsA4FLL#First-draft-of-schedule-for-...
* We found a password, we do not know whose it is, but we have turned
it into the lost and found.


### AAA Replacement
* First development phase complete & the team worked through 57 tickets in total
* The codebase was sent to our team first for demo and we will be
using feedback to develop the portal further
* During phase two we would like to change some codebases in existing
apps, and write documentation on how to upgrade applications to
redirect to the new API
* We would like to roll this request for feedback out to some
community maintainers during this phase too for another iteration on
the service and documentation
* Our work is publicly tracked here
https://github.com/orgs/fedora-infra/projects/6 so please stop by and
check out the progress we are making, and what we are looking at
working on next



### CI/CD

* Monitor-gating is still running in production and giving us some
data about the health of the packager workflow:
    * For example, these are the statistics between Monday and Wednesday:
39 messages retrieved
prod.monitor-gating.multi-build.end.failed  --  7
prod.monitor-gating.multi-build.end.succeeded  --  2
prod.monitor-gating.multi-build.start  --  10
prod.monitor-gating.single-build.end.failed  --  3
prod.monitor-gating.single-build.end.succeeded  --  7
prod.monitor-gating.single-build.start  --  10
* rpmautospec 0.0.1 through 0.0.10 have been released and deployed in staging
    * We got two builds to go through fine, from the same commit,
getting two different NEVR and an auto-generated changelog
    * However, for this to happen, we had to tweak a couple of things
on the builder which is not really ideal/acceptable, so we moved a
part of the processing inside the chroot where the SRPM will be built,
which solved the main issues we faced
    * To be done: Make tagging (latest) existing builds a separate
operation executed outside the build root, to avoid having to talk to
Koji inside it.
    * In other words: Stay put, we're getting there!



### Sustaining Team
* Mbbox
    * The team have made some progress on koji-builder CRD
* The team are also working on Bodhi 5.3 with few improvements and bug
fixes from 5.2.
* The team had a reboot and Update cycle this week.
* The team are also discussing ideas around a releng bot to help
process the tickets that require manual interventions.
* They also add more updates to compose-tracker
* And started playing with odcs on new
odcs-backend-releng01.phx2.fedoraproject.org



## CentOS Updates

### CentOS
* CentOS CI is stable with 0 downtime!
* RHEL 7.8 released this week too!


### CentOS Stream
* qt5, go-toolest (module), container tools (module) are updated to
their 8.2 versions
* We are also looking at easier automation of koji tags



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great weekend!

Aoife


Source: https://hackmd.io/gSci385uRoeNVEuoNUS1pg?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford

[Randy Barlow]

On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  However we do
>  recognize that it was still nonetheless a decision that was not made
>  in public, and for that we can only now offer our apologies for this
>  mistake and learn a hard lesson from it. 
It's simply not true that this is the only thing that can be done. You 
can hold off on making a decision, and follow an open process instead.

>  We do want to let you know that we deeply appreciate the
> requirements
>  you have given us and would like to ask you to continue engaging with
>  us while we are moving through our next steps with GitLab. 
What would be the goal if the community were to continue to engage with 
CPE management when it has demonstrated that it does not meaningfully 
engage with the community?

[Chris Murphy]

On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow
<bowlofeggs(a)fedoraproject.org&gt; wrote:
>  On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > However we do
>  > recognize that it was still nonetheless a decision that was not made
>  > in public, and for that we can only now offer our apologies for this
>  > mistake and learn a hard lesson from it.
>
>  It's simply not true that this is the only thing that can be done. You
>  can hold off on making a decision, and follow an open process instead.
>
>  > We do want to let you know that we deeply appreciate the requirements
>  > you have given us and would like to ask you to continue engaging with
>  > us while we are moving through our next steps with GitLab.
>
>  What would be the goal if the community were to continue to engage with
>  CPE management when it has demonstrated that it does not meaningfully
>  engage with the community? 
I agree. Treating this as a fait accompli is not a good idea.

There's been a trust reducing event. Repairing the damage should
happen before further actions requiring trust are taken.

Flaws have been discovered in the process used to arrive at the
decision, and therefore it's not clear whether the decision is valid.
The mistake has been admitted, and treating it as moot suggests in
fact nothing has been learned from the mistake.


-- 
Chris Murphy

[clime]

On Sat, 4 Apr 2020 at 23:56, Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; wrote:
>  >
>  > On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > > However we do
>  > > recognize that it was still nonetheless a decision that was not made
>  > > in public, and for that we can only now offer our apologies for this
>  > > mistake and learn a hard lesson from it.
>  >
>  > It's simply not true that this is the only thing that can be done. You
>  > can hold off on making a decision, and follow an open process instead.
>  >
>  > > We do want to let you know that we deeply appreciate the requirements
>  > > you have given us and would like to ask you to continue engaging with
>  > > us while we are moving through our next steps with GitLab.
>  >
>  > What would be the goal if the community were to continue to engage with
>  > CPE management when it has demonstrated that it does not meaningfully
>  > engage with the community?
>
>  I agree. Treating this as a fait accompli is not a good idea.
>
>  There's been a trust reducing event. Repairing the damage should
>  happen before further actions requiring trust are taken.
>
>  Flaws have been discovered in the process used to arrive at the
>  decision, and therefore it's not clear whether the decision is valid.
>  The mistake has been admitted, and treating it as moot suggests in
>  fact nothing has been learned from the mistake. 
I agree with this as well.

clime

>
>
> --
> Chris Murphy
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Leigh Griffin]

On Sat, Apr 4, 2020 at 10:56 PM Chris Murphy <lists(a)colorremedies.com&gt;
wrote:

>  On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; wrote:
>  >
>  > On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > > However we do
>  > > recognize that it was still nonetheless a decision that was not made
>  > > in public, and for that we can only now offer our apologies for this
>  > > mistake and learn a hard lesson from it.
>  >
>  > It's simply not true that this is the only thing that can be done. You
>  > can hold off on making a decision, and follow an open process instead.
>  >
>  > > We do want to let you know that we deeply appreciate the requirements
>  > > you have given us and would like to ask you to continue engaging with
>  > > us while we are moving through our next steps with GitLab.
>  >
>  > What would be the goal if the community were to continue to engage with
>  > CPE management when it has demonstrated that it does not meaningfully
>  > engage with the community?
>
>  I agree. Treating this as a fait accompli is not a good idea.
>  
Over a year ago it was decided that Pagure did not meet our mission
statement. The exercise we undertook for all our stakeholders (Fedora is
one) reaffirmed that CPE will not be in a position to support Pagure going
forward outside of pagure.io. This is the next step in that process and the
actual specifics of how that looks on Gitlab is not decided yet and we are
engaging to figure that out with the Council in tandem.

>  There's been a trust reducing event. Repairing the damage should
>  happen before further actions requiring trust are taken.
>  
I'm happy to have us repair the damage and work towards building an open
and trustful relationship and this mail by Aoife is a good first step in
that in my opinion.

>  Flaws have been discovered in the process used to arrive at the
>  decision, and therefore it's not clear whether the decision is valid.
>  
Our choice of Forge that CPE will support is valid from the requirements we
received

The mistake has been admitted, and treating it as moot suggests in
>  fact nothing has been learned from the mistake.
>
>
>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Charalampos Stratakis]

----- Original Message -----
>  From: "Randy Barlow" <bowlofeggs(a)fedoraproject.org&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Saturday, April 4, 2020 10:35:21 PM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > However we do
>  > recognize that it was still nonetheless a decision that was not made
>  > in public, and for that we can only now offer our apologies for this
>  > mistake and learn a hard lesson from it.
>  
>  It's simply not true that this is the only thing that can be done. You
>  can hold off on making a decision, and follow an open process instead.
>  
>  > We do want to let you know that we deeply appreciate the requirements
>  > you have given us and would like to ask you to continue engaging with
>  > us while we are moving through our next steps with GitLab.
>  
>  What would be the goal if the community were to continue to engage with
>  CPE management when it has demonstrated that it does not meaningfully
>  engage with the community?
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
Indeed. I see no reason at all in engaging in any sort of community feedback at this
point.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat

[Leigh Griffin]

On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow <bowlofeggs(a)fedoraproject.org&gt;
wrote:

>  On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > However we do
>  > recognize that it was still nonetheless a decision that was not made
>  > in public, and for that we can only now offer our apologies for this
>  > mistake and learn a hard lesson from it.
>
>  It's simply not true that this is the only thing that can be done. You
>  can hold off on making a decision, and follow an open process instead.
>  
We are engaged with the Fedora Council on the next steps here for the
adoption of Gitlab / the retirement of Pagure from the CPE remit. That much
of the decision has been made, the actual specifics are what we are
engaging on to make sure that the Fedora needs are satisfied as we move
forward.

>  > We do want to let you know that we deeply appreciate the requirements
>  > you have given us and would like to ask you to continue engaging with
>  > us while we are moving through our next steps with GitLab.
>
>  What would be the goal if the community were to continue to engage with
>  CPE management when it has demonstrated that it does not meaningfully
>  engage with the community?
>  
Your engagement influences how this will look in the future, we have enough
gathered to ensure that is the case but given the breadth and depth of
Fedora, we do wish for people to engage.


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Dominik 'Rathann' Mierzejewski]

On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote:
>  On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow
> <bowlofeggs(a)fedoraproject.org&gt;
>  wrote:
>  
>  > On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > > However we do
>  > > recognize that it was still nonetheless a decision that was not made
>  > > in public, and for that we can only now offer our apologies for this
>  > > mistake and learn a hard lesson from it.
>  >
>  > It's simply not true that this is the only thing that can be done. You
>  > can hold off on making a decision, and follow an open process instead.
>  
>  We are engaged with the Fedora Council on the next steps here for the
>  adoption of Gitlab / the retirement of Pagure from the CPE remit. That much
>  of the decision has been made, the actual specifics are what we are
>  engaging on to make sure that the Fedora needs are satisfied as we move
>  forward. 
The majority here is telling you to hold off execution of that
"decision" and revisit it, but you're ignoring those voices entirely and
offering useless "apologies" instead. You cannot pretend to be part of a
community if you just ignore its other members and do your own thing.

>  > > We do want to let you know that we deeply appreciate the
> requirements
>  > > you have given us and would like to ask you to continue engaging with
>  > > us while we are moving through our next steps with GitLab.
>  >
>  > What would be the goal if the community were to continue to engage with
>  > CPE management when it has demonstrated that it does not meaningfully
>  > engage with the community?
>  
>  Your engagement influences how this will look in the future, we have enough
>  gathered to ensure that is the case but given the breadth and depth of
>  Fedora, we do wish for people to engage. 
You cannot wish for meaningful engagement in the future if you don't fix
your past mistakes and reverse bad decisions.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Alex Scheel]

----- Original Message -----
>  From: "Dominik 'Rathann' Mierzejewski"
> <dominik(a)greysector.net&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Monday, April 6, 2020 7:09:38 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote:
>  > On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow <bowlofeggs(a)fedoraproject.org&gt;
>  > wrote:
>  > 
>  > > On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > > > However we do
>  > > > recognize that it was still nonetheless a decision that was not made
>  > > > in public, and for that we can only now offer our apologies for this
>  > > > mistake and learn a hard lesson from it.
>  > >
>  > > It's simply not true that this is the only thing that can be done. You
>  > > can hold off on making a decision, and follow an open process instead.
>  > 
>  > We are engaged with the Fedora Council on the next steps here for the
>  > adoption of Gitlab / the retirement of Pagure from the CPE remit. That much
>  > of the decision has been made, the actual specifics are what we are
>  > engaging on to make sure that the Fedora needs are satisfied as we move
>  > forward.
>  
>  The majority here is telling you to hold off execution of that
>  "decision" and revisit it, but you're ignoring those voices entirely and
>  offering useless "apologies" instead. You cannot pretend to be part of a
>  community if you just ignore its other members and do your own thing. 
That part isn't actually clear to me. There's certainly a vocal portion
against using GitLab, but is that sufficient to determine it is the
majority of the Fedora packager community? I at least felt tired of
arguing and decided to mostly quit arguing versus continuing to participate
in this thread.

It'd be interesting to see if the FESCo election system could be
repurposed to get a sense of all packagers' opinions, rather than
make assumptions on how the community as a whole feels based on a few
vocal members and their participation in the mailing lists.


- Alex

[Miro Hrončok]

On 06. 04. 20 14:19, Alex Scheel wrote:
>  That part isn't actually clear to me. There's certainly a
> vocal portion
>  against using GitLab 
I think it's hard to see who's vocal against GitLab and who just wants a truly 
open decision process for this.

I've heard people who would love to get GitLab, but who are genuinely sad about 
how CPE management handled this.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Alex Scheel]

----- Original Message -----
>  From: "Miro Hrončok" <mhroncok(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Monday, April 6, 2020 8:28:15 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  On 06. 04. 20 14:19, Alex Scheel wrote:
>  > That part isn't actually clear to me. There's certainly a vocal portion
>  > against using GitLab
>  
>  I think it's hard to see who's vocal against GitLab and who just wants a
>  truly
>  open decision process for this.
>  
>  I've heard people who would love to get GitLab, but who are genuinely sad
>  about how CPE management handled this. 
Sure, can we have two positions in this voting system?

 1. I want GitLab,
 2. I want Pagure,
 3. I want something not listed here,
 4. I don't particularly care.

--- 

 a. I am OK with how this was handled,
 b. I would prefer an open process,
 c. I don't care how it was handled.


IIRC, FESCo voting is a ranked voting scheme, so we'd also get a sense of
preference for each of these items.


It'd need some disclaimer that this is meant as a survey and not as an
actual decision mechanism and that the results wouldn't necessarily
influence the outcome. But as a way of reading the temperature of the
entire room and not guessing based on mailing list participation, it
might be better.


My 2c,

- Alex

>  
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Till Maas]

On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
>  ----- Original Message -----
>  > From: "Miro Hrončok" <mhroncok(a)redhat.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Monday, April 6, 2020 8:28:15 AM
>  > Subject: Re: CPE Weekly: 2020-04-04
>  > 
>  > On 06. 04. 20 14:19, Alex Scheel wrote:
>  > > That part isn't actually clear to me. There's certainly a vocal
> portion
>  > > against using GitLab
>  > 
>  > I think it's hard to see who's vocal against GitLab and who just wants a
>  > truly
>  > open decision process for this.
>  > 
>  > I've heard people who would love to get GitLab, but who are genuinely sad
>  > about how CPE management handled this.
>  
>  Sure, can we have two positions in this voting system?
>  
>   1. I want GitLab,
>   2. I want Pagure,
>   3. I want something not listed here,
>   4. I don't particularly care. 
What do you want to do with this information? Also I do not think it is
a good idea to micro-manager CPE into a specific solution. IMHO it is
more important to get the dist-git features that Fedora requested and
probably also issue trackers for Fedora groups (for example Council,
FESCo, ...) currently implemented in
pagure.io), GIT repos with a git forge for Fedora (for example for docs,
infra, releng). And it would be great to also ensure that Fedora
contributors/Fedora Infra/CPE can contribute to these solutions to
ensure that Fedora specific requirements can be met.

If it is easier to customize Gitlab to meet Fedora's dist-git
requirements than to customize pagure, then it would be good for CPE
to do this even if more people would like to prefer pagure. If it is the
other way, then it could still make sense to use Gitlab for tasks used
by pagure.io to benefit from better Gitforge features, there, but keep
pagure for dist-git.

Also, I do not have any idea how easy it is to get changes into Gitlab,
so this is also something that needs to be taken into consideration.
I find it somewhat troublesome that these questions are not answered,
especially since the migration from pkgdb to pagure was very painful and
is not yet completed.

Kind regards
Till

[Alex Scheel]

----- Original Message -----
>  From: "Till Maas" <opensource(a)till.name&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Monday, April 6, 2020 1:39:49 PM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
>  > ----- Original Message -----
>  > > From: "Miro Hrončok" <mhroncok(a)redhat.com&gt;
>  > > To: devel(a)lists.fedoraproject.org
>  > > Sent: Monday, April 6, 2020 8:28:15 AM
>  > > Subject: Re: CPE Weekly: 2020-04-04
>  > > 
>  > > On 06. 04. 20 14:19, Alex Scheel wrote:
>  > > > That part isn't actually clear to me. There's certainly a vocal
> portion
>  > > > against using GitLab
>  > > 
>  > > I think it's hard to see who's vocal against GitLab and who just wants
> a
>  > > truly
>  > > open decision process for this.
>  > > 
>  > > I've heard people who would love to get GitLab, but who are genuinely sad
>  > > about how CPE management handled this.
>  > 
>  > Sure, can we have two positions in this voting system?
>  > 
>  >  1. I want GitLab,
>  >  2. I want Pagure,
>  >  3. I want something not listed here,
>  >  4. I don't particularly care.
>  
>  What do you want to do with this information?  
I'm not in CPE.

I'm curious what the _community's_ position is. There's a small portion of
people responding to this thread. We can make assumptions about what the
Fedora community thinks (and certainly we know what individuals of it think),
but until we have data, do we really know what the majority opinion is?

I value data over a few loud voices. :)

>  Also I do not think it is
>  a good idea to micro-manager CPE into a specific solution. IMHO it is
>  more important to get the dist-git features that Fedora requested and
>  probably also issue trackers for Fedora groups (for example Council,
>  FESCo, ...) currently implemented in
>  pagure.io), GIT repos with a git forge for Fedora (for example for docs,
>  infra, releng). And it would be great to also ensure that Fedora
>  contributors/Fedora Infra/CPE can contribute to these solutions to
>  ensure that Fedora specific requirements can be met. 
As I said elsewhere, I don't want to use this for a decision. I just
want to see what more than the ~60 people responding here and in the
other thread actually think about this issue.

I do agree, if this were a vote, it would boxes CPE in. But before the
Fedora community can engage with CPE, shouldn't the leadership (and those
of us arguing on the thread) understand what the rest of the Fedora
community thinks, such that we all can represent something cohesively to
CPE?

IMO, that was the step lacking from this process on the Fedora side.

>  If it is easier to customize Gitlab to meet Fedora's dist-git
>  requirements than to customize pagure, then it would be good for CPE
>  to do this even if more people would like to prefer pagure. If it is the
>  other way, then it could still make sense to use Gitlab for tasks used
>  by pagure.io to benefit from better Gitforge features, there, but keep
>  pagure for dist-git.
>
>  Also, I do not have any idea how easy it is to get changes into Gitlab,
>  so this is also something that needs to be taken into consideration.
>  I find it somewhat troublesome that these questions are not answered,
>  especially since the migration from pkgdb to pagure was very painful and
>  is not yet completed. 
Thanks for your opinion, your response has been recorded in this informal
poll. :)
 
>  Kind regards
>  Till
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Randy Barlow]

On 4/6/20 8:28 AM, Miro Hrončok wrote:
>  I think it's hard to see who's vocal against GitLab and who
> just wants a 
>  truly open decision process for this.
>  
>  I've heard people who would love to get GitLab, but who are genuinely 
>  sad about how CPE management handled this. 
This. I personally actually like GitLab. I know that many people here 
don't, and I respect that.

I feel particularly awkward, because though I am in favor of GitLab, 
what has happened here is an affront to our open community, and that 
matters a lot more to me than which program we use.

[Nicolas Mailhot]

Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>  
>  It'd be interesting to see if the FESCo election system could be
>  repurposed to get a sense of all packagers' opinions, rather than
>  make assumptions on how the community as a whole feels based on a few
>  vocal members and their participation in the mailing lists. 

Fedora guidelines ask Fedora packagers to subscribe to the devel list,
so it’s the official place to reach Fedora packagers.

And practically, ignoring officialdom, yes there is a self selection
bias, every packager does not follow guidelines and the list. But, it
is a bias in favor of people who do stuff, and use the list to
coordinate, ie the portion of the packaging community you least want to
ignore, because they pull all the others.

-- 
Nicolas Mailhot

[Alex Scheel]

----- Original Message -----
>  From: "Nicolas Mailhot via devel"
> <devel(a)lists.fedoraproject.org&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  Sent: Monday, April 6, 2020 9:10:56 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>  > 
>  > It'd be interesting to see if the FESCo election system could be
>  > repurposed to get a sense of all packagers' opinions, rather than
>  > make assumptions on how the community as a whole feels based on a few
>  > vocal members and their participation in the mailing lists.
>  
>  
>  Fedora guidelines ask Fedora packagers to subscribe to the devel list,
>  so it’s the official place to reach Fedora packagers. 
That's not the point I was making.

Not everyone is inclined to loudly argue their positions on the mailing
list. There have only been 12 unique participants to this thread and 57
to the other thread.

That isn't indicative of the entire Fedora packager ecosystem. A lot of
people are staying silent.


I believe we need a different way to engage the rest of our packager
base.

- Alex

>  And practically, ignoring officialdom, yes there is a self selection
>  bias, every packager does not follow guidelines and the list. But, it
>  is a bias in favor of people who do stuff, and use the list to
>  coordinate, ie the portion of the packaging community you least want to
>  ignore, because they pull all the others.
>  
>  --
>  Nicolas Mailhot
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Ben Rosser]

On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel <ascheel(a)redhat.com&gt; wrote:
>  ----- Original Message -----
>  > From: "Nicolas Mailhot via devel" <devel(a)lists.fedoraproject.org&gt;
>  > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  > Sent: Monday, April 6, 2020 9:10:56 AM
>  > Subject: Re: CPE Weekly: 2020-04-04
>  >
>  > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>  > >
>  > > It'd be interesting to see if the FESCo election system could be
>  > > repurposed to get a sense of all packagers' opinions, rather than
>  > > make assumptions on how the community as a whole feels based on a few
>  > > vocal members and their participation in the mailing lists.
>  >
>  >
>  > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
>  > so it’s the official place to reach Fedora packagers.
>
>  That's not the point I was making.
>
>  Not everyone is inclined to loudly argue their positions on the mailing
>  list. There have only been 12 unique participants to this thread and 57
>  to the other thread.
>
>  That isn't indicative of the entire Fedora packager ecosystem. A lot of
>  people are staying silent.
>
>
>  I believe we need a different way to engage the rest of our packager
>  base. 
I'm a packager who has been staying silent, but I generally strongly
agree with the points that Adam, Miro, Neal, and others have been
making with a few caveats:

* I don't _really_ mind if we wind up using Gitlab over Pagure, but if
we do, I do feel pretty strongly that we should use Gitlab CE and
self-host it-- I don't think it would be right for Fedora to use an
externally hosted solution and I don't think we should use the
enterprise edition.

* I don't like how this process has been conducted, and I think that
official responses from CPE thus far haven't really made things
better-- if anything, the "we apologize, but this is the decision
we've made" attitude is making things worse.

* I fear that, once again, we haven't adequately understood the
consequences of replacing pagure and some of the features that were
recently-- finally!-- added to it in order to replace missing pkgdb2
functionality will again be lost for a long period of time... and
nothing I've read in any of these threads so far has helped reassure
me that's not the case.

Not saying you're wrong that it would be nice to have the ability to
poll a broader selection of packagers. But I'm not sure using the
FESCo voting system would really accomplish that either. How many
people actually vote in FESCo elections relative to the number of
active packagers? I'm sure you could argue that, depending on the
turnout, the results wouldn't be necessarily representative either.

Ben Rosser

[Gabriel L. Somlo]

On Mon, Apr 06, 2020 at 09:49:13 -0400, rosser.bjr(a)gmail.com wrote:
>  On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel <ascheel(a)redhat.com&gt;
> wrote:
>  > 
>  > [...]
>  >
>  > I believe we need a different way to engage the rest of our packager
>  > base.
>  
>  I'm a packager who has been staying silent, but I generally strongly
>  agree with the points that Adam, Miro, Neal, and others have been
>  making with a few caveats:
>  
>  * I don't _really_ mind if we wind up using Gitlab over Pagure, but if
>  we do, I do feel pretty strongly that we should use Gitlab CE and
>  self-host it-- I don't think it would be right for Fedora to use an
>  externally hosted solution and I don't think we should use the
>  enterprise edition.
>  
>  * I don't like how this process has been conducted, and I think that
>  official responses from CPE thus far haven't really made things
>  better-- if anything, the "we apologize, but this is the decision
>  we've made" attitude is making things worse.
>  
>  * I fear that, once again, we haven't adequately understood the
>  consequences of replacing pagure and some of the features that were
>  recently-- finally!-- added to it in order to replace missing pkgdb2
>  functionality will again be lost for a long period of time... and
>  nothing I've read in any of these threads so far has helped reassure
>  me that's not the case. 
+1 to everything Ben said (now that feedback from us "silent types"
has been explicitly solicited :)

Best Regards,
--Gabriel Somlo
 
> Not saying you're wrong that it would be nice to have the ability to
> poll a broader selection of packagers. But I'm not sure using the
> FESCo voting system would really accomplish that either. How many
> people actually vote in FESCo elections relative to the number of
> active packagers? I'm sure you could argue that, depending on the
> turnout, the results wouldn't be necessarily representative either.

[Alex Scheel]

----- Original Message -----
>  From: "Ben Rosser" <rosser.bjr(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Monday, April 6, 2020 9:49:13 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>   
Thanks for sharing your thoughts. :-)

>  Not saying you're wrong that it would be nice to have the ability
> to
>  poll a broader selection of packagers. But I'm not sure using the
>  FESCo voting system would really accomplish that either. How many
>  people actually vote in FESCo elections relative to the number of
>  active packagers? I'm sure you could argue that, depending on the
>  turnout, the results wouldn't be necessarily representative either. 
In the last FESCo election, 273 ballots were cast [0]. According to the
graph maintained by Matthew Miller [1], we have between 225 and 375
active maintainers in Fedora, depending on how you count.

That says that FESCo elections are ~5x more participated in than these
mailing list discussions, and are a much more representative sample of
all our (active?) packagers. I'm not sure if FESCo votes count as
packager activity in the above graphs; I'm guessing not.


My 2c.

- Alex

[0]: subj: "FESCo election results", sent 6/Dec/'19 by bcotton(a)redhat.com,
     to this mailing list.
[1]: https://mattdm.org/fedora/fedora-contributor-trends/active-contributors-b...

>  
>  Ben Rosser
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Nicolas Mailhot]

Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit :
>  
>  In the last FESCo election, 273 ballots were cast [0]. According to
>  the
>  graph maintained by Matthew Miller [1], we have between 225 and 375
>  active maintainers in Fedora, depending on how you count. 
That’s *weekly* activity. As in, the packager finished something, and
was active a specific week landing the result in Fedora. It does not
count all what happens outside Fedora infra before the result lands.

-- 
Nicolas Mailhot

[Alex Scheel]

----- Original Message -----
>  From: "Nicolas Mailhot via devel"
> <devel(a)lists.fedoraproject.org&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  Sent: Monday, April 6, 2020 10:57:40 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>  
>  Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit :
>  > 
>  > In the last FESCo election, 273 ballots were cast [0]. According to
>  > the
>  > graph maintained by Matthew Miller [1], we have between 225 and 375
>  > active maintainers in Fedora, depending on how you count.
>  
>  That’s *weekly* activity. As in, the packager finished something, and
>  was active a specific week landing the result in Fedora. It does not
>  count all what happens outside Fedora infra before the result lands. 
I'm not sure why what happens outside Fedora infra has anything to do
with the dist-git discussion. Are you suggesting that all contributors
to all Fedora upstream should weigh in on this discussion as well? I
mean, that'd be nice I suppose, but mostly this a discussion for people
who interact with dist-git frequently. 

I do recognize that perhaps a monthly contributor list might have higher
magnitude than 300. But there's still old bugs, new bugs, and random other
contributions that could count as activity besides pushing a Bodhi update.


My 2c.

- Alex

>  
>  --
>  Nicolas Mailhot
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Nicolas Mailhot]

Le lundi 06 avril 2020 à 11:42 -0400, Alex Scheel a écrit :
>  
>  I'm not sure why what happens outside Fedora infra has anything to do
>  with the dist-git discussion. Are you suggesting that all
>  contributors
>  to all Fedora upstream should weigh in on this discussion as well? I
>  mean, that'd be nice I suppose, but mostly this a discussion for
>  people who interact with dist-git frequently.  
This should be discussion for the people who make Fedora tick. You can
make Fedora every week, or every month, but is is also perfectly fine
to push things every six months before stable branching and only land
sporadic fixes in between.

-- 
Nicolas Mailhot

[Dan Čermák]

Ben Rosser <rosser.bjr(a)gmail.com&gt; writes:

>  On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel <ascheel(a)redhat.com&gt;
> wrote:
> >
> > ----- Original Message -----
> > > From: "Nicolas Mailhot via devel"
> <devel(a)lists.fedoraproject.org&gt;
> > > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
> > > Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
> > > Sent: Monday, April 6, 2020 9:10:56 AM
> > > Subject: Re: CPE Weekly: 2020-04-04
> > >
> > > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
> > > >
> > > > It'd be interesting to see if the FESCo election system could be
> > > > repurposed to get a sense of all packagers' opinions, rather than
> > > > make assumptions on how the community as a whole feels based on a few
> > > > vocal members and their participation in the mailing lists.
> > >
> > >
> > > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
> > > so it’s the official place to reach Fedora packagers.
> >
> > That's not the point I was making.
> >
> > Not everyone is inclined to loudly argue their positions on the mailing
> > list. There have only been 12 unique participants to this thread and 57
> > to the other thread.
> >
> > That isn't indicative of the entire Fedora packager ecosystem. A lot of
> > people are staying silent.
> >
> >
> > I believe we need a different way to engage the rest of our packager
> > base.
>
>  I'm a packager who has been staying silent, but I generally strongly
>  agree with the points that Adam, Miro, Neal, and others have been
>  making 
As a $nobody that has stayed silent so far, I'd second this: essentially
everything that I would have said, has already been said and ignored
over and over and over again. Honestly, I don't see a point in repeating
the same things again, just to get a polite "we're terribly sorry how we
handled this, but no, we've decided to stick with gitlab"

>  with a few caveats:
>
>  * I don't _really_ mind if we wind up using Gitlab over Pagure, but if
>  we do, I do feel pretty strongly that we should use Gitlab CE and
>  self-host it-- I don't think it would be right for Fedora to use an
>  externally hosted solution and I don't think we should use the
>  enterprise edition. 
I would very much prefer Pagure, mostly because it is one of the few
true FLOSS git forges and we're currently it's biggest user.

>  * I don't like how this process has been conducted, and I think that
>  official responses from CPE thus far haven't really made things
>  better-- if anything, the "we apologize, but this is the decision
>  we've made" attitude is making things worse. 
Exactly. All threads that have unraveled so far only make me
increasingly frustrated and let me feel more and more powerless: if even
established and respected community members cannot make the CPE
reconsider and go back to the drawing board, then what on earth can I
do? Why should I even try to make a positive impact in the Fedora
community, if the CPE doesn't even consider our core values? What will
be ditched next for a proprietary SaaS solution? (yes I am exaggerating
on purpose with the last one)

>  * I fear that, once again, we haven't adequately understood the
>  consequences of replacing pagure and some of the features that were
>  recently-- finally!-- added to it in order to replace missing pkgdb2
>  functionality will again be lost for a long period of time... and
>  nothing I've read in any of these threads so far has helped reassure
>  me that's not the case. 
Your fear has been confirmed multiple times by Leigh Griffin: there is
*no* plan or analysis yet how the currently required features of our
pagure dist-git can be implemented in gitlab and how much that will
cost (how that does not defeat the original purpose of this whole ordeal
is beyond me).

I honestly have nothing more to add to that, as imho the last paragraph
already tells us how this thing will end :-(


Dan

[Mark Wielaard]

Hi,

On Mon, 2020-04-06 at 09:49 -0400, Ben Rosser wrote:
>  > Not everyone is inclined to loudly argue their positions on the
>  > mailing
>  > list. There have only been 12 unique participants to this thread and 57
>  > to the other thread.
>  > 
>  > That isn't indicative of the entire Fedora packager ecosystem. A lot of
>  > people are staying silent.
>  > [...]
>  
>  I'm a packager who has been staying silent, but I generally strongly
>  agree with the points that Adam, Miro, Neal, and others have been
>  making with a few caveats: 
This is also why I am staying silent. I believe the points I would make
have already been made, and probably much better than I could have
formulated them. Including what Ben just said.

>  * I don't _really_ mind if we wind up using Gitlab over Pagure,
> but if
>  we do, I do feel pretty strongly that we should use Gitlab CE and
>  self-host it-- I don't think it would be right for Fedora to use an
>  externally hosted solution and I don't think we should use the
>  enterprise edition.
>  
>  * I don't like how this process has been conducted, and I think that
>  official responses from CPE thus far haven't really made things
>  better-- if anything, the "we apologize, but this is the decision
>  we've made" attitude is making things worse.
>  
>  * I fear that, once again, we haven't adequately understood the
>  consequences of replacing pagure and some of the features that were
>  recently-- finally!-- added to it in order to replace missing pkgdb2
>  functionality will again be lost for a long period of time... and
>  nothing I've read in any of these threads so far has helped reassure
>  me that's not the case. 
It seems to me that nobody is happy with the process that was followed.
Reading back it is clear that people feel that what they perceive as
the Fedora goals and mission were not taken into account. Or at least
not formulated correctly, or strongly enough, during this process. And
that the process wasn't transparent, because various steps were not
visible enough. So a large part of the community was surprised by the
decision and believe that their input wasn't heard or simply ignored.
Including the input of some of who will have to do part of the
(integration) work.

I am sure that wasn't what was intended. And that there were just a few
communication accidents that caused things to break down. But
recognizing that some mistakes were made and trying to correct them so
that a real community can be build up around these kind of decisions is
important.

Cheers,

Mark

[Solomon Peachy]

On Mon, Apr 06, 2020 at 09:35:58AM -0400, Alex Scheel wrote:
>  That isn't indicative of the entire Fedora packager ecosystem. A
> lot of
>  people are staying silent. 
Do you really want/expect 300 folks to chime in with "+1" replies?

Speaking for myself, Neal and Adam (and others) have already expressed 
pretty much everything I have to say, and then some.  But what the heck, 
here's two more cents.

I'm not terribly invested in what goes on under Fedora's skirts and the 
RH<->Fedora relationship, but it's clear that there have been multiple 
trust-destroying breakdowns of communication, resulting in a single 
stakeholder (ie CPE) effectively dictating a major change that directly 
violates Fedora's principles.  Let me quote the text of the first:

 "We are dedicated to Free Software and content"

 "Advancing software and content freedom is a central community goal, 
  which we accomplish through the software and content we promote. We 
  choose free alternatives to proprietary code and content and limit the 
  effects of proprietary or patent encumbered code on the Project."

 "Sometimes this goal prevents us from taking the easy way out by 
  including proprietary or patent encumbered software in Fedora. But by 
  concentrating on the free software and content we provide and promote, 
  the end result is that we are able to provide:

  " * releases that are predictable and 100% legally redistributable for 
      everyone;

  " * Innovation in free and open source software that can equal or exceed 
      closed source or proprietary solutions;"

  " * and, a completely free project that anyone can emulate or copy in 
      whole or in part for their own purposes."

To be blunt, moving core distro plumbing off of Free Software, onto to a 
proprietary system [1] violates nearly every sentence of that principle.

I might add that the process that led to this decision also violated the 
"Friends" principle:

  "Like any friends, we occasionally disagree on details, but we believe 
   in finding an acceptable consensus to serve the interests of advancing 
   free software. We believe in a strong partnership between Red Hat and 
   our enormous volunteer community, since they both provide essential 
   contributions that help the Fedora Project succeed."

A afterthought of a message of a far-reaching change wih followup 
responses of "the decision has been made, and is final.  We'll figure 
out the very-hand-wavy details and what work you will have to do [3] and 
get back to you sometime in the future" not an "acceptable concensus" or 
even much of a "partnership".

[1] As Neal put it, the final requirement list and the stated reasons 
    for the decision all but guarantee that only the proprietary Github 
    Ultimate product can meet them. [2] 

[2] Yes, GitLab CE is "open source" but it won't meet the CPE's or 
    Fedora's needs without a considerable amount of development, both in 
    the core feature set and (especially) the integration effort.  If 
    we're going to invest that huge of amount development man-hours, why 
    not spend it improving Free Software (you know, our stated mission) 
    instead of reintegrating the wheel?

[3] Given that multiple core requirements were left out of the decision 
    process, what confidence can we have that the full consequences of 
    this decision will be adequately captured, planned, and budgeted for?

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Daniel P. Berrangé]

On Mon, Apr 06, 2020 at 09:35:58AM -0400, Alex Scheel wrote:
>  ----- Original Message -----
>  > From: "Nicolas Mailhot via devel" <devel(a)lists.fedoraproject.org&gt;
>  > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  > Sent: Monday, April 6, 2020 9:10:56 AM
>  > Subject: Re: CPE Weekly: 2020-04-04
>  > 
>  > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>  > > 
>  > > It'd be interesting to see if the FESCo election system could be
>  > > repurposed to get a sense of all packagers' opinions, rather than
>  > > make assumptions on how the community as a whole feels based on a few
>  > > vocal members and their participation in the mailing lists.
>  > 
>  > 
>  > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
>  > so it’s the official place to reach Fedora packagers.
>  
>  That's not the point I was making.
>  
>  Not everyone is inclined to loudly argue their positions on the mailing
>  list. There have only been 12 unique participants to this thread and 57
>  to the other thread.
>  
>  That isn't indicative of the entire Fedora packager ecosystem. A lot of
>  people are staying silent. 
Watching the discussion in the other big thread, I feel it has become
rather too toxic & negative, going over & over the same points, verging
into personal insults, and repeatly beating people over the previous
communication or process failures. I struggle to see anything positive
coming from further contributors joining in that discussion thread,
which I expect is why so many choose to remain silent.

Going for a formal vote on this topic would not be a good step at this
point in time, as the issue is far too emotive & raw. A vote will serve
to crystalize division instead of healing it & we need to consider what
is viable, as voting for something that can't then be delivered is even
worse.

IMHO there needs to be a general cooling off period, followed by a fresh
look at what the realistic options available to Fedora are, given the
current decisions that have been made & the resources available to the
project[1]. We need to be positive & constructive if we're to make any
progress, and get out of the negative blame game we're in right now.

Regards,
Daniel

[1] I'm not saying that we must go ahead with the decision to replace
    Pagure with GitLab. Just that we need to carefully consider where
    to go from here, as any decision needs to be sustainable for the
    project in the long term.
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Alex Scheel]

----- Original Message -----
>  From: "Daniel P. Berrangé" <berrange(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  Sent: Monday, April 6, 2020 11:02:52 AM
>  Subject: Re: CPE Weekly: 2020-04-04
>   
>  Watching the discussion in the other big thread, I feel it has
> become
>  rather too toxic & negative, going over & over the same points, verging
>  into personal insults, and repeatly beating people over the previous
>  communication or process failures. I struggle to see anything positive
>  coming from further contributors joining in that discussion thread,
>  which I expect is why so many choose to remain silent. 
Agreed on the toxicity and negativity, but I still think it is important
to get a sense of everyone's thoughts, not just those of us who participate
in this thread.

>  Going for a formal vote on this topic would not be a good step at
> this
>  point in time, as the issue is far too emotive & raw. A vote will serve
>  to crystalize division instead of healing it & we need to consider what
>  is viable, as voting for something that can't then be delivered is even
>  worse. 
I wasn't suggesting a formal vote. I was suggesting a survey, using an
existing mechanism. We could also use Google forms (like Modularity did),
but that'd make the results less visible and some people don't like
Google. Also, the voting mechanism ties into FAS ID's and has restrictions
on who can participate (users with two different groups right?). It'd be
hard to enforce something similar with Google forms.

>  IMHO there needs to be a general cooling off period, followed by a
> fresh
>  look at what the realistic options available to Fedora are, given the
>  current decisions that have been made & the resources available to the
>  project[1]. We need to be positive & constructive if we're to make any
>  progress, and get out of the negative blame game we're in right now. 
I think we need to involve everyone who CPE works with in one forum,
otherwise we'll likely arrive at maintaining two separate projects,
one just for Fedora and one for CentOS and Red Hat. Perhaps that is
what is best though, who knows.

>  Regards,
>  Daniel
>  
>  [1] I'm not saying that we must go ahead with the decision to replace
>      Pagure with GitLab. Just that we need to carefully consider where
>      to go from here, as any decision needs to be sustainable for the
>      project in the long term.
>  --
>  |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange
>  |:|
>  |: https://libvirt.org         -o-            https://fstop138.berrange.com
>  |:|
>  |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange
>  |:|
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Gordon Messmer]

On 4/6/20 5:19 AM, Alex Scheel wrote:
>  It'd be interesting to see if the FESCo election system could be
>  repurposed to get a sense of all packagers' opinions, rather than
>  make assumptions on how the community as a whole feels based on a few
>  vocal members and their participation in the mailing lists. 

I tend to think that a survey would be less useful than a list of 
dist-git integrations that will need to be rebuilt in order to move that 
service and an estimate of man-hours required, vs a list of feature gap 
and estimated cost to close it.

[Leigh Griffin]

On Mon, Apr 6, 2020 at 12:11 PM Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net&gt; wrote:

>  On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote:
>  > On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow <
>  bowlofeggs(a)fedoraproject.org&gt;
>  > wrote:
>  >
>  > > On 4/4/20 3:02 PM, Aoife Moloney wrote:
>  > > > However we do
>  > > > recognize that it was still nonetheless a decision that was not made
>  > > > in public, and for that we can only now offer our apologies for this
>  > > > mistake and learn a hard lesson from it.
>  > >
>  > > It's simply not true that this is the only thing that can be done. You
>  > > can hold off on making a decision, and follow an open process instead.
>  >
>  > We are engaged with the Fedora Council on the next steps here for the
>  > adoption of Gitlab / the retirement of Pagure from the CPE remit. That
>  much
>  > of the decision has been made, the actual specifics are what we are
>  > engaging on to make sure that the Fedora needs are satisfied as we move
>  > forward.
>
>  The majority here is telling you to hold off execution of that
>  "decision" and revisit it, but you're ignoring those voices entirely and
>  offering useless "apologies" instead. You cannot pretend to be part of a
>  community if you just ignore its other members and do your own thing.
>  
I'm reaffirming that I hear the concerns and that my team are taking them
on board. I am also reaffirming that our engagement point is with the
Fedora Council, not at the individual level as the Council is responsible
for listening and collating those concerns and speaking on behalf of the
entire community. It is not for me to change how that process works so
please reach out to your Council reps and engage through that channel.


>  > > > We do want to let you know that we deeply appreciate the requirements
>  > > > you have given us and would like to ask you to continue engaging with
>  > > > us while we are moving through our next steps with GitLab.
>  > >
>  > > What would be the goal if the community were to continue to engage with
>  > > CPE management when it has demonstrated that it does not meaningfully
>  > > engage with the community?
>  >
>  > Your engagement influences how this will look in the future, we have
>  enough
>  > gathered to ensure that is the case but given the breadth and depth of
>  > Fedora, we do wish for people to engage.
>
>  You cannot wish for meaningful engagement in the future if you don't fix
>  your past mistakes and reverse bad decisions.
>  
I'm happy to fix mistakes, I think it's a wonderful learning opportunity
when One encounters a mistake and overcomes it down the line again. Bad
decision here is subjective, you have your view on it and I have mine, both
are entitled to it.

>  Regards,
>  Dominik
>  --
>  Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
>  There should be a science of discontent. People need hard times and
>  oppression to develop psychic muscles.
>          -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Miro Hrončok]

On 06. 04. 20 17:20, Leigh Griffin wrote:
>  
>  I'm reaffirming that I hear the concerns and that my team are taking them on 
>  board. I am also reaffirming that our engagement point is with the Fedora 
>  Council, not at the individual level as the Council is responsible for listening 
>  and collating those concerns and speaking on behalf of the entire community. 
This only makes it more clear that you are not interested in engaging with the 
community directly, but you are deferring that to the Council. This is not "the 
process", this is just a way to justify not engaging. What you say here is not 
very friendly.

>  It 
>  is not for me to change how that process works so please reach out to your 
>  Council reps and engage through that channel. 
Fedora has an established process for infra changes like this and you have 
chosen to bypass it entirely by talking directly to the Council. And now you say 
"this is how this process works" -- well, in fact it isn't.

https://docs.fedoraproject.org/en-US/program_management/changes_policy/

https://pagure.io/Fedora-Council/tickets/issue/292#comment-640101


-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Leigh Griffin]

On Mon, Apr 6, 2020 at 4:34 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 06. 04. 20 17:20, Leigh Griffin wrote:
>  >
>  > I'm reaffirming that I hear the concerns and that my team are taking
>  them on
>  > board. I am also reaffirming that our engagement point is with the
>  Fedora
>  > Council, not at the individual level as the Council is responsible for
>  listening
>  > and collating those concerns and speaking on behalf of the entire
>  community.
>
>  This only makes it more clear that you are not interested in engaging with
>  the
>  community directly, but you are deferring that to the Council. This is not
>  "the
>  process", this is just a way to justify not engaging. What you say here is
>  not
>  very friendly.
>  
I am engaging with the community directly but we have agreed and
predetermined engagements with the Fedora Council to enact actual changes.
We cannot take the view of a singular person and make changes based on
that, we defer to them for prioritisation and their input. That's how the
relationship works between CPE and the Fedora Community and it's how formal
requests and feedback are routed.


>  > It
>  > is not for me to change how that process works so please reach out to
>  your
>  > Council reps and engage through that channel.
>
>  Fedora has an established process for infra changes like this and you have
>  chosen to bypass it entirely by talking directly to the Council. 

As explained above we have our formal engagement process. I can bring this
up with Council in our next scheduled sync if the feeling is that we should
be engaging through other means. I'm happy to accomodate.


>  And now you say
>  "this is how this process works" -- well, in fact it isn't.
>
>  https://docs.fedoraproject.org/en-US/program_management/changes_policy/
>
>  https://pagure.io/Fedora-Council/tickets/issue/292#comment-640101 

+1 on that ticket I would like to see clarity on this point so that we can
engage in the right way in the future. Our engagement was not designed to
side step known processes, it was taken at face value to engage with
Council as previously agreed on.


>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[R P Herrold]

On Mon, 6 Apr 2020, Leigh Griffin wrote:

>  We cannot take the view of a singular person and make changes based
> on
>  that, we defer to them for prioritisation and their input. That's how the 
But, having reviewed the 'wishlist' of criteria quoted last 
week, [in the thread with Ben Cotton's message last Friday -- 
I believe the URL to the list directly was posted in the 
thread: CPE Git Forge Decision, but cannot lay my hands on it 
presently], it very obviously had not been winnowed down or 
curated down into any sort of rank order priority, or even 
something as simple as an Agile set of cards, sorted into 
stacks:

	- Must be present, showstopper if absent
	- Expected, but not critical if absent
	- Nice to have, but 'neh'

... so that task decomposition could proceed.  If it had been 
openly done, with actual stakeholders at the table, the 'Must 
be free sources' criteria would have been in that top pile, 
and remained there.  Without that 'polestar', other criteria 
were treated as critical

As an outsider (from CentOS 1 era), who votes in each Fedora 
election, it looks as a non-transparent result is being 
'justified' ex post

If there are unacceptible non-Free parts at Gitlab to the 
Fedora vision of attainable via no non-freely licensed 
package, I'd be studying how to relieve the non-free 
constraints in Gitlab, rather than 'fighting City Hall'

Just my thoughts,

-- Russ herrold

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
>  The majority here is telling you to hold off execution of that
>  "decision" and revisit it, but you're ignoring those voices entirely and
>  offering useless "apologies" instead. You cannot pretend to be part of a
>  community if you just ignore its other members and do your own thing. 
[…]
>  You cannot wish for meaningful engagement in the future if you
> don't fix
>  your past mistakes and reverse bad decisions. 
+1

        Kevin Kofler

[Randy Barlow]

On 4/6/20 6:41 AM, Leigh Griffin wrote:
>  We are engaged with the Fedora Council on the next steps here for the
>
>  adoption of Gitlab / the retirement of Pagure from the CPE remit. That 
>  much of the decision has been made, the actual specifics are what we are 
>  engaging on to make sure that the Fedora needs are satisfied as we move 
>  forward. 
This is not a response to what I wrote, thus what I wrote still stands. 
It's not true that this is the only thing that can be done.

>  Your engagement influences how this will look in the future, we have
>
>  enough gathered to ensure that is the case but given the breadth and 
>  depth of Fedora, we do wish for people to engage. 
You've shown that this is not true by avoiding the opportunity for the 
community to influence the decision. If you avoiding community input on 
this decision, what reason does the community have to trust that you 
would listen to community input for other decisions?

[Vít Ondruch]

Dne 04. 04. 20 v 21:02 Aoife Moloney napsal(a):
>  * rpmautospec 0.0.1 through 0.0.10 have been released and deployed in
> staging 

Could somebody please update on the status? What were the proof of
concepts, what are takeaways? Was there any decision on the approach and
why?


Vít

[Pierre-Yves Chibon]

On Mon, Apr 06, 2020 at 11:09:37AM +0200, Vít Ondruch wrote:
>  
>  Dne 04. 04. 20 v 21:02 Aoife Moloney napsal(a):
>  > * rpmautospec 0.0.1 through 0.0.10 have been released and deployed in staging
>  
>  
>  Could somebody please update on the status? What were the proof of
>  concepts, what are takeaways? Was there any decision on the approach and
>  why? 
This is very much planned, but we wanted to do this once we have something to
show.
If we end up not being able to show something then we'll have a "lessons
learned" email but we're still currently planning on having something to show
and call for testing :)

So, while you wrote this in past tense, it's still present for us and hopefully
we will soon send the email calling for feedback.


Pierre

[Vít Ondruch]

Dne 06. 04. 20 v 12:29 Pierre-Yves Chibon napsal(a):
>  On Mon, Apr 06, 2020 at 11:09:37AM +0200, Vít Ondruch wrote:
> > Dne 04. 04. 20 v 21:02 Aoife Moloney napsal(a):
> >> * rpmautospec 0.0.1 through 0.0.10 have been released and deployed in staging
> >
> > Could somebody please update on the status? What were the proof of
> > concepts, what are takeaways? Was there any decision on the approach and
> > why?
>  This is very much planned, but we wanted to do this once we have something to
>  show.
>  If we end up not being able to show something then we'll have a "lessons
>  learned" email but we're still currently planning on having something to show
>  and call for testing :)
>
>  So, while you wrote this in past tense, it's still present for us and hopefully
>  we will soon send the email calling for feedback.
>  
Ok, thx for the update. I'll try to be patient ;)


Vít


>  Pierre
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Robbie Harwood]

Aoife Moloney <amoloney(a)redhat.com&gt; writes:

>  * We found a password, we do not know whose it is, but we have
> turned
>  it into the lost and found. 
I'm sorry, what?  Can you explain what this is and what it means?

Thanks,
--Robbie

[Stephen John Smoogen]

On Mon, 6 Apr 2020 at 13:34, Robbie Harwood <rharwood(a)redhat.com&gt; wrote:

>  Aoife Moloney <amoloney(a)redhat.com&gt; writes:
>
>  > * We found a password, we do not know whose it is, but we have turned
>  > it into the lost and found.
>
>  I'm sorry, what?  Can you explain what this is and what it means?
>
>  
This was something I slipped in to see if anyone was going to read any part
of things on the move or if everyone else was going to fixate on the other
parts. Thank you for reading past the first set of paragraphs.


-- 
Stephen J Smoogen.

[James Cassell]

On Mon, Apr 6, 2020, at 1:48 PM, Stephen John Smoogen wrote:
>  
>  
>  On Mon, 6 Apr 2020 at 13:34, Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  > Aoife Moloney <amoloney(a)redhat.com&gt; writes:
>  > 
>  >  > * We found a password, we do not know whose it is, but we have turned
>  >  > it into the lost and found.
>  > 
>  >  I'm sorry, what? Can you explain what this is and what it means?
>  > 
>  
>  This was something I slipped in to see if anyone was going to read any 
>  part of things on the move or if everyone else was going to fixate on 
>  the other parts. Thank you for reading past the first set of 
>  paragraphs. 
>   
I'd assumed it was a joke. Or that maybe you found a file called "password"
somewhere.

V/r,
James Cassell

[Erinn Looney-Triggs]

With all of the other noise going on around this, I wanted to thank you 
folks for putting this out. Even this basic update shed light on a few 
things I had no idea about, communishift and rpmautospec. So thank you 
it is much appreciated that you are doing these.

-Erinn

On 4/4/20 1:02 PM, Aoife Moloney wrote:
> # CPE Weekly 2020-04-04
> ---
> title: CPE Weekly status email
> tags: CPE Weekly, email
> ---
>
> # CPE Weekly: 2020-03-06
>
> Background:
> The Community Platform Engineering group is the Red Hat team combining
> IT and release engineering from Fedora and CentOS. Check out our teams
> info here https://docs.fedoraproject.org/en-US/cpe/
>
>
> ## GitForge Updates
> Idea for note:
> *There has been a lot of discussion this week on the devel and infra
> lists about the decision to move to GitLab in the near future.
> Firstly, let us apologize again to the communities for our drop in
> communication between the requirement collecting phase and the
> decision making phase. As we have said before, it was in no way, shape
> or form an intentional lapse of communications. However we do
> recognize that it was still nonetheless a decision that was not made
> in public, and for that we can only now offer our apologies for this
> mistake and learn a hard lesson from it.
> We do want to let you know that we deeply appreciate the requirements
> you have given us and would like to ask you to continue engaging with
> us while we are moving through our next steps with GitLab.
> While the discussions on the lists are deeply emotional, they are
> still incredibly valuable to us to truly comprehend the importance of
> our next steps in ensuring we make the right choices in the coming
> months.
> Now more than ever, your guidance is needed to make sure we achieve
> the best possible result for you and our team from this decision.
> CPE management and I, our team's product owner, are also actively
> engaging with the Fedora Council and soon the CentOS Board to make
> sure that ALL of the developments and progress between us and GitLab
> are publicly available.
> We have a long way to go in this process and your feedback on our
> progress will be vital to make sure we remain on course.
> We hope in time you can understand our decision was made in good
> intent for the betterment of both our team and the communities we
> serve, and we hope to still be able to rely on you all as peers and
> friends for feedback and guidance during this journey.*
>
>
>
> ## Fedora Updates
> * Final Freeze starts 7th April 2020 @ 1400 UTC
> * Pagure 5.9.1 release pushed to both staging and pagure.io
> * the-new-hotness configuration was updated
> https://pagure.io/fedora-infrastructure/issue/8783
> * Michal Konečný has been working on mapping the fedora infrastructure
> applications, his project, (which sounds really cool and useful!) can
> be found here https://github.com/Zlopez/fedora-infra-map
>
>
> ### Data Centre Move
> * Please note Communishift will be down from 13th April - 8th May to
> facilitate the first shipment wave of our datacenter
> * We are also still on track to switch to a reduced Fedora offering
> from 25th May until est. 1st July\*.
> * For a list of services we are planning to have available during this
> window, please see mail thread in archive
>
https://lists.fedoraproject.org/archives/list/[e-mail]...
> * We will not have staging available so we will not have capacity to
> review or deploy new or upgraded features and applications during this
> time.
> * As always, please view our public schedule here for more a more
> detailed overview
>
https://hackmd.io/@fedorainfra2020/rJpsA4FLL#First-draft-of-schedule-for-...
> * We found a password, we do not know whose it is, but we have turned
> it into the lost and found.
>
>
> ### AAA Replacement
> * First development phase complete & the team worked through 57 tickets in total
> * The codebase was sent to our team first for demo and we will be
> using feedback to develop the portal further
> * During phase two we would like to change some codebases in existing
> apps, and write documentation on how to upgrade applications to
> redirect to the new API
> * We would like to roll this request for feedback out to some
> community maintainers during this phase too for another iteration on
> the service and documentation
> * Our work is publicly tracked here
> https://github.com/orgs/fedora-infra/projects/6 so please stop by and
> check out the progress we are making, and what we are looking at
> working on next
>
>
>
> ### CI/CD
>
> * Monitor-gating is still running in production and giving us some
> data about the health of the packager workflow:
>      * For example, these are the statistics between Monday and Wednesday:
> 39 messages retrieved
> prod.monitor-gating.multi-build.end.failed  --  7
> prod.monitor-gating.multi-build.end.succeeded  --  2
> prod.monitor-gating.multi-build.start  --  10
> prod.monitor-gating.single-build.end.failed  --  3
> prod.monitor-gating.single-build.end.succeeded  --  7
> prod.monitor-gating.single-build.start  --  10
> * rpmautospec 0.0.1 through 0.0.10 have been released and deployed in staging
>      * We got two builds to go through fine, from the same commit,
> getting two different NEVR and an auto-generated changelog
>      * However, for this to happen, we had to tweak a couple of things
> on the builder which is not really ideal/acceptable, so we moved a
> part of the processing inside the chroot where the SRPM will be built,
> which solved the main issues we faced
>      * To be done: Make tagging (latest) existing builds a separate
> operation executed outside the build root, to avoid having to talk to
> Koji inside it.
>      * In other words: Stay put, we're getting there!
>
>
>
> ### Sustaining Team
> * Mbbox
>      * The team have made some progress on koji-builder CRD
> * The team are also working on Bodhi 5.3 with few improvements and bug
> fixes from 5.2.
> * The team had a reboot and Update cycle this week.
> * The team are also discussing ideas around a releng bot to help
> process the tickets that require manual interventions.
> * They also add more updates to compose-tracker
> * And started playing with odcs on new
> odcs-backend-releng01.phx2.fedoraproject.org
>
>
>
> ## CentOS Updates
>
> ### CentOS
> * CentOS CI is stable with 0 downtime!
> * RHEL 7.8 released this week too!
>
>
> ### CentOS Stream
> * qt5, go-toolest (module), container tools (module) are updated to
> their 8.2 versions
> * We are also looking at easier automation of koji tags
>
>
>
> As always, feedback is welcome, and we will continue to look at ways
> to improve the delivery and readability of this weekly report.
>
>
> Have a great weekend!
>
> Aoife
>
>
> Source: https://hackmd.io/gSci385uRoeNVEuoNUS1pg?view
>
>