Re: Welcome and discussion starter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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



[Index of Archives]     [Fedora&nbdp;Development]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux