Help Wanted: Fedora.next schedule estimation

Stephen John Smoogen smooge at gmail.com
Mon Feb 24 21:56:42 UTC 2014


On 24 February 2014 10:44, Stephen Gallagher <sgallagh at redhat.com> wrote:

>
>
> As a non-exhaustive list of example things we expect will need
> attention and would like input (particularly time-estimates) on:
>
>  * Quality Assurance: Coverage increases and automation such as
>    Task-o-Tron[1]
>  * Release Engineering: Re-tooling and automation.
>  * Documentation Team: Impact on creating documentation for three
>    products.
>  * Ambassadors: How do we market these new products and do we need to
>    account for time to deliver marketing materials?
>  * Websites Team: What sort of redesign work will we need to go through?
>  * Working Groups: How long to deliver new technologies?
>  * Marketing: What to distribute to folks at conferences, how to convey
>    fedora.next to our users.
>  * Translators: Need to be kept in the loop on any new stuff added that
>    requires translations.
>  * Infrastructure: applications changes to meet fedora.next needs or new
>    applications development to help do so. (bodhi changes, etc)
>  * Design: consider logos and other needs of products and what it might
>    take to make them happen.
>
>
> These are just a few examples. We expect there to be plenty of other
> cases that need to be addressed, which is why we would like to hear
> them as soon as possible. FESCo will be attempting to determine a
> Fedora 21 schedule in the near future and would prefer not to make
> this decision in ignorance.
>

I am going to say that there are quite a few train problems here that can't
be seen without the Next getting further defined. A possible infrastructure
one would be:

* Storage needs.  Our combined supported release storage tries to be under
1TB and a lot of mirrors don't even copy all of that. How much extra disk
space will all the images require. Images are less able to be deduplicated
and can quickly push our storage over that. Storage for the amount of disk
access needed on the mirrors is also expensive (300GB SAS drives versus 4TB
SATA drives, etc.) Since we must also keep archives there needs to be
additional storage there also over time.

* Bandwidth needs. [Related to Storage.] The less mirrors have, the more
the bandwidth gets pulled by the Red Hat network. There are limits to how
much we can use here and changes to it usually occur after you need it.

* Download changes.. this actually falls into infrastructure, design and
webgroups. Where does start take you? Where does one get all the new images
from? What other application changes are needed. All of these will probably
have to fall into F22 because it will take F21 for the lower layers to
cement.


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140224/770ca903/attachment.html>


More information about the devel mailing list