Re: [foreman-dev] bringing pulp-2.10 into katello

[Tom McKay]

On Wed, Aug 24, 2016 at 5:58 PM, Justin Sherrill 
wrote:

> On 08/24/2016 05:48 PM, Tom McKay wrote:
>
>
>
> On Wed, Aug 24, 2016 at 5:36 PM, Chris Duryee  wrote:
>
>>
>>
>> On 08/24/2016 05:33 PM, Tom McKay wrote:
>> > Katello and foreman are nearing dev freeze in early September but there
>> are
>> > a few features centered around Atomic Host and Atomic Registry that will
>> > need changes introduced in pulp-2.10. While I understand pulp-2.10 is
>> > currently still in beta, I was hoping we could bring it into katello now
>> > ahead of dev freeze so the dependent integration could be completed.
>> >
>> > If we did bring in pulp-2.10, it would have to be with the understanding
>> > that breakages on both sides would need to be fixed prior to katello
>> > releasing. I know this is usually how things go anyways but I just
>> wanted
>> > to state it up front.
>> >
>> > Also, are there resources to do this work? If I understand things
>> > correctly, it's not just as simple as updating a repo file to point to
>> > pulp-2.10, but that changes to runcible would also need to be made? Is
>> this
>> > something that could be done ASAP? Sooner means more time to shake out
>> > issues.
>>
>> 2.10 should have additive-only changes from 2.9, I don't think runcible
>> would change unless it was to support something new in 2.10.
>>
>
> We would be passing username/password for docker registries w/
> authentication. Not sure if there are other changes too, @partha?
>
>
> Generally when pulling in a new pulp release, we only initially introduce
> changes required to maintain existing functionality.  New functionality is
> added after that is done in one or more PRs.
>
>
Of course, so yes @beav is correct.


>
>
>> >
>> > Thoughts?
>> >
>>
>> --
>> 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] bringing pulp-2.10 into katello

[Justin Sherrill]

On 08/24/2016 05:48 PM, Tom McKay wrote:



On Wed, Aug 24, 2016 at 5:36 PM, Chris Duryee > wrote:




On 08/24/2016 05:33 PM, Tom McKay wrote:
> Katello and foreman are nearing dev freeze in early September
but there are
> a few features centered around Atomic Host and Atomic Registry
that will
> need changes introduced in pulp-2.10. While I understand
pulp-2.10 is
> currently still in beta, I was hoping we could bring it into
katello now
> ahead of dev freeze so the dependent integration could be completed.
>
> If we did bring in pulp-2.10, it would have to be with the
understanding
> that breakages on both sides would need to be fixed prior to katello
> releasing. I know this is usually how things go anyways but I
just wanted
> to state it up front.
>
> Also, are there resources to do this work? If I understand things
> correctly, it's not just as simple as updating a repo file to
point to
> pulp-2.10, but that changes to runcible would also need to be
made? Is this
> something that could be done ASAP? Sooner means more time to
shake out
> issues.

2.10 should have additive-only changes from 2.9, I don't think
runcible
would change unless it was to support something new in 2.10.


We would be passing username/password for docker registries w/ 
authentication. Not sure if there are other changes too, @partha?


Generally when pulling in a new pulp release, we only initially 
introduce changes required to maintain existing functionality.  New 
functionality is added after that is done in one or more PRs.





>
> Thoughts?
>

--
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] bringing pulp-2.10 into katello

[Chris Duryee]

On 08/24/2016 05:33 PM, Tom McKay wrote:
> Katello and foreman are nearing dev freeze in early September but there are
> a few features centered around Atomic Host and Atomic Registry that will
> need changes introduced in pulp-2.10. While I understand pulp-2.10 is
> currently still in beta, I was hoping we could bring it into katello now
> ahead of dev freeze so the dependent integration could be completed.
> 
> If we did bring in pulp-2.10, it would have to be with the understanding
> that breakages on both sides would need to be fixed prior to katello
> releasing. I know this is usually how things go anyways but I just wanted
> to state it up front.
> 
> Also, are there resources to do this work? If I understand things
> correctly, it's not just as simple as updating a repo file to point to
> pulp-2.10, but that changes to runcible would also need to be made? Is this
> something that could be done ASAP? Sooner means more time to shake out
> issues.

2.10 should have additive-only changes from 2.9, I don't think runcible
would change unless it was to support something new in 2.10.

> 
> Thoughts?
> 

-- 
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] Using tmpfs significantly reduces testing time

[Lukas Zapletal]

> I would suggest even considering moving the entire /var/lib dir to tmpfs
> instead of on disk so the other DBs will get a boost - assuming the
> /var/lib dir is created anyways only for the worker's lifetime and
> destroyed afterwards.

That's perhaps too much. But fine tuning PostgreSQL and MySQL instances
could help a lot (giving up some atomicity or consistency in the storage
subsystem).

-- 
Later,
 Lukas #lzap Zapletal

-- 
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] Using tmpfs significantly reduces testing time

[Lukas Zapletal]

Please file a PR so we can compare speedup on Jenkins and discuss
details.

LZ

On Wed, Aug 24, 2016 at 02:35:21AM -0700, Shimon Shtein wrote:
> 
> I have ext4 for my home and tmpfs for /tmp.
> I haven't tried your solution (symlink), but if you say it's pretty much 
> the same as in-memory, I will surely switch to it.
> 
> 
> On Wednesday, August 24, 2016 at 12:10:05 PM UTC+3, Lukas Zapletal wrote:
> >
> > > It would be nice to see the differences. 
> >
> > It's almost the same speedup as with symlink (the difference is loading 
> > the database three times perhaps): 
> >
> > real13m32.018s 
> > user11m13.229s 
> > sys 0m12.004s 
> >
> > What is your file system? That might do the difference. 
> >
> > -- 
> > Later, 
> >  Lukas #lzap Zapletal 
> >
> 
> -- 
> 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.


-- 
Later,
 Lukas #lzap Zapletal

-- 
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] Hash rocket syntax

[David Davis]

I was thinking about responding to the items in your email but I feel like
I’ve put enough time into this discussion already. Just some general
thoughts.

I think you’re mischaracterizing my argument. I am not arguing that we
enable all cops. In fact, in the dynflow case I tried to open a PR with
just white spacing checking enabled but closed it out after it got out of
sync and had no activity:

https://github.com/Dynflow/dynflow/pull/169

To your point about disabling rubocop per instance, I’m sure that reduces
readability. I guess that’s subjective.

And we did have discussions on foreman-dev about which cops to
enable/disable. We even had a poll. The resulting PR reached an impasse
though even though we had reached a consensus on foreman-dev.


David

On Wed, Aug 24, 2016 at 7:41 AM, Ivan Necas  wrote:

> On Wed, Aug 24, 2016 at 10:49 AM, Marek Hulán  wrote:
> > Few more comments below
> >
> >> What do you mean by "Foreman dev"?
> >
> > You, me, everyone who contributed to Foreman.
> >
> >> I’ve contributed to both foreman and
> >> rubocop several times. Having worked on rubocop with all its cops
> enabled
> >> hasn’t been a deterrent to me even though I don’t necessarily agree with
> >> all cops.
> >
> > Seems rubocop devs are happy with more cops than at least one foreman
> dev is
> > (me). That make sense, otherwise they would not contribute to rubocop I
> guess
> > :-)
> >
> >> I’m not disagreeing with you. But I still have nightmares about the
> dynflow
> >> source code which had no rubocop checking at all and featured a number
> of
> >> obscure ruby syntaxes that rubocop would have forbid.
>
> I'm sorry, but this seem like a straw man argument to me. I agree with
> what Marek said.
> The think with the obscure syntax a little to do with Rubocop,
> but rather using the Algebrick gem. We gave it a try, it didn't work,
> we will remove eventually.
> Nothing to do with Rubocop. I'm not saying Dynflow would not benefit
> from Rubocop.
> And once more prio things get sorted out, we will finish that. I would
> not enable all cops
> though.
>
> I think we got quite far from the Hash rocket topic, just my last
> comment on Rubocop
> in general. What I see here is people saying "the more Rubocop" = "the
> more consistency"
> = "the more readable code". I don't agree with this reasoning. Yes,
> some cops increases
> the consistency, but it can just lead to your code to be consistently
> unreadable. And some cops
> have nothing to do with consistency.
>
> Let's take few examples from the Rubocop source code itself:
>
>   https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/
> rubocop/config.rb#L243
> - multi-line modifier statement - I hope nobody here would argue
> for this being more readable
> then standard if
>
>   https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/
> rubocop/config_loader.rb#L74
> - combination of modifier and non-modifier if: if you tried to put
> everything into non-modifier form,
>   it would tell you that you should use the modifier one (I
> tried:), which would eventually lead you
>   to the same case as previous one
>
>   https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/config.rb
>  - IMO the 80 lines limit just makes too many lines spread across
> more lines, making it harder to read;
>ok, I know some people us vim in split on lower resolution, but
> I don't think others and the readability
>should suffer from that: I would take the max line size from
> what actually helps the readability, not
>what resolution somebody has, otherwise, I would just argue
> that we need max 50 lines, to make it
>easier for me to review the code on my phone.
>
>https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/cli.rb#L5
>   - the comment says "The CLI is a class responsible of handling
> all the command line interface logic"
>   - while it was true when the class was added few years ago, it's
> no more valid that it's responsible
> for handling *all* of the logic, because the option parser is
> in separate class now.
>   - I would say the comment was just useless at the first place,
> and got obsolete (as comments
> use to) and the only reason people add it there is the policy.
>   - also, from personal experience with Rubocop documentation, I
> would not say it helped anyhow,
> I feel the pain every time I try to find what some cop expects
> or how to disable that, I end up
> looking at rubocop tests anyway usually.
>
> What I think is happening is people relying on Rubocop keeping their
> code readable
> and not paying any attention to it. And some cops make it also harder
> to improve the readability,
> (I know you can always disable the the cop per line, but I would say
> that already affects
> the readability in a bad way).
>
> I know that it might be frustrating for someone to discuss the styling
> between
> the developers, 

Re: [foreman-dev] Hash rocket syntax

[David Davis]

On Wed, Aug 24, 2016 at 4:49 AM, Marek Hulán  wrote:

> Few more comments below
>
> > What do you mean by "Foreman dev"?
>
> You, me, everyone who contributed to Foreman.
>

So then your statement about not one foreman dev being a rubocop
contributor is incorrect, right?



>
> > I’ve contributed to both foreman and
> > rubocop several times. Having worked on rubocop with all its cops enabled
> > hasn’t been a deterrent to me even though I don’t necessarily agree with
> > all cops.
>
> Seems rubocop devs are happy with more cops than at least one foreman dev
> is
> (me). That make sense, otherwise they would not contribute to rubocop I
> guess
> :-)
>
> > I’m not disagreeing with you. But I still have nightmares about the
> dynflow
> > source code which had no rubocop checking at all and featured a number of
> > obscure ruby syntaxes that rubocop would have forbid.
>
> If dynflow was foreman core project and was reviewed in that way from the
> first
> commit, this would not happen. Rubocop would not help too much. I tried to
> run
> rubocop on dynflow. From 1346 offenses I found only 22 regarding the
> obscure
> syntax, rest is "redundant return", "1.9 hash syntax", "top level class
> documentation missing" stuff. If you want to reproduce, see [1].
>
>
You’re grepping for lambda and only checking for a handful of lambda cops.
What about cops like MethodCallParentheses, MultilineIfThen, etc? Even some
of the cops like SpaceAroundOperators would have prevented stuff like “=->”.

I would hope that all foreman and foreman-related projects would have some
level of rubocop checking even if it’s just basic stuff like whitespace (I
tried to do this for dynflow but closed my PR out after it had conflicts
and no activity).



> This thread started around has rocket syntax. So to remain on topic, I
> don't
> think that the fact there is a cop for enforcing one hash syntax, it's
> widely
> accepted among Ruby devs. Speaking of hash rockets, an example might be
> github
> style guide - https://github.com/styleguide/ruby/hashes


That’s not true. The HashSyntax cop can be used to check for hash rockets:
https://git.io/v67yi

My vote is not to enforce hash syntax—let developers choose whether to use
1.9 vs hash rockets.

Also, I am not a huge fan of Github’s style guide since it has some weird
things like using TomDoc: https://github.com/styleguide/ruby/documentation


>
>
> [1] https://gist.github.com/ares/ff6e8b19361148e2be17290f1167c7c4
>
> --
> Marek
>
> > I think there’s probably a happy medium between not using rubocop and
> > enabling all rubocop cops.
> >
> >
> > David
> >
> > On Tue, Aug 23, 2016 at 11:22 AM, Marek Hulán  wrote:
> > > On Tuesday 23 of August 2016 07:47:31 David Davis wrote:
> > > > The plugins may not have as many contributors as foreman core but
> > > > rubocop
> > > > has more contributors (279 vs 200 for foreman) and they have pretty
> much
> > > > all cops enabled. It’s only been around for 3 years (vs 7 years for
> > > > foreman) so it doesn’t seem to be a deterrent to community
> > > > contributions.
> > >
> > > I don't think this is fair comparison. Do you think that 279
> contributors
> > > of
> > > one project represent all Ruby devs or all Foreman devs? At least not
> one
> > > Foreman dev, that's for sure. I don't say we should disable rubocop
> but I
> > > don't think all devs are happy with all cops. Adding cops like hash
> rocket
> > > makes it only worse.
> > >
> > > --
> > > Marek
> > >
> > > > I’d probably wager that most experienced Ruby developers are aware of
> > > > rubocop and the ruby community style guide [1]. For unexperienced
> Ruby
> > > > developers, I think they are a great way to learn good Ruby coding
> > > > standards.
> > > >
> > > > That said, I agree it would be nice to get opinions of community
> members
> > > > who contribute to foreman and their experiences with rubocop.
> > > >
> > > > [1] https://github.com/bbatsov/ruby-style-guide
> > > >
> > > >
> > > > David
> > > >
> > > > On Tue, Aug 23, 2016 at 3:48 AM, Marek Hulán 
> wrote:
> > > > > I'm with Lukas, we already enforce too many things without clear
> > >
> > > benefit.
> > >
> > > > > Let's
> > > > > keep both ways accepted which is default for all rubyists.
> > > > >
> > > > > > > I think we implemented Rubocop far beyond what's reasonable
> point.
> > >
> > > It
> > >
> > > > > > > make sense for dangerous constructs, but not in this case (and
> few
> > > > > > > others).
> > > > >
> > > > > +1, since rubocop leads to bike-shedding and annoyed devs from both
> > >
> > > sides
> > >
> > > > > I
> > > > > don't think it's a good idea to introduce more cops.
> > > > >
> > > > > > I'd argue the opposite, in foreman_docker or foreman_ansible I
> think
> > > > > > rubocop (with *all* cops enabled) helped maintain good coding
> > >
> > > standards
> > >
> > > > > > immensely and making the project *much easier* to read and get
> used
> > >
> > > 

Re: [foreman-dev] Hash rocket syntax

[Ivan Necas]

On Wed, Aug 24, 2016 at 10:49 AM, Marek Hulán  wrote:
> Few more comments below
>
>> What do you mean by "Foreman dev"?
>
> You, me, everyone who contributed to Foreman.
>
>> I’ve contributed to both foreman and
>> rubocop several times. Having worked on rubocop with all its cops enabled
>> hasn’t been a deterrent to me even though I don’t necessarily agree with
>> all cops.
>
> Seems rubocop devs are happy with more cops than at least one foreman dev is
> (me). That make sense, otherwise they would not contribute to rubocop I guess
> :-)
>
>> I’m not disagreeing with you. But I still have nightmares about the dynflow
>> source code which had no rubocop checking at all and featured a number of
>> obscure ruby syntaxes that rubocop would have forbid.

