I'm gonna hijack this conversation a little to add one item - adding a replacement/alternative to the ParsedFile provider. Right now it's the main method provided by Puppet to manipulate files (aside from Augeas), but it's buggy, cryptic, poorly documented, and generally unreliable. Having an alternative that's documented, well defined, and easy to use would be a big help to a lot of people. This is something that I would really like to have in core, and if we have enough people that want this feature I would like it prioritized for 4.0.
On Wed, Aug 28, 2013 at 8:45 AM, Andy Parker <a...@puppetlabs.com> wrote: > On Wed, Aug 28, 2013 at 7:27 AM, Henrik Lindberg < > henrik.lindb...@cloudsmith.com> 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%2bunsubscr...@googlegroups.com> >> . >> To post to this group, send email to puppet-dev@googlegroups.com. >> 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 > a...@puppetlabs.com > 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 puppet-dev+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Adrien Thebo | Puppet Labs -- 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+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
