m (→Change Name) |
|||
| Line 54: | Line 54: | ||
---- | ---- | ||
=== Dependency Name === | === External Need: ''Dependency Name'' === | ||
'''Summary:''' Elevator pitch for the change. | '''Summary:''' Elevator pitch for the change. | ||
Revision as of 17:36, 26 February 2014
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
- Anaconda-based installs are the way forward
- 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: 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)
Additionally, we are going to have dependencies on changes that are largely in other Fedora groups. These aren't really our changes, so we shouldn't be submitting them, but we should also list them. The enhanced automatic QA features of taskotron would be an example. Web design and marketing are others. So, something like:
External Need: Dependency 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" )
Fedora Sub-Project/SIG: [ QA | Websites | etc ]
Cloud SIG owner: (We can't just demand things, obviously. Who from our group is going to interface and possibly contribute?)
link to relevant whatever