I'm sorry, but this seem like a straw man argument to me. I agree with
what Marek said.
The think with the obscure syntax a little to do with Rubocop,
but rather using the Algebrick gem. We gave it a try, it didn't work,
we will remove eventually.
Nothing to do with Rubocop. I'm not saying Dynflow would not benefit
from Rubocop.
And once more prio things get sorted out, we will finish that. I would
not enable all cops
though.

I think we got quite far from the Hash rocket topic, just my last
comment on Rubocop
in general. What I see here is people saying "the more Rubocop" = "the
more consistency"
= "the more readable code". I don't agree with this reasoning. Yes,
some cops increases
the consistency, but it can just lead to your code to be consistently
unreadable. And some cops
have nothing to do with consistency.

Let's take few examples from the Rubocop source code itself:

  https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/config.rb#L243
- multi-line modifier statement - I hope nobody here would argue
for this being more readable
then standard if

  
https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/config_loader.rb#L74
- combination of modifier and non-modifier if: if you tried to put
everything into non-modifier form,
  it would tell you that you should use the modifier one (I
tried:), which would eventually lead you
  to the same case as previous one

  https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/config.rb
 - IMO the 80 lines limit just makes too many lines spread across
more lines, making it harder to read;
   ok, I know some people us vim in split on lower resolution, but
I don't think others and the readability
   should suffer from that: I would take the max line size from
what actually helps the readability, not
   what resolution somebody has, otherwise, I would just argue
that we need max 50 lines, to make it
   easier for me to review the code on my phone.

   https://github.com/bbatsov/rubocop/blob/v0.42.0/lib/rubocop/cli.rb#L5
  - the comment says "The CLI is a class responsible of handling
all the command line interface logic"
  - while it was true when the class was added few years ago, it's
no more valid that it's responsible
for handling *all* of the logic, because the option parser is
in separate class now.
  - I would say the comment was just useless at the first place,
and got obsolete (as comments
use to) and the only reason people add it there is the policy.
  - also, from personal experience with Rubocop documentation, I
would not say it helped anyhow,
I feel the pain every time I try to find what some cop expects
or how to disable that, I end up
looking at rubocop tests anyway usually.

What I think is happening is people relying on Rubocop keeping their
code readable
and not paying any attention to it. And some cops make it also harder
to improve the readability,
(I know you can always disable the the cop per line, but I would say
that already affects
the readability in a bad way).

I know that it might be frustrating for someone to discuss the styling between
the developers, rather that aligning to whatever few people agree on Rubocop
PR to merge. I asked several times to have proper discussion on the
cops to enable/disable,
rather than doing that in PRs directly. It didn't happened, which is
why we are arguing about
it every single time somebody wants to introduce some new one.

-- Ivan

>
> If dynflow was foreman core project and was reviewed in that way from the 
> first
> commit, this would not happen. Rubocop would not help too much. I tried to run
> rubocop on dynflow. From 1346 offenses I found only 22 regarding the obscure
> syntax, rest is "redundant return", "1.9 hash syntax", "top level class
> documentation missing" stuff. If you want to reproduce, see [1].
>
> This thread started around has rocket syntax. So to remain on topic, I don't
> think that the fact there is a cop for enforcing one hash syntax, it's widely
> accepted among Ruby devs. Speaking of hash rockets, an example might be github
> style guide - https://github.com/styleguide/ruby/hashes
>
> [1] 

Re: [foreman-dev] Using tmpfs significantly reduces testing time

[Tomer Brisker]

+1 to looking into implementing on Jenkins.
I would suggest even considering moving the entire /var/lib dir to tmpfs
instead of on disk so the other DBs will get a boost - assuming the
/var/lib dir is created anyways only for the worker's lifetime and
destroyed afterwards.
If this even gives us a 10% boost to test speed that would be a significant
step to reducing the Jenkins load.

On Thu, Aug 18, 2016 at 10:41 AM, Lukas Zapletal  wrote:

> Hello,
>
> this morning I observed that putting foreman git repo onto tmpfs folder
> (e.g. /tmp/foreman) greatly reduces testing time by more than 50 % !
>
> Running it from my checkout folder (Samsung SSD - 2014 edition):
>
> real27m24.425s
> user12m25.875s
> sys 0m27.050s
>
> And now from tmpfs:
>
> real12m21.645s
> user9m59.112s
> sys 0m9.877s
>
> I don't know if it's just the db/ directory or we do some temp files
> during tests, but before I investigate this further, I'd like someone to
> try this out and compare the numbers. I could made a mistake.
>
> If I had to guess, I think sqlite does some filesystem sync operations
> which are just noops on tmpfs (it's memory or swap right).
>
> This would be great benefit on our Jenkins assuming there is tmpfs
> available. I guess so (RHEL6+ has it). We do start always from scratch
> there, so mounting/symlinking db/ should be relatively easy to do. And I
> currently have about 35 MB in db/ folder, nothing that should kill the
> runner.
>
> --
> Later,
>  Lukas #lzap Zapletal
>
> --
> 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.
>



-- 
Have a nice day,
Tomer Brisker
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] Using tmpfs significantly reduces testing time

[sshtein]

I have ext4 for my home and tmpfs for /tmp.
I haven't tried your solution (symlink), but if you say it's pretty much 
the same as in-memory, I will surely switch to it.


On Wednesday, August 24, 2016 at 12:10:05 PM UTC+3, Lukas Zapletal wrote:
>
> > It would be nice to see the differences. 
>
> It's almost the same speedup as with symlink (the difference is loading 
> the database three times perhaps): 
>
> real13m32.018s 
> user11m13.229s 
> sys 0m12.004s 
>
> What is your file system? That might do the difference. 
>
> -- 
> Later, 
>  Lukas #lzap Zapletal 
>

-- 
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] Using tmpfs significantly reduces testing time

[Lukas Zapletal]

> It would be nice to see the differences. 

It's almost the same speedup as with symlink (the difference is loading
the database three times perhaps):

real13m32.018s
user11m13.229s
sys 0m12.004s

What is your file system? That might do the difference.

-- 
Later,
 Lukas #lzap Zapletal

-- 
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] Requesting 1-2 week branch warning

[Dominic Cleal]

On 23/08/16 21:05, Eric D Helms wrote:
> I'd like to request a 1-2 week branch warning for 1.13 (future releases
> would be great too). The month warning is great for helping finalize
> priorities. On top of that, I think having a 1 week warning with the
> date would help developers work to wrap up anything they are working on
> and begin planning plugin release tasks in congruence with the Foreman
> release.

Consider this your two week warning then!

Watching
http://projects.theforeman.org/projects/foreman/wiki/Foreman_113_Schedule is
a good idea - every release is linked from the dev resources, and
usually from my announcements.

-- 
Dominic Cleal
domi...@cleal.org

-- 
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] Hash rocket syntax

[Marek Hulán]

Few more comments below

> What do you mean by "Foreman dev"? 

You, me, everyone who contributed to Foreman.

> I’ve contributed to both foreman and
> rubocop several times. Having worked on rubocop with all its cops enabled
> hasn’t been a deterrent to me even though I don’t necessarily agree with
> all cops.

Seems rubocop devs are happy with more cops than at least one foreman dev is 
(me). That make sense, otherwise they would not contribute to rubocop I guess 
:-)

> I’m not disagreeing with you. But I still have nightmares about the dynflow
> source code which had no rubocop checking at all and featured a number of
> obscure ruby syntaxes that rubocop would have forbid.

If dynflow was foreman core project and was reviewed in that way from the first 
commit, this would not happen. Rubocop would not help too much. I tried to run 
rubocop on dynflow. From 1346 offenses I found only 22 regarding the obscure 
syntax, rest is "redundant return", "1.9 hash syntax", "top level class 
documentation missing" stuff. If you want to reproduce, see [1].

