Hi,
quick summary about 1.17 branching status. The develop branch moved to
Rails 5 and turbolinks were added to tfm-ror51. Right now, the develop is
basically ready to move to Rails 5.1 by getting in [1]. When that is done,
there are packaging updates that need to be done - we need to update fog to
Hi,
as we are getting closer to 1.17 branching, I would like to ask for access
to Koji, because I will need to update build targets and configuration.
O.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop rec
by 2.4
> comes with JSON 2+.
>
> On Dec 7, 2017 7:02 AM, "Ondrej Prazak" wrote:
>
>> Hi,
>> this is a quick summary of current 1.17 branching status. As before, feel
>> free to correct/complete the information below.
>>
>> The new version of tur
Hi,
this is a quick summary of current 1.17 branching status. As before, feel
free to correct/complete the information below.
The new version of turbolinks-classic (2.5.4) was released about 12 hours
ago, and we work on adding it to tfm-ror51 [1].
Dynflowd deployment on Debian is almost ready to
+1 to the comments above, moving forward with React will allow us to drop
turbolinks at some point without a noticeable decrease in UI performance -
at least that is my hope.
On Wed, Dec 6, 2017 at 5:46 PM, Ohad Levy wrote:
>
>
> On Wed, Dec 6, 2017 at 5:10 PM, Walden Raines wrote:
>
>> I am se
+1 to both
On Wed, Dec 6, 2017 at 5:19 PM, Ivan Necas wrote:
> +2
>
> -- Ivan
>
> On Wed, 6 Dec 2017 at 16:51, Lukas Zapletal wrote:
>
>> +1 +1 beer time!
>>
>> LZ
>>
>> On Wed, Dec 6, 2017 at 1:40 PM, Tomer Brisker
>> wrote:
>> > Hello,
>> > As many of you may have noticed, foreman-core open
Hi,
this is a quick summary of where we currently stand with 1.17. Feel free to
correct/complete the information below.
Moving to Rails 5.1 is still the biggest task on our plate but we are
getting closer. Changes for the past week or so:
* more work done on tfm-ror51, scratch builds on PRs [1]
If having 2.0 means just a change in number because y is now just too high
to remember, then it does not matter if we pick 1.17, 1.18 or 1.19. I agree
that bumping the major number signals a significant and possibly breaking
changes to users and should not be done arbitrarily.
If we want 2.0 with s
Hi,
this is just a quick summary of where we stand with 1.17, please feel free
to correct me if I got something wrong.
foreman_selinux, smart-proxy, installer and modules have no blockers - at
least none that we know of.
Blockers for foreman are dynflow and Rails 5.1 as already stated previously
Hi,
I am sending this just to let you know that, according to the schedule, the
1.17 branching should happen in 2 weeks.
O.
--
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
Hi,
I think using a generally accepted style guide is a better approach than
creating our own from scratch. I would just like to point out that it does
not remove the challenges entirely as new versions of style guide are
released and new rules added, but that is just something we have to deal
with
Hi,
foreman_pipeline was already removed from packaging repo, I have no
objections against removing it from Redmine, Jenkins and Foreman org on
Github as it hasn't been updated in a year.
O.
On Tue, Nov 7, 2017 at 5:44 PM, Marek Hulán wrote:
> Hello there
>
> thanks to Tomer and Timo, we were a
+1 from me
On Mon, Nov 6, 2017 at 4:15 PM, Greg Sutcliffe
wrote:
> On 06/11/17 13:20, Eric D Helms wrote:
> > An important part I missed with the migration and initial proposal is
> > around maintainers. I am proposing that all katello-packagers be given
> > commit access to foreman-packaging as
Hi,
I would recommend writing a plugin. There are several plugins upstream that
add a new compute resource provider, so you can take a look at those to
find an inspiration [1]. We have a plugin template [2] that you can clone
and rename, so you do not have to start completely from scratch. We also
Hi,
based on the Redmine release dates [1], 1.17 is supposed to be branched on
December 1st. Do we want to stick to this plan or do we want to take into
account that 1.16 was delayed?
Let me know what you think,
Ondra
[1] http://projects.theforeman.org/rb/releases/foreman
--
You received this m
+1
On Mon, Oct 23, 2017 at 9:49 PM, Marek Hulan wrote:
> +1, I remember you've helped me many times.
>
> --
> Marek
>
>
>
> On October 23, 2017 6:16:48 PM Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
> Hello all,
>>
>> To get more involved in packaging I'd like to request
Hi,
I have put together [1], which could be a way.
O.
[1] https://github.com/theforeman/foreman/pull/4888
On Tue, Oct 10, 2017 at 5:09 PM, wrote:
> Hey everyone!
>
> We're ready to begin adding React pages to Katello. One of the challenges
> we face is adding the dependencies listed in Katell
lking about? Is this the container selinux
>>> installation issue?
>>>
>>> If there is a chance of sneaking in
>>>
>>> https://github.com/theforeman/foreman/pull/4555
>>>
>>> if this is merged in the deadline, that would be great. Pretty
>>
Hi,
there will be a 1.15.5 Foreman release. Main motivation behind this is to
get SELinux fixes into 1.15, but if you are aware of any critical fix that
should go in there, let me know.
Have a nice day,
Ondrej Prazak
--
You received this message because you are subscribed to the Google Groups
Definitely +1.
On Mon, Sep 25, 2017 at 2:48 PM, Greg Sutcliffe
wrote:
> On Mon, 2017-09-25 at 14:01 +0200, Ewoud Kohl van Wijngaarden wrote:
> > Hello all,
> >
> > To get more involved in foreman infra I'd like to request push access
> > to foreman-infra. At first I'd like to help more with the
what they offer - some support only image-based provisioning [2]. I do not
think using 'Bare metal' option to provision a VM will work as Foreman uses
compute resources to support various VM providers.
Kind Regards,
Ondrej Prazak
[1] https://github.com/mattwilmott/foreman-ovm
of whitelisting the params that we want to update. So if you add
new fields, you need to make sure they do not get filtered out.
Hope this helps,
Ondrej Prazak
[1]
https://github.com/theforeman/foreman/blob/develop/app/controllers/hostgroups_controller.rb#L42-L43
[2]
https://github.com/theforeman/
+1 from me
On Mon, Jun 26, 2017 at 3:16 AM, Tom McKay wrote:
> +1 for @ehelms
>
> On Fri, Jun 23, 2017 at 9:05 AM, Neil Hanlon wrote:
>
>> +1 from me :)
>>
>> On Fri, Jun 23, 2017 at 8:44 AM Greg Sutcliffe
>> wrote:
>>
>>> Hi all,
>>>
>>> Slightly different to our usual "nominate a new commite
+1
On Mon, Apr 24, 2017 at 4:23 PM, Stephen Benjamin
wrote:
> +1, see other comments below
>
>
> On Mon, Apr 24, 2017 at 8:47 AM, Tomer Brisker
> wrote:
> > +1
> >
> > On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán wrote:
> >>
> >> Hello devs,
> >>
> >> based on our handbook [1]. I'd like to nom
On Tue, Jan 17, 2017 at 12:08 PM, Tomas Strachota
wrote:
> On Mon, Jan 16, 2017 at 6:55 PM, oprazak wrote:
> > Hi,
> > I recently started identifying problematic areas in Permissions and
> Roles,
> > especially with regard to plugins. Foreman provides 'Viewer' and
> 'Manager'
> > roles out of th
+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 plugin
26 matches
Mail list logo