Re: [foreman-dev] Found In Version Katello Redmine custom field

2017-10-18 Thread Marek Hulan 
I would love to see the issue template, especially the reproducing steps 
would help. Also installed plugins would help in some cases.


--
Marek


On October 18, 2017 21:01:06 Justin Sherrill  wrote:


I like this idea, and there seems to be a plugin already to do it:
http://www.redmine.org/plugins/redmine_issue_templates


On 10/18/2017 02:55 PM, Tom McKay wrote:

Perhaps using a template for new issues. Here is an example from github:
https://github.com/openshift/origin/issues/new

[provide a description of the issue]

# Version
[provide output of the `openshift version` or `oc version` command]

# Steps To Reproduce
1. [step 1]
2. [step 2]

# Current Result

# Expected Result

# Additional Information
[try to run `$ oc adm diagnostics` (or `oadm diagnostics`) command if
possible]
[if you are reporting issue related to builds, provide build logs with
`BUILD_LOGLEVEL=5`]
[consider attaching output of the `$ oc get all -o json -n
` command to the issue]
[visit https://docs.openshift.org/latest/welcome/index.html]


On Mon, Oct 16, 2017 at 1:47 PM, Ewoud Kohl van Wijngaarden
mailto:ew...@kohlvanwijngaarden.nl>> wrote:

https://projects.theforeman.org/projects/foreman/issues/new
 has
this, but I'm not sure we can rename the Release field since it's
part of the Redmine Backlogs plugin though my memory is fuzzy
here. I think someone with admin rights on Redmine can say more
about the practicalities but the idea makes a lot of sense to me.

On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:

+1

If we do this, we should clarify that the current "version"
field is used
for releases by calling it "target version" or something similar.

John Mitsch
Red Hat Engineering
(860)-967-7285 
irc: jomitsch

On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink
mailto:akof...@redhat.com>> wrote:

RFC:

Because Katello is a nested project under Foreman in
Redmine, we can only
see Foreman versions in the "version" field. It would be
great to have a
custom text box field "Found In Version" that bug
reporters can provide the
exact RPM they installed to see the issue.

Let me know if you would find this useful.


--
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+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
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+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
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+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Vendorizing or Building RPMs

2017-10-18 Thread Eric D Helms 
On Wed, Oct 18, 2017 at 3:01 PM, Michael Moll  wrote:

> hi,
>
> On Tue, Oct 17, 2017 at 03:42:50PM -0700, Dmitri Dolguikh wrote:
> > >2) Vendorize Rails and thirdparty gems into a one or more base RPMs
> > > (e.g. an RPM for rails stack and one for thirdparty dependencies)
> >
> > Not sure if this has already been considered: use bundler to package the
> > app. In this case all dependencies, including rails will be cached
> locally,
> > and we could then wrap the result into an rpm. Not sure how plugins would
> > fit into this though.
>
> I'm not 100% sure if you meant it like that, but basically this is what
> we're doing in the current DEB approach. The "foreman" package is the
> result of "bundle package", the subpackages drop in a file or two each
> into bundler.d/ and a plugin package is its gem (and if needed,
> dependent gems) to add into the current bundle and precompiled assets.
>

How do the plugins isolate their dependent gems? i.e. is it a script or
build tool or just knowledge to grab the right gems and pop them in?


>
> Regards
> --
> Michael Moll
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Eric D. Helms
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Current State of Nightlies

2017-10-18 Thread Eric D Helms 
Nightlies are back to green.