This thread started around has rocket syntax. So to remain on topic, I don't 
think that the fact there is a cop for enforcing one hash syntax, it's widely 
accepted among Ruby devs. Speaking of hash rockets, an example might be github 
style guide - https://github.com/styleguide/ruby/hashes

[1] https://gist.github.com/ares/ff6e8b19361148e2be17290f1167c7c4

--
Marek

> I think there’s probably a happy medium between not using rubocop and
> enabling all rubocop cops.
> 
> 
> David
> 
> On Tue, Aug 23, 2016 at 11:22 AM, Marek Hulán  wrote:
> > On Tuesday 23 of August 2016 07:47:31 David Davis wrote:
> > > The plugins may not have as many contributors as foreman core but
> > > rubocop
> > > has more contributors (279 vs 200 for foreman) and they have pretty much
> > > all cops enabled. It’s only been around for 3 years (vs 7 years for
> > > foreman) so it doesn’t seem to be a deterrent to community
> > > contributions.
> > 
> > I don't think this is fair comparison. Do you think that 279 contributors
> > of
> > one project represent all Ruby devs or all Foreman devs? At least not one
> > Foreman dev, that's for sure. I don't say we should disable rubocop but I
> > don't think all devs are happy with all cops. Adding cops like hash rocket
> > makes it only worse.
> > 
> > --
> > Marek
> > 
> > > I’d probably wager that most experienced Ruby developers are aware of
> > > rubocop and the ruby community style guide [1]. For unexperienced Ruby
> > > developers, I think they are a great way to learn good Ruby coding
> > > standards.
> > > 
> > > That said, I agree it would be nice to get opinions of community members
> > > who contribute to foreman and their experiences with rubocop.
> > > 
> > > [1] https://github.com/bbatsov/ruby-style-guide
> > > 
> > > 
> > > David
> > > 
> > > On Tue, Aug 23, 2016 at 3:48 AM, Marek Hulán  wrote:
> > > > I'm with Lukas, we already enforce too many things without clear
> > 
> > benefit.
> > 
> > > > Let's
> > > > keep both ways accepted which is default for all rubyists.
> > > > 
> > > > > > I think we implemented Rubocop far beyond what's reasonable point.
> > 
> > It
> > 
> > > > > > make sense for dangerous constructs, but not in this case (and few
> > > > > > others).
> > > > 
> > > > +1, since rubocop leads to bike-shedding and annoyed devs from both
> > 
> > sides
> > 
> > > > I
> > > > don't think it's a good idea to introduce more cops.
> > > > 
> > > > > I'd argue the opposite, in foreman_docker or foreman_ansible I think
> > > > > rubocop (with *all* cops enabled) helped maintain good coding
> > 
> > standards
> > 
> > > > > immensely and making the project *much easier* to read and get used
> > 
> > to.
> > 
> > > > With all respect, these plugins do not have as many contributors as
> > > > Foreman
> > > > and I'd like to hear from these contributors whether rubocop helped or
> > > > annoyed
> > > > them. I don't think that all cops enabled == good coding standards.
> > 
> > And it
> > 
> > > > does not imply good readability, that's on reviewer. TBH I think it's
> > 
> > also
> > 
> > > > pretty subjective (remember explicit return cop discussion).
> > > > 
> > > > --
> > > > Marek
> > > > 
> > > > On Friday 19 of August 2016 11:54:23 Daniel Lobato Garcia wrote:
> > > > > On 08/19, Lukas Zapletal wrote:
> > > > > > > As discussed on IRC yesterday there should be consistency and
> > 
> > there
> > 
> > > > is
> > > > 
> > > > > > > an
> > > > > > > option to autofix with rubocop if the style is changed to change
> > > > > > > existing
> > > > > > > code with less effort.
> > > > > > 
> > > > > > TL;DR - Let's keep Rubocop away from rockethash thing.
> > > > > > 
> > > > > > What the consistency gives us? We all know there are two ways and
> > 
> > both
> > 
> > > > > > will work. Let's avoid big bangs that will make cherry picking
> > 
> > harder
> > 
> > > > > > and just let's slowly