On Oct 14, 2008, at 3:37 PM, Brice Figureau wrote: >> >> Sorry I'm taking longer than normal on this code review. >> >> I'm not quite comfortable pushing this into 0.24.6, since I think it >> needs a bit more thought to see how it fits into the language, so I >> don't want to rush it. > > If you want my opinion, I don't think this should not be merged in a > subrelease, this looks like stuff for 0.25. I don't mind if that's not > even merged if you don't want this feature (I wasn't the one who > requested this feature, I'm not even sure I'd use it in production). > That was fun and easy to add thanks to puppet modularity, though :-) > >> I'll assess the code this week, hopefully. > > OK. There is no hurry on my side, the job is done.
Cool. > >> I assume these overrides follow the same rules as current overrides >> -- >> only possible within a subclass? > > Maybe I'm plain wrong, but I don't think this restriction is > necessary, > since after all if the original resource is not collected/realized it > doesn't even exist. So the override is just that we are > "instantiating" > a different resource than what was exported/virtualized. Note that multiple classes can realize a given resource. Thus, it does matter, or at least, can. -- Good judgment comes from experience, and experience comes from bad judgment. --Barry LePatner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
