updates and testing instead of lifecycle

[Kevin Fenzi]

So, instead of trying to tweak the life cycle, how about another
alternate approach: 

Short term/f21: 

- For those 'featured stacks' that we are going to integrate and test,
  and all there deps, we setup some new group for Bodhi
  ("server-critical-path"). 

- We setup new rules/critera/test plans for when updates are allowed to
  go stable that are in this group. (open to ideas on what this would
  be exactly, I suspect we would want to rope in maintainers of those
  components) This would allow folks to know that if they install the
  release version and apply updates everything will continue to work. 

- Look at default partitioning/setup that will let us use lvm thinp and yum
  pre/post transaction snapshots for extra paranoia. This may require
  us to decide that say /srv is where most user data is by default. 

- Work to improve fedup support for server use cases (remote machine,
  etc) and make sure Fn->Fn+1 for server case is heavily tested and
  rollbacks are supported. (This may well need additional developer
  time) 

- Create comps groups for each 'featured stack' of things, so they can
  be selected at install time or installed later. Ideally we would test
  all of these, but since any combo of them could be installed at once,
  we may have to pick and choose. Possibly "each feature by itself" and
  "all features at once" would be easy cases to start with. 

Longer term: 

- Add some logic to bodhi (or wherever) that would note updates that
  require a 'restart' in addition to a 'reboot'. Or setup some way to
  notify admins things that need restart. (email to root from
  needs-restarting?)

- Perhaps make a server specific 'initial setup' that sets some server
  specific things instead of making a local user. (root email alias,
  logs retention, etc. 

- Improve server docs a lot. Possibly include a best practices doc. 
Especially note new features like cgroups, journald, etc. 

- Grow out more featured applications. 

-  Decide on and work on integration of our applications with base
stuff like auth backend, database, CM, monitoring, backup solution,
log monitoring, intrusion detection, and probibly a bunch of other
things. 

- Look at all the container solutions (possibly this is with other
  working groups) and see if any of them should be 'featured' and made
  well integrated. Possibly someday the containers take over for the
  normally installed versions of applications. 

Thoughts?

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/server/attachments/20131108/0ce28b9a/attachment.sig>