F21 schedule: what would you do with more time?

[Kevin Fenzi]

On Thu, 22 Aug 2013 18:00:54 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

...snip...

> > What Infrastructure projects would be helped by this?
> A web infrastructure to
> * ease package orphanage.
> * launch AWOL/MIA requests
> * a unified koji/bodhi/bugzilla Web-GUI
> * much longer build.log holding time for FTBFS.

Yep. Although these could be done any time in the release cycle if
people were working on them right? 

> Also,
> - faster builders: Introduction of the arm has significantly
> increased the turn around times of package building.

Yeah. I don't know of any faster arm hardware yet, but if there is some
we could look at upgrading to it. 

> - better mirroring: I am having the impression mirrormanager doesn't 
> work well at all. E.g. this morning, yum sent me around the globe for 
> rawhide and failed in the end, seemingly because all fast mirrors
> seem to be busy loading f20.

I think part of this also might be us signing all the rpms for f20.
This means pretty much every package changes due to the signature.
Also, yeah, the f20 tree syncing out. (Although it should be hardlinked
to rawhide). Hopefully this will stablize in the next few days. 
> 
> > Web and design team,
> > would slowing down the release focus allow time to work on, oh,
> > say, getting the Wiki beautiful (or does it not matter)?
> Well, IMO the web design is the least issue to be concerned about
> wrt. the release process and packager works.
> 
> What would really make sense is a faster koji/bodhi/bugzilla. From
> here, esp. bugilla is such kind of clumsy to use and ... such kind of
> slooow, I am glad I don't have to use it.

Yeah, there are folks working on making bugzilla faster. ;( 

I agree it's an issue. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130822/a76fb341/attachment.sig>