On Wed, Oct 18, 2017 at 9:50 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> And https://github.com/theforeman/foreman-packaging/pull/1869 should fix
> the other issue.
>
>
> On Wed, Oct 18, 2017 at 02:24:19PM +0200, Ewoud Kohl van Wijngaarden wrote:
>
>> Agreed. https://github.com/theforeman/foreman-packaging/pull/1866
>>
>> On Tue, Oct 17, 2017 at 09:16:52AM +0200, Lukas Zapletal wrote:
>>
>>> EPEL is not great place to be for Rails or Node components. You should
>>> not bump versions in EPEL7 (major relase should go into EPEL8).
>>>
>>> On Tue, Oct 17, 2017 at 12:01 AM, Eric D Helms 
>>> wrote:
>>>


 On Oct 16, 2017 5:17 PM, "Sean O'Keeffe"  wrote:

 Why dont we ask the maintainer to pkg a new version or someone offer to
 become a co-maintainer and get a new version into EPEL ?


 While I think this is the right open source path, I'd weigh:

  1) how long will nighties be broken waiting on a new package?
  2) 2.0 to 4.1 is a large jump and as a base dependency other EPEL
 packages
 may not work.



 On Mon, Oct 16, 2017 at 9:31 PM, Ewoud Kohl van Wijngaarden
  wrote:

>
> On Mon, Oct 16, 2017 at 04:18:53PM -0400, Eric D Helms wrote:
>
>>
>> Nightly RPM and tests have been broken for around 2 weeks now. This
>> morning
>> a bit of a regression was merged to foreman core to fix the breaking
>> RPM
>> aspect and I can report that nightly RPMs are now building. However,
>> this
>> leads to a breakage in plugin asset usage with the newer React
>> components.
>> To potentially address this I have opened [1] for testing and input.
>> As
>> part of the original breakage, I added to test_develop running npm
>> install
>> and webpack compile the same way our RPMs do in order to catch these
>> sort
>> of issues earlier.
>>
>
>
> Thanks for this!
>
> The second half is that after RPMs were built, repoclosure on the test
>> pipeline is currently failing [2]. The highlight being:
>>
>> *20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
>> undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
>> *20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
>> npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0
>>
>>
>>
>> nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we
>> will
>> need to add both of these as top level packages carried in
>> foreman-packaging. Can anyone confirm or deny that is how this should
>> be
>> working? Or should another package we build be providing these?
>>
>
>
> I do believe we need to package this ourselves since we need a newer
> version than in EPEL.
>
> [1] https://github.com/theforeman/foreman/pull/4924
>> [2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console
>>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Eric D. Helms
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Vendorizing or Building RPMs

2017-10-18 Thread Michael Moll 
hi,

On Tue, Oct 17, 2017 at 03:42:50PM -0700, Dmitri Dolguikh wrote:
> >2) Vendorize Rails and thirdparty gems into a one or more base RPMs
> > (e.g. an RPM for rails stack and one for thirdparty dependencies)
> 
> Not sure if this has already been considered: use bundler to package the
> app. In this case all dependencies, including rails will be cached locally,
> and we could then wrap the result into an rpm. Not sure how plugins would
> fit into this though.

I'm not 100% sure if you meant it like that, but basically this is what
we're doing in the current DEB approach. The "foreman" package is the
result of "bundle package", the subpackages drop in a file or two each
into bundler.d/ and a plugin package is its gem (and if needed,
dependent gems) to add into the current bundle and precompiled assets.

Regards
-- 
Michael Moll

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Found In Version Katello Redmine custom field

2017-10-18 Thread Justin Sherrill 
I like this idea, and there seems to be a plugin already to do it: 
http://www.redmine.org/plugins/redmine_issue_templates



On 10/18/2017 02:55 PM, Tom McKay wrote:

Perhaps using a template for new issues. Here is an example from github:
https://github.com/openshift/origin/issues/new

[provide a description of the issue]

# Version
[provide output of the `openshift version` or `oc version` command]

# Steps To Reproduce
1. [step 1]
2. [step 2]

# Current Result

# Expected Result

# Additional Information
[try to run `$ oc adm diagnostics` (or `oadm diagnostics`) command if 
possible]
[if you are reporting issue related to builds, provide build logs with 
`BUILD_LOGLEVEL=5`]
[consider attaching output of the `$ oc get all -o json -n 
` command to the issue]

