Hello,
My opinion comes as a non-core developer but more as a user. I'd prefer
not to relearn anything so any change is something I'd like to avoid.
Even when you automatically change any existing template then you still
haven't changed the knowledge inside the users head. Given this has been
the
Hello
The discussion has diverged into something different. People agree we should
add an extra layer but implemented through proxy objects. It's also clear no
one starts actively working on this right now. At the same time I want to add
new macro, let's say rpm_distro? which returns
Hi,
I think that while there are benefits to moving away from the host object,
we have a de-facto API based on it.
A way to change without breaking user's template would be to use a "proxy"
object that maintains the same endpoints and allows adding functionality or
handling changes in the
I am also for keeping the change but giving more attention to the
upgrades and providing some tooling to convert existing templates.
LZ
On Wed, Jan 11, 2017 at 5:05 PM, Daniel Lobato Garcia
wrote:
> Hi foreman devs,
>
> Just noticed today
+1 for keeping the macros. IMHO, just because we did something a certain
way for a long time should not prevent us from changing it if there are
reasons for a change. This is also not the first change in core that
affected plugin(s) in a negative way and I doubt it will be the last.
Breaking
I'm with Marek on this one. Anything giving us more breathing space
is a good thing in the long run, even if the immediate effect might be a
bit negative.
A migration for community-templates would be nice though.
The mentioned REX issue was just a minor inconvenience. It just stopped the
tests
I don't think it causes any problems. I don't see the reason why the whole
commit should be reverted. If something then perhaps deprecation warning
could be removed. I'd still prefer communuty-templates using macros instead
of internal objects.
--
Marek
Odesláno pomocí AquaMail pro Android
Maybe the best thing to do for now it to revert it and send a PR to the RFC
repo for a proper discussion?
On Fri, Jan 13, 2017 at 2:26 PM, Daniel Lobato Garcia
wrote:
> On 01/12, Marek Hulán wrote:
> > >
> > > > I strongly disagree that this does not have big benefits.
On 01/12, Marek Hulán wrote:
> >
> > > I strongly disagree that this does not have big benefits. Using internal
> > > Foreman objects in templates is a bad practice. It blocks us from
> > > improving
> > > our code. Therefore it's very important to build a DSL that users can use
> > > in
On čtvrtek 12. ledna 2017 9:32:06 CET Stephen Benjamin wrote:
> - Original Message -
>
> > From: "Marek Hulán" <mhu...@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, January 12, 2017 2:59:39 AM
> > Subject: Re
> Also, the deprecation wasn't really smooth as it broke REX tests.
> http://ci.theforeman.org/job/test_plugin_matrix/2466/
One more note, REX was not broken by this, users were no affected. It's just
the test that checks "no warning was reported". The test tests something more
than it
On středa 11. ledna 2017 14:22:53 CET Stephen Benjamin wrote:
> - Original Message -
>
> > From: "Daniel Lobato Garcia" <elobat...@gmail.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Wednesday, January 11, 2017 11:05:39 AM
> > Subject
- Original Message -
> From: "Daniel Lobato Garcia" <elobat...@gmail.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, January 11, 2017 11:05:39 AM
> Subject: [foreman-dev] Revert removal of @host.params for host_param
>
> Hi foreman d
Hi foreman devs,
Just noticed today https://github.com/theforeman/foreman/pull/3983/files
after some comments on IRC. What's the background behind this change?
As far as I can see, this merely moves
@host.param to host_param
@host.param_true? to host_param_true?
@host.param_false? to
14 matches
Mail list logo