-----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@xxxxxxxxxxxxxxxxx - ------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJRGzevAAoJEAkwIK7bXCER7K4MAKqYobEIMEsIGsUnc40yyXlZ gRPtJBo7fyrYO0BweYZaco2xKuUJtmA2lnAEzup4yHbjxpHUJrbYHdlkK4TWZZYi gad058ZmAC1WHTMWnmf7wHUR/vjWCl9DjDKXcbw0/mSBNMyCDyvc+P6qMZGlSwMD 8Dd7CICwmIM5hU/cgwpba2lbHhfK3E+VZA+lN6Pa10jtabFcWEtn1DYnw9rVYNko GdTy84j0fC/kqytb/5Yhq+MXe7Mo1a9PfrWFDyukAyJSr+cfg4dpSwqQXmvpsdQq p1VVPymcvoC9D709P7g3+6XXHp+r1nOLLgI1PWOp0nnB0sJra2UvXkl24GXXtAWg X8GTFjKVuclxN6YOjWj0hkKzTIeD9pSfMf8b0u5YODekZbJuVMOhnEx7q/fqFRvO R6NFqYflqDzWykww1H1nbMqAVlSNiTKqSDnVd+VMWf9zrPAmZwhuTgzFiTYMChby 0aI5RkVAa2vsmm+MPIDElBPlbVFu/gMCYpt6NvlhVg== =Kmf3 -----END PGP SIGNATURE----- _______________________________________________ formulas-devel mailing list formulas-devel@xxxxxxxxxxxxxxxxxxxxxx https://lists.fedorahosted.org/mailman/listinfo/formulas-devel
