Welcome everyone.
I'm sure many of you have seen: https://fedoraproject.org/wiki/Fedora_formulas and http://lists.fedoraproject.org/pipermail/devel/2013-January/176011.html
but if not, please do go scan through those.
I'd like to start discussion here on a number of things we should decide and figure out and design before we start digging into too many implementation details.
I'd like to suggest we work on the assumption that a formula is a signed tag/commits in a git repo. I think making formulas rpms is going to be too much overhead for us.
I think it might be best to look at rules/guidelines we want to have first, keeping them as high level above implementation details as we can at this point.
I'll start with a stawman for people to add to/pick apart:
* Must use packages from the package collection, installed with the normal distro tools.
* Must not change non config files in those packages. ie, only can change files marked config in the package management system or add new files.
* Can depend on other formulas having been applied.
* Can conflict with other formulas. ("Sorry, you have apache server formula installed, so lighthttpd cannot be run")
* Must have an 'uninstall' method. (return config, remove packages)
* May be interactive and ask users questions, but should also include a set of default answers that can be used with --nointeractive.
* Must log when they were run / possibly output.
* Must have a detailed use case/description.
* Your idea here.
Thoughts?
kevin
From: Kevin Fenzi kevin@scrye.com I'd like to suggest we work on the assumption that a formula is a signed tag/commits in a git repo. I think making formulas rpms is going to be too much overhead for us.
I think this makes a lot of sense. Maybe someday way down the road, if this all pans out nicely and things stabilize, rpms might make sense.
I agree with all your bullet points too.
One issue I didn't see covered is how should things be handled when an formula has been applied, but has since been updated. Sure you can 'git pull', but then what? I still haven't had a chance to play with ansible, but will be soon so I'm not sure where this goes from there. With something like puppet, the formula/recipe/manifest thingy is intended to be idempotent so that reapplying to things already in the correct state is harmless, yet if the manifest has been changed then the targeted resources will be affected accordingly.
I guess for that matter, this brings up another basic point that should be made. Are the formulas intended to manage the initial setup only and then are no longer needed or are they intended to be used to enforce the setup for the lifetime of the deployment?
-- John Florian
On Tue 12 February 2013 15:13:27 John.Florian@dart.biz wrote:
With something like puppet, the formula/recipe/manifest thingy is intended to be idempotent so that reapplying to things already in the correct state is harmless, yet if the manifest has been changed then the targeted resources will be affected accordingly.
So is Ansible
formulas-devel-bounces@lists.fedorahosted.org wrote on 02/12/2013 15:36:02:
From: Ryan Rix ry@n.rix.si To: Development discussion for formulas <formulas- devel@lists.fedorahosted.org> Date: 02/12/2013 15:36 Subject: Re: Welcome and discussion starter Sent by: formulas-devel-bounces@lists.fedorahosted.org
On Tue 12 February 2013 15:13:27 John.Florian@dart.biz wrote:
With something like puppet, the formula/recipe/manifest thingy is intended
to
be idempotent so that reapplying to things already in the correct
state is
harmless, yet if the manifest has been changed then the targeted
resources
will be affected accordingly.
So is Ansible
That's what I figured. So the question(s) simply comes down to, "Do we want the formulas to be applied perpetually, or just initially?" If just initially, should the formulas provide support for handling updates to existing deployments as those formulas evolve?
-- John Florian
On Tue, 12 Feb 2013 15:40:31 -0500 John.Florian@dart.biz wrote:
That's what I figured. So the question(s) simply comes down to, "Do we want the formulas to be applied perpetually, or just initially?" If just initially, should the formulas provide support for handling updates to existing deployments as those formulas evolve?
An excellent question. ;)
I guess my instinct is to just target initial setup. If something is improved/changed in the formula they could re-run it and get those improvements. But the issue would be:
run LAMP stack formula use it, setup some sites, reconfigure things as you want them new formula version comes out. re-run new formula
Does the new formula then mess up your existing config? Or can we have things setup in such a way that we don't touch it if it's been further configured, but this opens up a pretty big can of worms.
kevin
Kevin Fenzi (kevin@scrye.com) said:
That's what I figured. So the question(s) simply comes down to, "Do we want the formulas to be applied perpetually, or just initially?" If just initially, should the formulas provide support for handling updates to existing deployments as those formulas evolve?
An excellent question. ;)
I guess my instinct is to just target initial setup. If something is improved/changed in the formula they could re-run it and get those improvements. But the issue would be:
run LAMP stack formula use it, setup some sites, reconfigure things as you want them new formula version comes out. re-run new formula
Does the new formula then mess up your existing config? Or can we have things setup in such a way that we don't touch it if it's been further configured, but this opens up a pretty big can of worms.
I think an initial goal would be that any updated formula changes the package set accordingly, but doesn't touch the configuration.
Perhaps it should even operate on the principle that it never touches the configuration unless it's already RPM-clean? (i.e., not changed since package installation.)
Bill
From: Bill Nottingham notting@redhat.com Kevin Fenzi (kevin@scrye.com) said:
That's what I figured. So the question(s) simply comes down to, "Do we want the formulas to be applied perpetually, or just initially?" If just initially, should the formulas provide support for handling updates to existing deployments as those formulas evolve?
An excellent question. ;)
I guess my instinct is to just target initial setup. If something is improved/changed in the formula they could re-run it and get those improvements. But the issue would be:
run LAMP stack formula use it, setup some sites, reconfigure things as you want them new formula version comes out. re-run new formula
Does the new formula then mess up your existing config? Or can we have things setup in such a way that we don't touch it if it's been further configured, but this opens up a pretty big can of worms.
I think an initial goal would be that any updated formula changes the package set accordingly, but doesn't touch the configuration.
Perhaps it should even operate on the principle that it never touches the configuration unless it's already RPM-clean? (i.e., not changed since package installation.)
That seems like a reasonable approach. I can't think of any examples offhand where that would be a bad policy. -- John Florian
On Tue, Feb 12, 2013 at 12:52:36 -0700, Kevin Fenzi kevin@scrye.com wrote:
- Must have an 'uninstall' method. (return config, remove packages)
Are packages installed before the formula kept track of? Are packages installed that are used by packages or formulas later tracked? If not, what should the formula do? (Perhaps not remove packages that have dependencies outside of the formula?)
From: Kevin Fenzi kevin@scrye.com I think it might be best to look at rules/guidelines we want to have first, keeping them as high level above implementation details as we can at this point.
I think another requirement will be that the formulas are pegged to a specific Fedora release. While there may not need to be much in the way of differences from release to release, it does happen. I know I have to have lots of conditional handling in my puppet manifests where I'm covering back to at least Fedora 14. An easy case to imagine is the mysql => mariadb transition that appears to be possibly be underway. A real life example (that's been wholly unfun) is a postfix + amavisd-new + clamav + spamassassin mail stack. There has been major shifts in the packaging and integration requirements.
These changes may all be improvements, but I think any such formula arrangement is going to need to cope with them. Maybe these too can have conditions to cover such changes rather than having numerous forks. If conditioned, then you might also want to nail down the policy of supporting only those Fedoras not at EoL. -- John Florian
On Tue, 12 Feb 2013 17:15:19 -0500 John.Florian@dart.biz wrote:
From: Kevin Fenzi kevin@scrye.com I think it might be best to look at rules/guidelines we want to have first, keeping them as high level above implementation details as we can at this point.
I think another requirement will be that the formulas are pegged to a specific Fedora release. While there may not need to be much in the way of differences from release to release, it does happen. I know I have to have lots of conditional handling in my puppet manifests where I'm covering back to at least Fedora 14. An easy case to imagine is the mysql => mariadb transition that appears to be possibly be underway. A real life example (that's been wholly unfun) is a postfix + amavisd-new + clamav + spamassassin mail stack. There has been major shifts in the packaging and integration requirements.
Sure, if we are going with git repo per formula (as it seems folks seem to like so far), we could do a branch per target...
These changes may all be improvements, but I think any such formula arrangement is going to need to cope with them. Maybe these too can have conditions to cover such changes rather than having numerous forks. If conditioned, then you might also want to nail down the policy of supporting only those Fedoras not at EoL.
I agree.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, February 12, 2013 12:52:36 PM Kevin Fenzi wrote:
Welcome everyone.
I'm sure many of you have seen: https://fedoraproject.org/wiki/Fedora_formulas and http://lists.fedoraproject.org/pipermail/devel/2013-January/176011.html
but if not, please do go scan through those.
I'd like to start discussion here on a number of things we should decide and figure out and design before we start digging into too many implementation details.
I'd like to suggest we work on the assumption that a formula is a signed tag/commits in a git repo. I think making formulas rpms is going to be too much overhead for us.
I think it might be best to look at rules/guidelines we want to have first, keeping them as high level above implementation details as we can at this point.
I'll start with a stawman for people to add to/pick apart:
Must use packages from the package collection, installed with the normal distro tools.
Must not change non config files in those packages. ie, only can change files marked config in the package management system or add new files.
Can depend on other formulas having been applied.
Can conflict with other formulas. ("Sorry, you have apache server formula installed, so lighthttpd cannot be run")
Must have an 'uninstall' method. (return config, remove packages)
May be interactive and ask users questions, but should also include a set of default answers that can be used with --nointeractive.
Must log when they were run / possibly output.
Must have a detailed use case/description.
Your idea here.
Thoughts?
kevin
- -- I've been thinking of implementation, in general terms. A lot of the details would fall out if a few preliminary goals are established, and the replies so far have come from a necessarily technical perspective. Allow me to offer another, on presentation:
Who is the target audience for formulas? We can roughly group the user base into two areas: end users and experienced users. I would group the average desktop linux enthusiast in the former, and include the majority of Fedora contributors, system administrators, and wizened enthusiasts in the latter.
Targeting the end user would require a lot more effort in presentation, but would provide a bigger payoff in terms of marketing value and user draw. Targeting the latter would allow a much easier implementation - really, we would just have to agree on a common style and guidelines for shipping playbooks and put them in a git repo to be cloned.
Without solid presentation, we will expending effort to the exclusion of less experienced users. I propose that from the beginning, Formulas should be implemented with the intent of making their use as easy as clicking the link to download a spin. I think that we can agree that drawing more users to Fedora is generally a Good Thing, and that Formulas could help keep the contributor funnel full.
So, a Formula should contain: - an ansible playbook - any required ansible templates - descriptive content in html using a defined template, or in a format translatable to html - a fun banner image - indexable metadata
The presentation layer should provide: - a browseable, searchable interface built from Formula metadata - a rating system, to promote involvement - a moderated comment system, to promote involvement (although comments can detract from perceived professionalism) - a script to crawl through the git source and create and index the content - individual Formula pages displaying the above mentioned descriptive content, with direct links to the playbook file itself - a GUI URI handler to guide the user through the interactive portions of the formula, and to promote a sense of accomplishment
- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'd like to throw my ideas into the ring. I've spent a bunch of time thinking about this from a slightly different perspective, one of flexibility and usefulness to the Formula contributor.
I've taken the time to put together a github repository with some code (the code is just a prototype and should not be considered yet) and a fairly thought out README file. You can read this at https://github.com/herlo/formulas/blob/master/README.rst at your leisure.
So far, I agree with pretty much everything put forward with a few exceptions. Here is my take on this...
- - Delivery and Development -
Using git is definitely a must! It should be used to develop formulas and submit them for approval. This works well with the github fork and pull request model. Take an 'approved' formula and improve upon it. Or make a new one, it doesn't matter. The value is gained in a pull request, code review and approval. This definitely helps speed development of formulas.
A GUI is definitely a must as well. Integrating with Anaconda is a great idea, but may take a bit longer than desired to get in place. A simple GUI that can be searched is a definite must. But how do you test new formulas using the GUI? Just something to consider here.
- - Flexibility is Key -
Being flexible is important, both to those who create as well as those who will use formulas. If we stick to one configuration management system, we lose some flexibility and choice. It seems ansible is the choice most want, but what is the harm in having alternates available? Limiting the choices here limits what a formulas developer could create because even though it seems like it, all CM systems are not created equal.
- - Contributor and End User Friendly -
At the risk of becoming the straw man (please be gentle), I suggest we consider an approach that allows for any number of backends. In other words, I would like to develop formula in the CM system I choose, or at least have a choice between a number of them.
This suggestion is not without its challenges. For one, there's the consideration of the presentation and the user. How would the user know which backend it's using. Hopefully they wouldn't, nor would they care. It may require installing yet another package to work. I'm not sure how this would work yet, but think it's worth considering.
Additionally, there would have to be considerations made in the repository for how to determine which backend said formula is using. This problem could be easily overcome in many ways, however, simply using a configuration value in the manifest Pete suggested below would be simple enough.
If the end user is the most important thing, we'd need to make a way to filter for the installed backend(s), or inform them of a need for additional packages. Maybe requiring them to use yum or package kit to install said packages.
In terms of contributors, we want more, right? So let's consider a way that makes it easier for them to contribute something simple to use in their own way. Let's be flexible about it and make it easy to contribute. If they want to use puppet instead of ansible, or salt instead or bcfg2 for that matter, let's figure out a way to make that possible and make it easy on our end users to boot.
It seems logical to me that we could use a limited set of CM engines to accomplish this goal. Maybe we should consider some criteria for what CM tool(s) would be useful with formulas.
Cheers,
herlo
- -----
I've been thinking of implementation, in general terms. A lot of the details would fall out if a few preliminary goals are established, and the replies so far have come from a necessarily technical perspective. Allow me to offer another, on presentation:
Who is the target audience for formulas? We can roughly group the user base into two areas: end users and experienced users. I would group the average desktop linux enthusiast in the former, and include the majority of Fedora contributors, system administrators, and wizened enthusiasts in the latter.
Targeting the end user would require a lot more effort in presentation, but would provide a bigger payoff in terms of marketing value and user draw. Targeting the latter would allow a much easier implementation - really, we would just have to agree on a common style and guidelines for shipping playbooks and put them in a git repo to be cloned.
Without solid presentation, we will expending effort to the exclusion of less experienced users. I propose that from the beginning, Formulas should be implemented with the intent of making their use as easy as clicking the link to download a spin. I think that we can agree that drawing more users to Fedora is generally a Good Thing, and that Formulas could help keep the contributor funnel full.
So, a Formula should contain: - an ansible playbook - any required ansible templates - descriptive content in html using a defined template, or in a format translatable to html - a fun banner image - indexable metadata
The presentation layer should provide: - a browseable, searchable interface built from Formula metadata - a rating system, to promote involvement - a moderated comment system, to promote involvement (although comments can detract from perceived professionalism) - a script to crawl through the git source and create and index the content - individual Formula pages displaying the above mentioned descriptive content, with direct links to the playbook file itself - a GUI URI handler to guide the user through the interactive portions of the formula, and to promote a sense of accomplishment
- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@fedoraproject.org
- -------------
On Tue, 12 Feb 2013 23:50:25 -0700 Clint Savage herlo1@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'd like to throw my ideas into the ring. I've spent a bunch of time thinking about this from a slightly different perspective, one of flexibility and usefulness to the Formula contributor.
I've taken the time to put together a github repository with some code (the code is just a prototype and should not be considered yet) and a fairly thought out README file. You can read this at https://github.com/herlo/formulas/blob/master/README.rst at your leisure.
So far, I agree with pretty much everything put forward with a few exceptions. Here is my take on this...
- Delivery and Development -
Using git is definitely a must! It should be used to develop formulas and submit them for approval. This works well with the github fork and pull request model. Take an 'approved' formula and improve upon it. Or make a new one, it doesn't matter. The value is gained in a pull request, code review and approval. This definitely helps speed development of formulas.
Sure. I'm not sure we want to host all the formulas at github though. I guess thats something to think about.
A GUI is definitely a must as well. Integrating with Anaconda is a great idea, but may take a bit longer than desired to get in place. A simple GUI that can be searched is a definite must. But how do you test new formulas using the GUI? Just something to consider here.
Yep. I want a command line version as well. Testing gui's can be tricky, I think our only option there is to use a peer review type setup where a formula maintainer reviews someone elses formula and provides feedback. With a command line tool we could run automated testing to some degree as well as script some checking/linting on the playbooks themselves.
- Flexibility is Key -
Being flexible is important, both to those who create as well as those who will use formulas. If we stick to one configuration management system, we lose some flexibility and choice. It seems ansible is the choice most want, but what is the harm in having alternates available?
I think the harm is confusion, spreading of resources and difficulty in testing/qa/infrastructure. If we have a base set of templates for say ansible, and someone makes a formula in puppet, that could very well behave differently.
Limiting the choices here limits what a formulas developer could create because even though it seems like it, all CM systems are not created equal.
Well, in the same way limiting Fedora to rpms is limiting. ;) Sure, we could ship debs too, but...
- Contributor and End User Friendly -
At the risk of becoming the straw man (please be gentle), I suggest we consider an approach that allows for any number of backends. In other words, I would like to develop formula in the CM system I choose, or at least have a choice between a number of them.
Well, I suppose if you really really had to use cfengine for a formula you could write a small ansible wrapper that installed cfengine and ran it's commands. However, I am not sure this really has that many advantages.
This suggestion is not without its challenges. For one, there's the consideration of the presentation and the user. How would the user know which backend it's using. Hopefully they wouldn't, nor would they care. It may require installing yet another package to work. I'm not sure how this would work yet, but think it's worth considering.
Well, or collection of packages. I don't think this is the big hurdle...
Additionally, there would have to be considerations made in the repository for how to determine which backend said formula is using. This problem could be easily overcome in many ways, however, simply using a configuration value in the manifest Pete suggested below would be simple enough.
Sure. I don't think thats the problem though.
I think QA, impossible documentation requirements, differing behavior, lack of area knowledge in all the various possibly CM's, dependency on many more tools/stacks are all the problems.
I don't like the idea we would have:
"Hey, contributor, you want to contribute a formula! great! So, first look at all the docs of ansible, puppet, cfengine, chef, salt, bcfg2, cdist, juju, and pick which one you want write your formula in"
If the end user is the most important thing, we'd need to make a way to filter for the installed backend(s), or inform them of a need for additional packages. Maybe requiring them to use yum or package kit to install said packages.
In terms of contributors, we want more, right? So let's consider a way that makes it easier for them to contribute something simple to use in their own way. Let's be flexible about it and make it easy to contribute. If they want to use puppet instead of ansible, or salt instead or bcfg2 for that matter, let's figure out a way to make that possible and make it easy on our end users to boot.
I think this might lead to lots of confusion...
It seems logical to me that we could use a limited set of CM engines to accomplish this goal. Maybe we should consider some criteria for what CM tool(s) would be useful with formulas.
I think we should look at picking one. ;)
kevin
Being flexible is important, both to those who create as well as those who will use formulas. If we stick to one configuration management system, we lose some flexibility and choice. It seems ansible is the choice most want, but what is the harm in having alternates available?
I think the harm is confusion, spreading of resources and difficulty in testing/qa/infrastructure. If we have a base set of templates for say ansible, and someone makes a formula in puppet, that could very well behave differently.
I suspect they would end up behaving differently despite our best attempts and intentions. For example:
https://projects.puppetlabs.com/issues/7165
I don't mean to pick on puppet specifically, just to illustrate that you can't always get what you ask for. If this bug affected a formula, for good or bad, things are certainly going to change once that bug is resolved and despite your best efforts, you now have new and different behavior. If we stick with just one CM platform, we minimize these kind of undesired variations. -- John Florian
On Tue, 12 Feb 2013 17:58:32 -0700 Pete Travis me@petetravis.com wrote:
I've been thinking of implementation, in general terms. A lot of the details would fall out if a few preliminary goals are established, and the replies so far have come from a necessarily technical perspective. Allow me to offer another, on presentation:
Who is the target audience for formulas? We can roughly group the user base into two areas: end users and experienced users. I would group the average desktop linux enthusiast in the former, and include the majority of Fedora contributors, system administrators, and wizened enthusiasts in the latter.
Targeting the end user would require a lot more effort in presentation, but would provide a bigger payoff in terms of marketing value and user draw. Targeting the latter would allow a much easier implementation - really, we would just have to agree on a common style and guidelines for shipping playbooks and put them in a git repo to be cloned.
Sure. I think it may be that it's easier to target the one group short term, but keep the other group in mind for longer term implementation.
Without solid presentation, we will expending effort to the exclusion of less experienced users. I propose that from the beginning, Formulas should be implemented with the intent of making their use as easy as clicking the link to download a spin. I think that we can agree that drawing more users to Fedora is generally a Good Thing, and that Formulas could help keep the contributor funnel full.
Sure, but there might be some (hopefully informed) questions asked of the user. Ideally there would be a 'defaults' mode where it just took defaults, but I think interactivity is a good selling point as well.
So, a Formula should contain:
- an ansible playbook
- any required ansible templates
(These could well be required by all formulas...)
- descriptive content in html using a defined template, or in
a format translatable to html
- a fun banner image
- indexable metadata
The presentation layer should provide:
- a browseable, searchable interface built from Formula
metadata
- a rating system, to promote involvement
- a moderated comment system, to promote involvement (although comments can detract from perceived
professionalism)
- a script to crawl through the git source and create and
index the content
- individual Formula pages displaying the above mentioned
descriptive content, with direct links to the playbook file itself
- a GUI URI handler to guide the user through the interactive
portions of the formula, and to promote a sense of accomplishment
Yes to all this.
Also, I would really like a command line version of the tool that exists on the end user machine. (in addition to the gui one).
Much of the presentation layer could fit into a larger "software center" type thing as well. There's been talk of such a project, and if there's any movement on it we could perhaps leverage that for formulas as well.
kevin
On Feb 13, 2013 9:37 AM, "Kevin Fenzi" kevin@scrye.com wrote:
(snip)
Yes to all this.
Also, I would really like a command line version of the tool that exists on the end user machine. (in addition to the gui one).
Much of the presentation layer could fit into a larger "software center" type thing as well. There's been talk of such a project, and if there's any movement on it we could perhaps leverage that for formulas as well.
kevin
The "software center" - we *should* come up with a catchy and unique name when the time comes - is exactly what I would like to see. Specifically, on a public hosted Web interface, instead of a local application. We would get hits from searches for "Installing Apache on Fedora 18" and the like, and perhaps put our offerings on display for potential users.
That said, I agree that a command line implementation, and a standardized definition of a Formula, should be the immediate priority, until the content is matured enough to present.
On competing CM solutions, I think we should pick one. Ansible seems the best choice, based on my limited expertise. I also see no problem with presenting other choices, as in "This formula is also available as a puppet module. " The majority of users will be administering their own machine only, so the most benefit to the most users would come from a solution that tailored to that use case. Really, the type of people deploying puppet in scale don't need us to churn out modules for them.
--Pete
Pete Travis (me@petetravis.com) said:
I've been thinking of implementation, in general terms. A lot of the details would fall out if a few preliminary goals are established, and the replies so far have come from a necessarily technical perspective. Allow me to offer another, on presentation:
Who is the target audience for formulas? We can roughly group the user base into two areas: end users and experienced users. I would group the average desktop linux enthusiast in the former, and include the majority of Fedora contributors, system administrators, and wizened enthusiasts in the latter.
Targeting the end user would require a lot more effort in presentation, but would provide a bigger payoff in terms of marketing value and user draw. Targeting the latter would allow a much easier implementation - really, we would just have to agree on a common style and guidelines for shipping playbooks and put them in a git repo to be cloned.
Without solid presentation, we will expending effort to the exclusion of less experienced users. I propose that from the beginning, Formulas should be implemented with the intent of making their use as easy as clicking the link to download a spin. I think that we can agree that drawing more users to Fedora is generally a Good Thing, and that Formulas could help keep the contributor funnel full.
So, a Formula should contain:
- an ansible playbook
- any required ansible templates
- descriptive content in html using a defined template, or in a format
translatable to html
- a fun banner image
- indexable metadata
The presentation layer should provide:
- a browseable, searchable interface built from Formula metadata
- a rating system, to promote involvement
- a moderated comment system, to promote involvement (although comments can detract from perceived professionalism)
- a script to crawl through the git source and create and index the
content
- individual Formula pages displaying the above mentioned descriptive
content, with direct links to the playbook file itself
- a GUI URI handler to guide the user through the interactive portions of
the formula, and to promote a sense of accomplishment
A lot here does depend on the target market you're looking at. For example, are we trying to get to the use case of users who want: http://spins.fedoraproject.org/ or the use case of users who want: http://jujucharms.com/charms/precise ?
These are vastly different target markets, and I'd honestly try and shoot for the second, not the first. Others may disagree.
Bill
On Wed, 13 Feb 2013 15:57:42 -0500 Bill Nottingham notting@redhat.com wrote:
A lot here does depend on the target market you're looking at. For example, are we trying to get to the use case of users who want: http://spins.fedoraproject.org/ or the use case of users who want: http://jujucharms.com/charms/precise ?
These are vastly different target markets, and I'd honestly try and shoot for the second, not the first. Others may disagree.
I think we should shoot for the second for now, but with the idea that someday down the road we might be able to satisfy the first. ;)
We are never fully going to be able to replace spins, as there are use cases that still require a fully setup media to boot from, but I think we can take over some needs people currently satisfy with spins at some point.
kevin
formulas-devel@lists.stg.fedorahosted.org
-
Bill Nottingham -
Bruno Wolff III -
Clint Savage -
John.Florian＠dart.biz -
Kevin Fenzi -
Pete Travis -
Ryan Rix