Re: Fedora priorities for RH CPE team -- let's make a list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> https://teams.fedoraproject.org/project/fedora-council-infrastructure-priorities/us/10
> 
> 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
> https://teams.fedoraproject.org/project/fedora-council-infrastructure-priorities/us/8?kanban-status=439
> 
> 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.

...snip...

> > 3. Image builder in composes (leading to image builder distinct from main
> >    compose for spins)
> 
> +1

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. 

kevin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Users]     [Fedora Outreach]     [Fedora Desktop]     [Fedora KDE]     [KDE Users]     [Fedora SELinux]     [Yosemite Forum]     [Linux Audio Users]

  Powered by Linux