I think that RedHat + Solaris would be a better base to start, since they are the most common *nix flavors on most companies. Maybe going a bit further and adding OSX to the mix to give everyone some guidelines on how to write the modules for the 3 major *nix based Operative Systems out there.
Telmo. Light travels faster than sound. This is why some people appear bright until you hear them speak On Tue, Feb 2, 2010 at 5:55 PM, Michael DeHaan <mich...@reductivelabs.com>wrote: > James Turnbull wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 3/02/10 3:27 AM, Michael DeHaan wrote: >> >> >>> Hi List! >>> >>> So I was talking with several folks on IRC this morning, and we came up >>> with an idea. >>> >>> One of the strengths of Puppet is it has a very large community with tons >>> of systems administration experience. This is huge. I'd like to unite >>> that experience more closely, so that this power is immediately available >>> and obvious to new and existing users. Currently we have a large >>> collection of repos, some containing one module, some containing many, but >>> they are fragmented: >>> >>> >> >> Mike >> >> I'd love to see this get off the ground. There have been a couple >> of attempts at it - and you can see some background at: >> >> http://reductivelabs.com/trac/puppet/wiki/CommonModules >> http://reductivelabs.com/trac/puppet/wiki/ModuleStandards >> >> >> > > Yep, read these (for benefit of the list, we were talking on IRC, I don't > actually read that fast!) ... seems not > be insurmountable. > > Even a tiny bit of pain getting this off the ground seems hugely worth it. > > What I'd like to do initially is start getting these together in one giant >>> curated repo, hosted on our github space, that makes it easier for all >>> Puppet users to contribute to. >>> >>> >> >> Sounds great - we had a play with a couple of ways to do this - >> mostly around git submodules (to allow you to check out individual >> modules from a git repo). I'd personally recommend not going down >> that path - I had issues. :) >> >> > > Can we start by grafting together everyone's modules and trying to > namespace them? > > Git subtree merge preserves attribution nicely... so everyone still gets > their credits. The paths > will then need to be merged around some. Temporarily, this might mean > prefixing modules > the paths of their creators if we have conflicts. > > If we need to make changes to them, there will be some testing work to be > done as well, which we can use help with. So this may mean identifying > which ones out of which repos are important for starters and trying them out > ... and moving more into the "curated" repo later ... basically keeping a > "to be processed" directory seperate from the main so we can more easily > identify what we need to transmogrify? We'll start small with some good > examples. > > > > >> >>> I think we need to start small, and identify some basic concepts we need >>> a collection of namespaced modules >>> to have, in order to work together well. If this takes off, we may >>> want to create a seperate list for development of the common modules -- TBD >>> -- but we could use puppet-users for now. >>> >>> >> >> I think the primary issue here is to have some common rules for >> handling certain scenarios: >> >> 1. Cross-platform support >> 2. Naming standard >> 3. Module construction >> >> I personally don't think these are hard problems to solve and I >> think it we put together two or three straw man variants as a >> talking point that'd get us further ahead than talking about it. >> >> > > Indeed. I'd rather try it and see what comes crashing down. We need to > be aware of what the problems could be though, no doubt. > > For our initial attempt, perhaps we should aim for mostly Debian+Red Hat > cross platformness with modules > supporting both? That seems reasonable and achieves a good starting base. > Of course there may be a lot of work getting to that... > > I need to check for any explict licensing in there, of course. We'd also > need to identify > what parts of them did things "weird" and try to homogenize them a bit, I'd > suspect. > > I don't mind doing the initial driving and getting the repo set up. More > collaborators on this would be good, and I think once we have this, it would > be easier for more people to contribute than what we have now. That all > being said, I'll be travelling a bit, so this may appear in pieces. Help > would be outstanding. > > If we commit to having something done a bit more quickly rather than trying > to get it perfect, and perhaps we get further this time, and over time we > can clean up what's there. Folks should know if they do a checkout in > these early days of such an effort, the modules may not remain compatible > and they should suspect a "git rebase" to break them. Over time, we can > move that towards being more consistent. > > So say we all? > > --Michael > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
