I'd like to add a vote for atomic Puppet client runs. http://projects.puppetlabs.com/issues/3806
Trevor On Wed, Aug 28, 2013 at 11:45 AM, Andy Parker <[email protected]> wrote: > On Wed, Aug 28, 2013 at 7:27 AM, Henrik Lindberg < > [email protected]> wrote: > >> Hi, >> There are a number of things to discuss and decide as the work on Puppet >> 4 is to start quite soon. I will be posting several topics (in separate >> threads). >> >> In summary: >> * There are a number of language features and issues to resolve; finalize >> ARMs (2, 3, 4, 8, 9, ...), internationalization, syntax details >> > > I don't think we need to tackle all of these for Puppet 4. > > >> * We need a way to refer to language revisions (as opposed to puppet >> overall version) >> > > I agree we need a way to talk about the version of the language, but I'm > unconvinced that we need to have the ability to select multiple versions of > the language in the same process for the same run. > > >> * Evaulator issues (let's tackle undef, and a bunch of other things) >> * Model / Catalog issues / features (anchor pattern, subgraphs, >> containment, etc.) >> > > Anchor pattern is already being worked on (and I think is the same as > containment that you list). It is looking like we will be using the > resource syntax for classes, but I haven't seen the final proposal from > Patrick yet. > > What do you mean by subgraphs? > > >> * Requirement on module metadata and the forge >> > > Could you be more specific? I'm not sure what this is referring to. > > >> * Puppet doc >> >> And a lot of other things I am sure. >> >> > I would have a slightly different list: > > * Split the codebase (master/agent/common? > apps/types+providers/language? something else?). We need to decide where > the right lines are to make the split and then figure out the work that it > will take to get there. This may or may not change how puppet is deployed, > but I think we can do it in a manner where we deploy in the same manner as > right now. > * Promote the egrammar to the default grammar. Do we keep the old > grammar around for ease of migration for users (I think we shouldn't)? > * Optimize the egrammar. It has to be faster than the existing grammar, > otherwise I don't think we can promote it. > * #8040 - anchor pattern. I think a solution is in sight, but it didn't > make 3.3.0 and it is looking like it might be backwards incompatible. > * Puppet Doc - I agree, this has sat and rotted for too long. It doesn't > show up on any of our roadmaps :( It seems to have just been forgotten > about. > * Remove all of the currently deprecated functionality (activerecord > store configs, many other things) > * Reboot support - This is being worked on, but didn't make it in time > for Puppet 3.3 (part of it did, but not all of it) > > Something that we also need to work out is how much Puppet 4 can break > compatibility. I've been aiming for the conservative approach were we try > to only break compatibility, when possible, by first providing a > deprecation warning for the old behavior, have the new behavior available > at the same time and then remove the old behavior in a major release. This > approach would mean that we can't change language semantics for the Puppet > 4 release because we haven't deprecated a lot of the behavior and provided > a new set of behaviors. I'm willing to be told that we can take a larger > step than that, though. > > Those are all of the things that we need to do that I know about. We > haven't decided on the timeline for 4.0 yet, but I suspect we should be > aiming for the end of the year. In the meantime, we, the PL employees, also > have to keep up on maintenance on PE and Puppet 3, so that is something to > keep in mind for the scope and how much we can do. > > >> I think it will help if we can keep this thread to talk about what we >> need to talk about, and then have a specific threads for the various topics. >> >> Some of the topics are perhaps quickly acted on, others may result in the >> need to write a new ARM. >> >> Regards >> - henrik >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to >> puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]> >> . >> To post to this group, send email to [email protected]. >> Visit this group at >> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> >> . >> For more options, visit >> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >> . >> > > > > -- > Andrew Parker > [email protected] > Freenode: zaphod42 > Twitter: @aparker42 > Software Developer > > *Join us at PuppetConf 2014, September 23-24 in San Francisco* > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