[visit https://docs.openshift.org/latest/welcome/index.html]


On Mon, Oct 16, 2017 at 1:47 PM, Ewoud Kohl van Wijngaarden 
mailto:ew...@kohlvanwijngaarden.nl>> wrote:


https://projects.theforeman.org/projects/foreman/issues/new
 has
this, but I'm not sure we can rename the Release field since it's
part of the Redmine Backlogs plugin though my memory is fuzzy
here. I think someone with admin rights on Redmine can say more
about the practicalities but the idea makes a lot of sense to me.

On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:

+1

If we do this, we should clarify that the current "version"
field is used
for releases by calling it "target version" or something similar.

John Mitsch
Red Hat Engineering
(860)-967-7285 
irc: jomitsch

On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink
mailto:akof...@redhat.com>> wrote:

RFC:

Because Katello is a nested project under Foreman in
Redmine, we can only
see Foreman versions in the "version" field. It would be
great to have a
custom text box field "Found In Version" that bug
reporters can provide the
exact RPM they installed to see the issue.

Let me know if you would find this useful.


-- 
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+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
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+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Found In Version Katello Redmine custom field

2017-10-18 Thread Tom McKay 
Perhaps using a template for new issues. Here is an example from github:
https://github.com/openshift/origin/issues/new

[provide a description of the issue]

# Version
[provide output of the `openshift version` or `oc version` command]

# Steps To Reproduce
1. [step 1]
2. [step 2]

# Current Result

# Expected Result

# Additional Information
[try to run `$ oc adm diagnostics` (or `oadm diagnostics`) command if
possible]
[if you are reporting issue related to builds, provide build logs with
`BUILD_LOGLEVEL=5`]
[consider attaching output of the `$ oc get all -o json -n `
command to the issue]
[visit https://docs.openshift.org/latest/welcome/index.html]


On Mon, Oct 16, 2017 at 1:47 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> https://projects.theforeman.org/projects/foreman/issues/new has this, but
> I'm not sure we can rename the Release field since it's part of the Redmine
> Backlogs plugin though my memory is fuzzy here. I think someone with admin
> rights on Redmine can say more about the practicalities but the idea makes
> a lot of sense to me.
>
> On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:
>
>> +1
>>
>> If we do this, we should clarify that the current "version" field is used
>> for releases by calling it "target version" or something similar.
>>
>> John Mitsch
>> Red Hat Engineering
>> (860)-967-7285
>> irc: jomitsch
>>
>> On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink 
>> wrote:
>>
>> RFC:
>>>
>>> Because Katello is a nested project under Foreman in Redmine, we can only
>>> see Foreman versions in the "version" field. It would be great to have a
>>> custom text box field "Found In Version" that bug reporters can provide
>>> the
>>> exact RPM they installed to see the issue.
>>>
>>> Let me know if you would find this useful.
>>>
>>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Current State of Nightlies

2017-10-18 Thread Ewoud Kohl van Wijngaarden 
And https://github.com/theforeman/foreman-packaging/pull/1869 should fix 
the other issue.


On Wed, Oct 18, 2017 at 02:24:19PM +0200, Ewoud Kohl van Wijngaarden wrote:

Agreed. https://github.com/theforeman/foreman-packaging/pull/1866

On Tue, Oct 17, 2017 at 09:16:52AM +0200, Lukas Zapletal wrote:

EPEL is not great place to be for Rails or Node components. You should
not bump versions in EPEL7 (major relase should go into EPEL8).

On Tue, Oct 17, 2017 at 12:01 AM, Eric D Helms  wrote:



On Oct 16, 2017 5:17 PM, "Sean O'Keeffe"  wrote:

Why dont we ask the maintainer to pkg a new version or someone offer to
become a co-maintainer and get a new version into EPEL ?


While I think this is the right open source path, I'd weigh:

 1) how long will nighties be broken waiting on a new package?
 2) 2.0 to 4.1 is a large jump and as a base dependency other EPEL packages
