From Fedora Project Wiki

Revision as of 17:29, 26 February 2014 by Mattdm (talk | contribs)

Brainstorming

Remove this section as ideas are put into a more structured form (or discarded).

  • Retire appliance-creator
    • Anaconda-based installs are the way forward
      • Needs new ImageFactory release
      • Patch Koji for ImageFactory support
      • Then, needs new Koji release
      • Then, push new Koji release to Fedora production
  • Extend AutoQA to allow for automated testing of cloud images (if not already possible)
  • Automate rel-eng
    • produce scratch builds on change (note: we already have nightly images of rawhide and branched compose for months)
    • upload final release and re-release images to ec2 and ftp
  • Updated Web Site for Obtaining Cloud Images
    • Easier access to provided images for various use cases
    • Provide build toolchain
    • encourage community to use toolchain to build new products
    • Allow folks to share and review the work done by their peers
  • Implement new procedures for (a)periodical re-releases
  • Ensure usability of software stacks for cloud usage
    • Always have several different versions (major or minor releases, i.e. non-bugfix releases) ready for installation
    • Make sure older versions are supported and available as long as possible, particularly with new Fedora releases
      • i.e. apps running on F21 cloud images should still be able to run on F22 cloud images (and F23? How long should they work?)
  • More modularly-packaged kernel (modules that are not necessary in virtualized environments need become optionally installable)
  • More modularly-packaged (or written?) SELinux policies
  • Make it possible to install without l10n/i18n support (no extra languages, etc.) but keep the possibility to install them
  • Make it possible to install packages without documentation (to save space) but keep the possibility to install them

Suggested Structure

Basically, each of these are going to become a Change using the Fedora Features process (Changes/Policy). So, each should be a very lightweight version of Changes/EmptyTemplate. We should also rate each one for importance (overall/strategically) and urgency (things that need to get done *now*, things that need to land in f21, things that can land after) + a rationale for the urgency (blocks something, competitive need, etc).

So, I'm envisioning a list here which looks like this:

Change Name

Summary: Elevator pitch for the change. Importance: [ vital | moderate | nice-to-have ] Timeframe: [ now | F21 alpha | F21 beta | F21 release | F22 | F23+ ] / reason (e.g. "blocks ability to produce images" ) Scope: [ self-contained | complex system-wide ] link to change proposal page (can be not actually filled out yet)