On Thu, Sep 03, 2020 at 11:01:21AM +0200, Aleksandra Fedorova wrote:
I've added mine to the taiga board.
One I'd like to highlight is the Community Openshift instance
It didn't survive the datacenter move, but it is a key project for
Fedora if we want to decentralize the infrastructure and let community
maintainers and not just CPE to work on services for Fedora.
See the status update email to devel-announce.
The other is transparency for infra resources which we use
The argument like "we can not do X because we don't have resources for
it" appears often, but currently we don't have data to make any
meaningful decisions here.
For example: how much does it "cost" for Fedora to enable ELN builds?
How much resources COPR takes? What is the impact of flatpacks? How
much it takes to add testing for new architecture?
We need to be able to measure these things so we can plan and negotiate better.
I don't disagree, but I don't think it's just that we are lazy and don't
calculate this, I think estimating things is really hard.
How would you estimate ELN builds? There's disk space, there's cpu
cycles (but some of that would have just been idle?) There's composes
disk space and cpu... some amount of BW I guess. But with just "ELN will
have a subset of packages of rawhide, we aren't sure yet which" how are
we supposed to estimate it?
Note that we have a initiative on the board for metrics... this I think
would be the first step for this. See what we are using at X and then
again at Y after something lands, or at least give us more information.
> 3. Image builder in composes (leading to image builder distinct
> compose for spins)
IMHO this needs more widespread discussion and agreement on a plan
before we should work on it. This changes lots of fundamental things
(release cycle) that lots of teams (qa, releng, infra, websites, fesco, docs)
use. It's going to rearrange how almost all of the project works.
> 4. Updated Fedora notifications system
I think we need a better description what does it mean "updated" .
What are the expectations and acceptance criteria?
The current Fedora Notifications System (FMN), is running on an EOL
version of Fedora. It's python2. It only knows fedmsg, not
fedora-messaging. It takes hours to restart. So, basically this is
rewriting it to be maintainable and make the interface easier to use.