may not work.



On Mon, Oct 16, 2017 at 9:31 PM, Ewoud Kohl van Wijngaarden
 wrote:


On Mon, Oct 16, 2017 at 04:18:53PM -0400, Eric D Helms wrote:


Nightly RPM and tests have been broken for around 2 weeks now. This
morning
a bit of a regression was merged to foreman core to fix the breaking RPM
aspect and I can report that nightly RPMs are now building. However, this
leads to a breakage in plugin asset usage with the newer React
components.
To potentially address this I have opened [1] for testing and input. As
part of the original breakage, I added to test_develop running npm
install
and webpack compile the same way our RPMs do in order to catch these sort
of issues earlier.



Thanks for this!


The second half is that after RPMs were built, repoclosure on the test
pipeline is currently failing [2]. The highlight being:

*20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
*20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0



nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we will
need to add both of these as top level packages carried in
foreman-packaging. Can anyone confirm or deny that is how this should be
working? Or should another package we build be providing these?



I do believe we need to package this ourselves since we need a newer
version than in EPEL.


[1] https://github.com/theforeman/foreman/pull/4924
[2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console


--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Place to put slide decks

2017-10-18 Thread Greg Sutcliffe 
I've been thinking the same thing. I was about to add them to the
foreman-graphics repo, since that's the closest thing to a media-store
we have. I'm happy to take PRs :)

Greg

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Current State of Nightlies

2017-10-18 Thread Ewoud Kohl van Wijngaarden 

Agreed. https://github.com/theforeman/foreman-packaging/pull/1866

On Tue, Oct 17, 2017 at 09:16:52AM +0200, Lukas Zapletal wrote:

EPEL is not great place to be for Rails or Node components. You should
not bump versions in EPEL7 (major relase should go into EPEL8).

On Tue, Oct 17, 2017 at 12:01 AM, Eric D Helms  wrote:



On Oct 16, 2017 5:17 PM, "Sean O'Keeffe"  wrote:

Why dont we ask the maintainer to pkg a new version or someone offer to
become a co-maintainer and get a new version into EPEL ?


While I think this is the right open source path, I'd weigh:

  1) how long will nighties be broken waiting on a new package?
  2) 2.0 to 4.1 is a large jump and as a base dependency other EPEL packages
may not work.



On Mon, Oct 16, 2017 at 9:31 PM, Ewoud Kohl van Wijngaarden
 wrote:


On Mon, Oct 16, 2017 at 04:18:53PM -0400, Eric D Helms wrote:


Nightly RPM and tests have been broken for around 2 weeks now. This
morning
a bit of a regression was merged to foreman core to fix the breaking RPM
aspect and I can report that nightly RPMs are now building. However, this
leads to a breakage in plugin asset usage with the newer React
components.
To potentially address this I have opened [1] for testing and input. As
part of the original breakage, I added to test_develop running npm
install
and webpack compile the same way our RPMs do in order to catch these sort
of issues earlier.



Thanks for this!


The second half is that after RPMs were built, repoclosure on the test
pipeline is currently failing [2]. The highlight being:

*20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
*20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0



nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we will
need to add both of these as top level packages carried in
foreman-packaging. Can anyone confirm or deny that is how this should be
working? Or should another package we build be providing these?



I do believe we need to package this ourselves since we need a newer
version than in EPEL.


[1] https://github.com/theforeman/foreman/pull/4924
[2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console


--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Vendorizing or Building RPMs

2017-10-18 Thread Ivan Necas 
On Wed, Oct 18, 2017 at 1:46 AM, Eric D Helms  wrote:
> Plugins do present the most complicated part of this process given they
> would each potentially be requiring a few independent gems separate from the
> core stack and we would not want bloat. Seems we'd need either:
>
>  1) a single gem stack that plugins contribute to and is renegenrated with
> all them enabled
>  2) a method for plugins to generate the bundle install, and pick out just
> the gems they need to contribute on top of the core stack

