<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 February 2014 10:44, Stephen Gallagher <span dir="ltr"><<a href="mailto:sgallagh@redhat.com" target="_blank">sgallagh@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
As a non-exhaustive list of example things we expect will need<br>
attention and would like input (particularly time-estimates) on:<br>
<br>
* Quality Assurance: Coverage increases and automation such as<br>
Task-o-Tron[1]<br>
* Release Engineering: Re-tooling and automation.<br>
* Documentation Team: Impact on creating documentation for three<br>
products.<br>
* Ambassadors: How do we market these new products and do we need to<br>
account for time to deliver marketing materials?<br>
* Websites Team: What sort of redesign work will we need to go through?<br>
* Working Groups: How long to deliver new technologies?<br>
* Marketing: What to distribute to folks at conferences, how to convey<br>
fedora.next to our users.<br>
* Translators: Need to be kept in the loop on any new stuff added that<br>
requires translations.<br>
* Infrastructure: applications changes to meet fedora.next needs or new<br>
applications development to help do so. (bodhi changes, etc)<br>
* Design: consider logos and other needs of products and what it might<br>
take to make them happen.<br>
<br>
<br>
These are just a few examples. We expect there to be plenty of other<br>
cases that need to be addressed, which is why we would like to hear<br>
them as soon as possible. FESCo will be attempting to determine a<br>
Fedora 21 schedule in the near future and would prefer not to make<br>
this decision in ignorance.<br></blockquote></div><div><br></div><div>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:</div>
<div><br></div><div>* 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.</div>
<div><br></div><div>* 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.</div>
<div><br></div><div>* 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.</div>
<div><br></div><div><br></div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>