Hello,
what is our current plan with Ruby 4.0 support?
LZ
···
-- Later,Lukas “lzap” Zapletal
irc: lzap #theforeman
We will wait for 3.0 first, right 
With Rails 4.0, I don't know
– Ivan
···
----- Original Message ----- > Hello, > > what is our current plan with Ruby 4.0 support? > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > irc: lzap #theforeman > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >I'd say this it quite far off, as we're dependent on SCL on EL6. I'd
like to move to depending on the RHSCL child channel[1] (for RHEL
proper) and CentOS SCL[2] (for CentOS or other EL clones) rather than
having our own builds of pre-GA SCL, even if it means we're beholden to
these releases.
Once Rails 4 - already packaged in Fedora 20 - is available in an SCL
release, then I think we can do it.
[1]http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
[2]http://lists.centos.org/pipermail/centos-announce/2013-October/020000.html
···
On 05/11/13 10:37, Lukas Zapletal wrote: > Hello, > > what is our current plan with Ruby 4.0 support?–
Dominic Cleal
Red Hat Engineering
Jason's spent some time testing this, by pulling packages from RHSCL 1.0
(which RHEL users can enable with yum-config-manager --enable
rhel-server-rhscl-6-rpms) where available instead of our repo, and
Foreman runs fine. I've also tested CentOS 6.4 against their beta repo
linked above.
For implementing this, I think we should:
a) document the additional repo enable command for RHEL users (like we
do for the optional channel)
b) add a parameterised yumrepo resource to the installer that runs on EL
clones only to configure the CentOS SCL repo
c) document the CentOS SCL repo dep in the manual for package users
d) add ruby193-ruby-wrapper and stop shipping our builds
I don't want this to be burdensome for users, but I think it's better
than shipping identical packages ourselves if we can help it. We still
have the ability to provide newer versions as and when we need to.
Are those steps above enough to make it transparent for users?
···
On 05/11/13 12:15, Dominic Cleal wrote: > On 05/11/13 10:37, Lukas Zapletal wrote: >> Hello, >> >> what is our current plan with Ruby 4.0 support? > > I'd say this it quite far off, as we're dependent on SCL on EL6. I'd > like to move to depending on the RHSCL child channel[1] (for RHEL > proper) and CentOS SCL[2] (for CentOS or other EL clones) rather than > having our own builds of pre-GA SCL, even if it means we're beholden to > these releases. > [snip] > > [1]http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ > [2]http://lists.centos.org/pipermail/centos-announce/2013-October/020000.html–
Dominic Cleal
Red Hat Engineering
> >> Hello,
> >>
> >> what is our current plan with Ruby 4.0 support?
> >
> > I'd say this it quite far off, as we're dependent on SCL on EL6. I'd
> > like to move to depending on the RHSCL child channel[1] (for RHEL
> > proper) and CentOS SCL[2] (for CentOS or other EL clones) rather than
> > having our own builds of pre-GA SCL, even if it means we're beholden to
> > these releases.
> > [snip]
> >
> > [1]http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
> > [2]http://lists.centos.org/pipermail/centos-announce/2013-October/020000.html
>
> Jason's spent some time testing this, by pulling packages from RHSCL 1.0
> (which RHEL users can enable with yum-config-manager --enable
> rhel-server-rhscl-6-rpms) where available instead of our repo, and
> Foreman runs fine. I've also tested CentOS 6.4 against their beta repo
> linked above.
>
> For implementing this, I think we should:
>
> a) document the additional repo enable command for RHEL users (like we
> do for the optional channel)
> b) add a parameterised yumrepo resource to the installer that runs on EL
> clones only to configure the CentOS SCL repo
> c) document the CentOS SCL repo dep in the manual for package users
> d) add ruby193-ruby-wrapper and stop shipping our builds
>
> I don't want this to be burdensome for users, but I think it's better
> than shipping identical packages ourselves if we can help it. We still
> have the ability to provide newer versions as and when we need to.
+1
···
----- Original Message ----- > On 05/11/13 12:15, Dominic Cleal wrote: > > On 05/11/13 10:37, Lukas Zapletal wrote:Are those steps above enough to make it transparent for users?
–
Dominic Cleal
Red Hat Engineering–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Jason's spent some time testing this, by pulling packages from RHSCL 1.0
> (which RHEL users can enable with yum-config-manager --enable
> rhel-server-rhscl-6-rpms) where available instead of our repo, and
> Foreman runs fine. I've also tested CentOS 6.4 against their beta repo
> linked above.
Thank you so much for this effort. My dreams come true.
> a) document the additional repo enable command for RHEL users (like we
> do for the optional channel)
I was already thinking - isn't it's time for subscription-manager puppet
manifest?
Then we could make installation even easier + b) could be merged (we
detect if we on a clone or not).
#justanidea
> b) add a parameterised yumrepo resource to the installer that runs on EL
> clones only to configure the CentOS SCL repo
> c) document the CentOS SCL repo dep in the manual for package users
> d) add ruby193-ruby-wrapper and stop shipping our builds
Let's put this onto scrum! +1
···
On Fri, Dec 06, 2013 at 11:31:35AM +0000, Dominic Cleal wrote:–
Later,
Lukas “lzap” Zapletal
irc: lzap #theforeman
What would this be?
– bk
···
On 12/06/2013 08:33 AM, Lukas Zapletal wrote: > I was already thinking - isn't it's time for subscription-manager puppet > manifest?:-) > > Then we could make installation even easier + b) could be merged (we > detect if we on a clone or not). > > #justanideaPuppet resource that would allow you to:
- register system
- add/remove (optional) channels
- ?
LZ
···
On Fri, Dec 06, 2013 at 08:40:23AM -0500, Bryan Kearney wrote: > On 12/06/2013 08:33 AM, Lukas Zapletal wrote: > >I was already thinking - isn't it's time for subscription-manager puppet > >manifest?:-) > > > >Then we could make installation even easier + b) could be merged (we > >detect if we on a clone or not). > > > >#justanidea > What would this be? > -- bk > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.–
Later,
Lukas “lzap” Zapletal
irc: lzap #theforeman
> Puppet resource that would allow you to:
>
> - register system
> - add/remove (optional) channels
Makes tons of sense!
– Ivan
···
----- Original Message -----
- ?
LZ
On Fri, Dec 06, 2013 at 08:40:23AM -0500, Bryan Kearney wrote:
On 12/06/2013 08:33 AM, Lukas Zapletal wrote:
I was already thinking - isn’t it’s time for subscription-manager puppet
manifest?Then we could make installation even easier + b) could be merged (we
detect if we on a clone or not).#justanidea
What would this be?
– bk–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.–
Later,Lukas “lzap” Zapletal
irc: lzap #theforeman–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.