The disadvantage of 2) comes, when there are two plugins, that both need
the same dependency, that is not in the core and using both plugins can
lead to version collisions (we've seen that in the deb packaging every
now and then).
Although, having multiple versions of gems usually is not that much of
a big deal, as long as they are compatible with the plugins, it's
seems a bit weird
that the specific versions being used would depend on the specific plugins
being installed.

The disadvantage of the the single plugins gem stack is, that update of
any dependency there means that the end user needs to re-download the
whole bundle
again. This is probably not issue for most of the dependencies, that
we don't update that
often (the part of the stack). But there are gems, such as Dynflow,
that are more
related to the code and it would be beneficial to have an ability to
deliver new versions
asynchronously. Thinking about it a bit more, we usually need the fast
updates in
nightlies, where it's probably not much of a deal for the end user, and having
the gem stack rpm updated with every upstream release seems like it could work.

There would be still possibility for any plugin, to bring in their own
dependency,
that would not be in the common stack, if needed,  but the recommended
would be to get into the Foreman ecosystem to get the deps into the
common stack.

So for now, 1) is winning for me. This might be also an entry-point for testing
the plugins together.

Another potential move could be tackling how the
plugins are getting enable in the first place. If the bits and pieces
for all the plugins
would be available every time, than the act of installing a plugin would
be just about enabling loading the corresponding gem (as opposed for
need to installing
it first). It would make it also easier to make the plugins
discoverable: there is of course
more work to be done for making that working, but just exploring what
it might mean.

It's also good to thing about how that could influence the
containerization work. We could
still build the containers at the end-user side, with a subset of
plugins installed, but
with the all-plugins bundle, we could distribute the images themselves.

There would be additional requirement on the plugin developers to sync
even more with
the core releases, but I think it's a good thing.

-- Ivan

>
> On Tue, Oct 17, 2017 at 6:42 PM, Dmitri Dolguikh 
> wrote:
>>
>> > Today we package all required rubygems as RPMs and utilize a thirdparty
>> > Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack
>> > (sclo-ror42). The team that manages the RHSCLs has already released Ruby
>> > 2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no
>> > plans to release any further SCLs for the Rails stack. This means, in
>> > addition to our own dependencies, we need to build and manage the Rails
>> > stack for the versions we want. This adds more packaging burden on the
>> > RPM
>> > side. GIven this, we have a few options:
>> >
>> >1) Build and manage our own SCLs for every version of Rails from here
>> > on
>> > out
>> >2) Vendorize Rails and thirdparty gems into a one or more base RPMs
>> > (e.g. an RPM for rails stack and one for thirdparty dependencies)
>>
>> Not sure if this has already been considered: use bundler to package the
>> app. In this case all dependencies, including rails will be cached locally,
>> and we could then wrap the result into an rpm. Not sure how plugins would
>> fit into this though.
>>
>> -d
>>
>> On Tue, Oct 17, 2017 at 11:17 AM, Bryan Kearney 
>> wrote:
>>>
>>> On 10/16/2017 04:36 AM, Michael Moll wrote:
>>> > I don't really have stakes in RPMs, but I'd try to stick with option 1
>>> > and I even expect that there's some demand for Rails SCLs at least in
>>> > the RHEL/CentOS world by other projects, too.
>>> >
>>> > Regards
>>>
>>> I would suggest the decision be made based on the assumption that the
>>> foreman community owns all the work for options 1 and 2. I have no
>>> special instights, but I would hate to assume we could package based on
>>> another communities work. Assume this commuity owns it all, which way is
>>> better/easier/quicker/less error prone.
>>>
>>> -- 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+unsubscr...@googlegroups.com.
>>> For mor