Re: [foreman-dev] The road to Rails 5.1

[Eric D Helms]

On Thu, Nov 30, 2017 at 8:16 PM, Michael Moll  wrote:

> On Thu, Nov 30, 2017 at 08:06:53PM -0500, Eric D Helms wrote:
> > Thanks for the update Michael! In working on test builds, something I
> > noticed was that we currently have fog 1.41 which is locked to json < 2.
> > However, Ruby 2.4 provides json 2+. Fog  1.42 appears to require json 2+.
> > Is this a dependency that we can update alongside the Rails update?
>
> I found https://github.com/theforeman/foreman/pull/4869


Good find! I know this will likely break nightlies on the RPM side given
JSON is only at 2+ in Ruby 2.4. However, based on your previous email it
sounds like we are going to have to bite the bullet on some length of time
where RPMs are broken? The question then is how long do we allow that
period to be based upon how much time we give plugins to switch to Rails 5?


>
>
> 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] The road to Rails 5.1

[Michael Moll]

On Thu, Nov 30, 2017 at 08:06:53PM -0500, Eric D Helms wrote:
> Thanks for the update Michael! In working on test builds, something I
> noticed was that we currently have fog 1.41 which is locked to json < 2.
> However, Ruby 2.4 provides json 2+. Fog  1.42 appears to require json 2+.
> Is this a dependency that we can update alongside the Rails update?

I found https://github.com/theforeman/foreman/pull/4869

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] The road to Rails 5.1

[Eric D Helms]

Thanks for the update Michael! In working on test builds, something I
noticed was that we currently have fog 1.41 which is locked to json < 2.
However, Ruby 2.4 provides json 2+. Fog  1.42 appears to require json 2+.
Is this a dependency that we can update alongside the Rails update?

On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll  wrote:

> Hi,
>
> On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
> >  * Rails 5 SCL initial builds minus turbolinks exist [1]
> >  * Turobolinks 2.4.5 is being released that will have Rails 5
> compatability
> >  * Work is progressing to test rebuild Foreman stack against SCL, this
> will
> >be followed up runtime tests
> >
> > Would someone with more knowledge on the code side of the Rails 5 mind
> > sending along an update of the path we see for getting to 5.1?
>
> We're currently blocked by two external dependencies:
> - https://github.com/turbolinks/turbolinks-classic/pull/679 (already
>   merged, we're only waiting for the gem release)
> - https://github.com/oauth-xx/oauth-ruby/pull/150
>
> Once there are gem releases out, I'd open PRs to raise the lower version
> boundary of these in core and after these got in, I'd ask
> https://github.com/theforeman/foreman/pull/4867
> to get merged (BTW, Eric, please see the comment at the bottom).
>
> At that state, core would be using Rails 5.0 only and I'd open one PR
> including the 5.0 only parts of
> https://github.com/theforeman/foreman/pull/4836
>
> After that one got merged, core would be using Rails 5.0 and be
> incompatible with Rails 4.2.
>
> Plugin authors should start updating their plugins to Rails 5.0
> standards at that point.
>
> Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
> https://github.com/theforeman/foreman/pull/5026
>
> After that one got merged, core is using Rails 5.1 (and probably not
> even Rails 5.0 compatible) and the RPM work can start. DEBs should just
> work fine without modifications.
>
> Plugin authors should check if anything is missing for Rails 5.1 and
> update, if needed.
>
> After that, the remaining deprecation notices with Rails 5.1 should get
> fixed and once this is done, Rails 5.2 is probably already released.
>
> 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] The road to Rails 5.1

[Michael Moll]

Hi,

On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
>  * Rails 5 SCL initial builds minus turbolinks exist [1]
>  * Turobolinks 2.4.5 is being released that will have Rails 5 compatability
>  * Work is progressing to test rebuild Foreman stack against SCL, this will
>be followed up runtime tests
> 
> Would someone with more knowledge on the code side of the Rails 5 mind
> sending along an update of the path we see for getting to 5.1?

We're currently blocked by two external dependencies:
- https://github.com/turbolinks/turbolinks-classic/pull/679 (already
  merged, we're only waiting for the gem release)
- https://github.com/oauth-xx/oauth-ruby/pull/150

Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
https://github.com/theforeman/foreman/pull/4867
to get merged (BTW, Eric, please see the comment at the bottom).

At that state, core would be using Rails 5.0 only and I'd open one PR
including the 5.0 only parts of
https://github.com/theforeman/foreman/pull/4836

After that one got merged, core would be using Rails 5.0 and be
incompatible with Rails 4.2.

Plugin authors should start updating their plugins to Rails 5.0
standards at that point.

Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
https://github.com/theforeman/foreman/pull/5026

After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.

Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.

After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.

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] Nominating cfouant for write access to hammer-cli-katello

[Tom McKay]

+1

On Tue, Nov 21, 2017 at 11:55 AM, Chris Roberts 
wrote:

> +1 from me
>
> On Tuesday, November 21, 2017 at 11:40:48 AM UTC-5, Andrew Kofink wrote:
>>
>> I hereby nominate Christine Fouant to gain commit access to
>> hammer-cli-katello. She currently has 12 merged PRs
>> 
>>  and
>> has helped to review 11 merged PRs
>> 
>> .
>>
>> Let the +/-1's begin!
>>
>> --
>> Andrew Kofink
>> ako...@redhat.com
>> IRC: akofink
>> Software Engineer
>> Red Hat Satellite
>>
> --
> 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] The road to Rails 5.1

[Eric D Helms]

Circling back to this as we've made some progress on the SCL front.

Updates

 * Rails 5 SCL initial builds minus turbolinks exist [1]
 * Turobolinks 2.4.5 is being released that will have Rails 5 compatability
 * Work is progressing to test rebuild Foreman stack against SCL, this will
be followed up runtime tests

Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?


[1] https://copr.fedorainfracloud.org/coprs/g/theforeman/tfm-ror51/

On Fri, Oct 20, 2017 at 12:20 PM, Ohad Levy  wrote:

>
>
> On Oct 20, 2017 11:39 AM, "Tomas Strachota"  wrote:
>
> I'm also fine with removing them. I don't think it adds much value
> when we're moving towards UI based on React.
>
>
> I would be happy if someone compare UI responsiveness before we make the
> changes
>
>
> T.
>
> On Fri, Oct 20, 2017 at 8:17 AM, Ivan Necas  wrote:
> > Not hard feelings from me to remove turbo-links:)
> >
> > -- Ivan
> >
> > On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines 
> wrote:
> >> I personally would be okay if we removed turbolinks from foreman
> entirely.
> >> We want to replace it in the future with a true single page app
> anyway.  But
> >> if others want to put in the effort to maintain it I would support that
> >> effort as well.
> >>
> >> Cheers,
> >> Walden
> >>
> >> On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms 
> wrote:
> >>>
> >>> Thanks for the update Michael. I just want to point interested parties
> to
> >>> the RPM side of the discussions that are on going over in
> >>> https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
> >>>
> >>> On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll 
> wrote:
> 
>  Hi,
> 
>  while the original plan was to switch to Rails 5.0 soon and then begin
>  5.1 work, it's a major downside that RPMs would be broken for a
>  potentially longer period, so I closed
>  https://github.com/theforeman/foreman/pull/4867 and like to draw the
>  attention of interested parties to
>  https://github.com/theforeman/foreman/pull/4836 where all the changes
>  that are queued up lead to a still 100% green Rails 5.0 test run and
>  leave 21 test failures with 5.1.
> 
>  I guess two of iNečas' recently opened PRs will fix some of these.
> 
>  Besides the missing changes to get green tests one major problem is
> that
>  there's no Rails 5 compatible version of turbolinks-classic, so either
>  Foreman needs to move to turbolinks 5 or a forked turbolinks-classic
> gem
>  would be needed, if turbolinks should be kept.
> 
>  In the meanwhile Rails 5.1 should be packaged for RPM in some way...
> :)
> 
>  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.
> >>
> >>
> >> --
> >> 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.
>



-- 
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 o

Re: [foreman-dev] Kanban tools and redmine

[Walden Raines]

> So for me, I'd prefer to keep using what I need, redmine and some board
and
not trying to combine both together.

I think that is a fair point.

It would be nice if we had a way to import redmine issues into a board and
have them move themselves to in progress, ready for review, done, etc. as
the state changed on redmine.  I woul djust like to find some way to
minimize manual tracking.  Perhaps we could write some integrations to
trello/kanboard to cut down on the bookkeeping.

Cheers,
Walden

On Thu, Nov 30, 2017 at 4:27 AM, Marek Hulán  wrote:

> Dne středa 29. listopadu 2017 9:05:28 CET, Lukas Zapletal napsal(a):
> > Can you elaborate on why something does not make sense to track in
> > RedMine? I am not following, RedMine is a generic ticketing system and
> > you can create as many tickets as you want, e.g. Buy milk. It will
> > work. This is a dogma I do not take as an argument. What's relevant is
> > if you need to create private work items, but we do have a private
> > feature in RedMine and we use it from time to time. And frankly, we
> > don't need these very often (mostly security issues).
>
> Sorry for answering someone else question, but from my experience, redmine
> is
> great for tracking dev stuff, including back traces, links to PR, BZ,
> release
> that includes the fix etc. Stuff like buy milk that does not hopefully
> have a
> backtrace is easier to track in some board as it's easier to manipulate.
> More
> realistically, things like "review PR $number" is easier to add and track
> in
> more lightweight system. I think these are simply two different use cases
> and
> I'm fine using two different tools for them.
>
> So for me, I'd prefer to keep using what I need, redmine and some board and
> not trying to combine both together.
>
> --
> Marek
>
> > If you look to the past, various scrum teams tried dozens off tools.
> > But hey, you know what is still here? RedMine (and RHBZ of course :-)
> > - those systems survived. My sole opinion is let's ditch RedMine and
> > use RHBZ for everything, many open source projects do this. But I
> > understand many people cannot live with Bugzilla, that's fine. OK!
> > Let's just stick to RedMine then. If people want to try RedMine
> > plugins, I totally do support that. What I really like is to have
> > everything in one place - no copies.
> >
> > Historically, there have been problems with RedMine plugins for scrum,
> > it was overloading the server when whole team was moving tickets. But
> > we might upgraded to better hosting how, if infrateam approves I am
> > all for trying anything that is a RedMine plugin and works with
> > regular issues.
> >
> > This could be a chance to setup "staging" redmine, since we still have
> > some knowledge from the migration. There we can test it on our current
> > data and vote how we like it.
> >
> > LZ
> >
> > On Wed, Nov 29, 2017 at 8:00 AM, Ivan Necas  wrote:
> > > My uderstanding of kanban is, that moving the cards manually on the
> signal
> > > board is actually part of the kanban way of doing things. Another
> thing,
> > > that is integrated part of the kanban process is
> > > WIP limits, that I don't even see on the redmine plugin. Another reason
> > > for
> > > actually not using
> > > redmine for this is the rasks, that don't make sense to actually track
> in
> > > redmine.
> > >
> > > I have a pr to nice Marek's tooling around automating some common
> actions
> > > around
> > > Kanboard https://github.com/ares/kansync/pull/5 and so far, I'm happy
> with
> > > this.
> > >
> > > -- Ivan
> > >
> > > út 28. 11. 2017 v 22:37 odesílatel Andrew Kofink 
> > >
> > > napsal:
> > >> I'm open to using other kanban style tools. To me it doesn't really
> > >> matter
> > >> that much how we plan - it's the same information just in a different
> > >> format. So, if people have reasons, then I'm fine with switching.
> > >>
> > >> On Tue, Nov 28, 2017 at 4:29 PM, Walden Raines 
> wrote:
> > >>> Hey,
> > >>>
> > >>> With several teams moving to kanban style tools for the
> visualization of
> > >>> tasks I'm wondering if anyone has tried redmine's PluginKanban [1].
> > >>>
> > >>> I really like the idea of a trello/kanboard like tool but I hate
> having
> > >>> to update tasks in multiple places.  Another idea I had was to switch
> > >>> (back) to using GH issues and use GH projects [2] as well.
> > >>>
> > >>> Any other thoughts on how to make these kanban boards work better
> with
> > >>> redmine?
> > >>>
> > >>> Cheers,
> > >>> Walden
> > >>>
> > >>> [1] http://www.redmine.org/projects/redmine/wiki/PluginKanban
> > >>> [2] https://help.github.com/articles/about-project-boards/
> > >>>
> > >>> --
> > >>> 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/o

Re: [foreman-dev] 2018 community survey

[Sean O'Keeffe]

What did we use the data for last year?

I ask because be able to say "last year we made X change due to Y feedback"
might drive more submissions this year

On Thu, Nov 30, 2017 at 3:11 PM, Greg Sutcliffe 
wrote:

> It's time (again, :P) to start drafting the community survey for while
> we're in Belgium next year :)
>
> I'm short on time today, so here's a link to last year's survey. Much of
> the generic questions will remain the same, they seem to work. What
> other burning issues would people like data on? What needs more detail?
> What can be dropped?
>
> https://theforeman.org/2017/03/2017-foreman-survey-analysis.html
>
> I'll get to work stripping out the outdated questions and incorporating
> new ones sometime next week.
>
> 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.
>

-- 
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.

[foreman-dev] 2018 community survey

[Greg Sutcliffe]

It's time (again, :P) to start drafting the community survey for while
we're in Belgium next year :)

I'm short on time today, so here's a link to last year's survey. Much of
the generic questions will remain the same, they seem to work. What
other burning issues would people like data on? What needs more detail?
What can be dropped?

https://theforeman.org/2017/03/2017-foreman-survey-analysis.html

I'll get to work stripping out the outdated questions and incorporating
new ones sometime next week.

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.

[foreman-dev] Re: Discourse - upcoming dates

[Greg Sutcliffe]

It's been a week since I opened up the poll, time for an update...

TLDR: Poll closes next week, then it's "New year, new tools" ;)

# Myself

As most of you know, today is my last day full-time, as I go off on
leave tomorrow for a few months. However, this is my most ambitious
community project to-date, and I will not be abandoning it. Expect to
see me active in the evenings (GMT) - my profile [1] will tell you when
I was last seen if you want to stalk me :P

If you need me urgently, an email or a private message on Discourse
should reach me within 5-10mins, and I will reply as soon as I am able
(likely immediately, at least in brief).

# Which lists?

https://community.theforeman.org/t/poll-which-lists-should-migrate-to-discourse/7598

At first glance this poll is pretty clear, 71% in favour of moving both
lists. But that would be unfair to long-time members of the community
who voted to move a single list - as we often say, it's a meritocracy,
not a democracy, and not all votes are equal.

There isn't a number for "merit" that exists, so as an approximation, I
weighted the votes using the length of time the user has been on the
mailing list (not perfect, but better than nothing). The results,
however, don't shift the needle very much:

Total vote-days cast: 26490
Both lists: 16156 (60.99%)
Just users: 10334 (39.01%)

Even attempting to weight for karma/merit/call-it-what-you-like, we
still get a pretty clear 61% result. I will leave the poll open into
next week (Thanksgiving means the US in particular haven't had much time
to consider), but I think we need to start planning for this outcome.

Sidenote: I don't want vote-days to become a standard metric, I think
we're usually pretty good at coming to a consensus - but in this case I
wanted to try to give fair treatment to those who disagree with me on a
divisive topic. Hopefully that works for everyone. If you want to check
my maths, you can find the raw data and the script I used at [2].

# Moderators & Maintenance

I'd like to thank Ori, Tomer, and Eric for agreeing to be moderators. In
my absence, any spam/flagged-posts/tags/split topics/etc issues can be
directed to them. Ori and Ewoud are also admins, should that be
necessary for some reason.

The Discourse host has been added to our puppetmaster, and offsite
backups of the Discourse DB are now happening. This includes files, and
so will protect us in the unlikely event of a complete loss of the host.

# Users feedback

I will bump the users thread today and make them aware of the poll too.
So far I've only heard positive or neutral feedback from users (some of
it private, so you'll have to believe me), and I don't expect any major
upset at this stage.

The November newsletter will also contain this info, so that readers
there have a final chance to join in before we take a conclusion next week.

# Migration plan

https://community.theforeman.org/t/draft-migration-plan-theoretical/7550

No comments have been left on this yet, so either I've done a really
good job of planning, or ... ;)

I think the debate is now coming to a natural close (no new viewpoints
have been addded in a while), and we also need to consider a time to do
the actual migration. New Year is traditionally very quiet, and seems to
fit the timescale. Given the above plan calls for a 3 week notice
period, I'm currently planning on the following dates:

Thu Dec  7th - conclude polls and state decisions regarding list(s)
Mon Dec 11th - initiate migration plan (as above, T - 3 weeks)
Sun Dec 31st - at midnight (or close to it) migrate the list(s)

I can work though the items on the plan in my evenings, it's not too
high a load, but assistance is welcome ofc. I will also volunteer to
give up my New Year's evening to do the migration - with 2 small
children, I'm not going out anyway :P

New Year, new tools. Should be fun :)

Thanks
Greg

[1] https://community.theforeman.org/u/Gwmngilfen/summary
[2] http://irc.emeraldreverie.org/R

-- 
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] Unique IDs and UI testing automation

[Lukas Zapletal]

Just to be sure it does not get lost:

> All inputs, including those not technically in a form (row select
> checkboxes, for example)
> All buttons

All buttons (which are links) already has data-id which is always
present and when not, it is auto-generated from HREF attribute. This
was added by Og request, perhaps it did not serve well?

Autogeneration cannot be used in other cases, I guess there is no
other way than explicitly adding those IDs manually.

I vote for raising an exception when ID is missing and Rails are in
development mode so we will never add such an element without an ID.
Would be good to have some kind of ID "registry" also available for
plugins so we prevent from making double IDs. I can imagine something
similar than what's used in i18n world: N_(id) when you can easily
create simple parser to verify whole codebase to extract those strings
(and easily spot wrong IDs).

-- 
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] Unique IDs and UI testing automation

[Lukas Zapletal]

This code was actually created by me to server the very same purpose -
QAs asked for this. They wanted to have all buttons (links) to have an
ID and now they have it.

https://github.com/theforeman/foreman/commit/bfee97b6a6980b6ad4f5bd65f4b60680f08967f5

This is the request: http://projects.theforeman.org/issues/3751

We used data-id to carry the information. It is autogenerated from
HREF path, if that's missing then its "aid_not_defined".

I am not sure what happened and why QAs are not using this anymore. If
this is not used, it should go away. Indeed it looks like a hack, but
I wanted to have a generic solution to the problem - QAs always come
to us and request "can you add ID here, and here", this was supposed
to solve this issue so they are unblocked until we add explicit IDs
there.

LZ

On Wed, Nov 29, 2017 at 11:45 PM, Tomer Brisker  wrote:
> While I don't mind adding more IDs, care should be taken to make sure there
> aren't any duplicate ids on the same page.
> We already add data-id attributes to all links in a bit of a hacky way [1],
> I'd be happy to get rid of this unreadable code (which i'm not sure is even
> used anywhere) and replace it with actual ids in a consistent manner.
>
> [1]
> https://github.com/theforeman/foreman/blob/develop/app/helpers/application_helper.rb#L6
>
> On Wed, Nov 29, 2017 at 9:06 PM, Walden Raines  wrote:
>>
>> > Seems reasonable to me. I don't really see a downside other than the
>> > work to add all the IDs.
>>
>> I don't think we should go through the entire application and add the IDs.
>> I think the way to tackle this is two-fold:
>>
>> Add IDs as we update functionality on pages that don't have these IDs
>> Encouraging QE to report missing IDs (and potentially open a PR to add
>> them) on troublesome pages
>>
>> The latter has already been agreed to, the former is in our hands to
>> remember to do.
>>
>> Cheers,
>> Walden
>>
>>
>> On Wed, Nov 29, 2017 at 1:31 PM, Ewoud Kohl van Wijngaarden
>>  wrote:
>>>
>>> On Wed, Nov 29, 2017 at 01:08:13PM -0500, Walden Raines wrote:

 In order to assist in UI automation, I would like to propose that we add
 unique IDs to the following elements:

   - Tables and table rows (s)
   - All inputs, including those not technically in a form (row select
   checkboxes, for example)
   - All buttons

 These IDs should all follow the same format, perhaps something like
 object.class-object.id-element.type.  For example, product-2-row and
 product-2-checkbox.

 Thoughts on this?  Anything that needs to be added or changed?
>>>
>>>
>>> +1 This was also the feedback I heard from QE. Sometimes they have to use
>>> xpaths to test which are more likely to break than IDs.
>>>
>>>
>>> --
>>> 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.
>
>
>
>
> --
> 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.



-- 
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.

[foreman-dev] Re: Proposal: Foreman 1.XX = 2.0 (a new one)

[Lukas Zapletal]

Ok, gmail did not refresh me the thread, I was reading old posts.

> D) I want to stick with 1.X, talk about feature-driven release
> management or simply decide later

It looks like majority want to continue the discussion, please carry on there.

There are some voices that vertical nav with Rails 5.x might be a good
reason to do 2.0, but Eric preferred also to include V1 drop.

Also one interesting remark was that we don't need to rush and it does
not make any huge difference if we switch 1.17 or 1.19, that's also
worth mentioning.

That's for the summary.

-- 
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.

[foreman-dev] Re: Proposal: Foreman 1.XX = 2.0 (a new one)

[Lukas Zapletal]

I think there is misunderstanding and the thread deviated to 2.0
feature discussion. This is not core of my proposal, I explicitly do
not want to do feature talk. There will always be something that we
would like to have in version X.Y. What I propose is:

A) Let's do 2.0 instead 1.17 regardless of features
B) Let's do 2.0 instead 1.18 regardless of features
C) Let's do 2.0 instead 1.19 regardless of features
D) I want to stick with 1.X, talk about feature-driven release
management or simply decide later

And it's totally fair if you guys prefer to talk about features and
decide later. This is just my attempt to set the direction back, but
it looks like I already know where this is going anyways :-)

At least I tried and opened the discussion so we don't hit the wall of
"twenty"...

-- 
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] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

Dne čtvrtek 30. listopadu 2017 11:59:27 CET, Ewoud Kohl van Wijngaarden 
napsal(a):
> On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
> >Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
> >
> >napsal(a):
> >> On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
> >> >> Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
> >> >> the near future, but *please* lets use it to deprecate / drop stuff we
> >> >> no longer want to maintain. Otherwise there's no real point to it.
> >> >
> >> >I agree we can take this "opportunity" to drop some deprecated things
> >> >like V1 API, but I don't see many other things. We are pretty good in
> >> >deprecating things using our "two releases" rule which should be
> >> >followed no matter if we bump major version or not.
> >> 
> >> +1 this is very similar to Django's release policy: in 1.x it was x
> >> deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
> >> suggest we do the same.
> >> 
> >> >Let's not block 2.0 with any feature, I wrote the reasons, if we fit
> >> >in some deprecation work why not. But's let's agree on 2.0 timeframe
> >> >regardless of any planning.
> >> 
> >> +1 on letting 2.0 drop block on dropping things rather than adding
> >> things.
> >
> >Actually I'd prefer to use this opportunity to drop or rewrite stuff we
> >know is problematic. E.g. taxonomies (especially nesting), API v1,
> >hostgroup provisioning, extracting puppet to a plugin, smart variables
> >merging with parameters (not smart class parameters), dropping unattended
> >installation mode (or at least refactoring).
> 
> These sound like good goals. How hard would it be to make the changes
> you're suggesting?
> 
> I have a slight preference to make 1.17 the 2.0 already because of the
> changes it's introducing but other than dropping API v1 and unattended
> installation mode they all sound like non-trivial tasks that will not be
> ready in time for 1.17.

very rough estimations
taxonomies (at least two release cycles)
apiv1 (easy if we don't need to spend time on proper extracting to gem/plugin 
that users could still install)
host group provisioning (drop is easy, refactor could be 1 foreman release)
smart variables unification with params - 1 or 2 releases, Ori has done some 
research in this area
extracting puppet to a plugin, not sure, Shim would perhaps know better
unattended installation mode - 1 release

I think even if we paralellize the effort, they should all be delivered in 
same release that we would call 2.0. Not sure how to do it, keeping PR opened 
for more than few weeks is not good :-) I'd like to avoid 2 develop branches.

> Maybe we need a list of deprecated features/desired breaking changes so
> we can look at it after a release when we're starting to plan for the
> next. If it grows to a certain size or the release manager feels like
> it's time for a major then they can announce it's being considered. That
> way devs have time to give priority to the breaking changes a long time
> in advance rather than the 2 weeks prior to branching.

That sounds good to me.

> What I'm proposing are guidelines that mostly focus on clear
> communication - no strict policy. Communication is much more important
> than what we actually do.

+1

--
Marek

-- 
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] Unique IDs and UI testing automation

[Marek Hulán]

Thanks Walden for bringing this up.

Dne středa 29. listopadu 2017 20:06:50 CET, Walden Raines napsal(a):
> > Seems reasonable to me. I don't really see a downside other than the work
> 
> to add all the IDs.
> 
> I don't think we should go through the entire application and add the IDs.

Why not? It might be a bit boring but very useful effort. If we only add IDs 
to new UI, I as an integration tests writer would remain frustrated whenever I 
add new test that touches existing area. I think it wouldn't be more than 1 
day of work to extend all tables in Foreman core. For inputs it should be even 
simpler as we have form helpers that would just need to be updated (but I 
think all rails inputs already have id).

This would also be a good opportunity for a contribution for someone who'd 
like to investigate the whole stack, go over all pages and do small code 
changes on them.

> I think the way to tackle this is two-fold:
> 
>- Add IDs as we update functionality on pages that don't have these IDs
>- Encouraging QE to report missing IDs (and potentially open a PR to add
>them) on troublesome pages
> 
> The latter has already been agreed to, the former is in our hands to
> remember to do.

I think we should also agree on a guideline how to construct such IDs, so we 
don't end up in random strings which would be prone to duplicates. For parts 
that are generated by rails, I think using dom_id helper would be a good start 
[1], obviously UI rendered from JS would need to have it's implementation of 
this method.

For tables we could have something like this
'table-users'

for tr, this should do
dom_id(user, 'row') # result is row_user_15 where 15 is id of user, or 
row_user if user is new_record

For inputs, rails follow the rule $resource_$attribute, while this does not 
necessarily need to be always unique, I think it's a good enough for resource 
forms. For the rest (e.g. search input) we should generate it uniquely, there 
are cases where we have 2 search field on the same page, e.g. roles and 
filters opened in 2pane.

For buttons it can be tricky. Perhaps the same approach as we have with data-
id today in core would do, or even keep to data-id only.

[1] https://apidock.com/rails/ActionView/RecordIdentifier/dom_id

--
Marek

> 
> Cheers,
> Walden
> 
> 
> On Wed, Nov 29, 2017 at 1:31 PM, Ewoud Kohl van Wijngaarden <
> 
> ew...@kohlvanwijngaarden.nl> wrote:
> > On Wed, Nov 29, 2017 at 01:08:13PM -0500, Walden Raines wrote:
> >> In order to assist in UI automation, I would like to propose that we add
> >> 
> >> unique IDs to the following elements:
> >>   - Tables and table rows (s)
> >>   - All inputs, including those not technically in a form (row select
> >>   checkboxes, for example)
> >>   - All buttons
> >> 
> >> These IDs should all follow the same format, perhaps something like
> >> object.class-object.id-element.type.  For example, product-2-row and
> >> product-2-checkbox.
> >> 
> >> Thoughts on this?  Anything that needs to be added or changed?
> > 
> > +1 This was also the feedback I heard from QE. Sometimes they have to use
> > xpaths to test which are more likely to break than IDs.
> > 
> > 
> > --
> > 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.

[foreman-dev] 1.17 branching - status update 2

[Ondrej Prazak]

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]

* turbolinks fix for Rails 5.1 compatibility merged [2], waiting for new
turbolinks-classic release

* broken tests on Rails 5.1 fixed [3], failures caused by strong params no
longer subclassing HashWithIndifferentAccess

* proxy not being able to register due to OAuth issue - fix submitted to
OAuth [4]

Plugin mainainers/developers:
I started creating Redmine tickets and PRs for changes that need to go into
plugins in order to make them run on 5.1. These involve mostly just changes
to migrations, you can see example at [5]. Katello is blocked by [6].

[1] https://github.com/theforeman/foreman-infra/pull/380
[2] https://github.com/turbolinks/turbolinks-classic/pull/679
[3] https://github.com/theforeman/foreman/pull/5026
[4] https://github.com/oauth-xx/oauth-ruby/pull/150
[5] https://github.com/theforeman/foreman-docker/pull/202
[6] https://github.com/theforeman/foreman-tasks/pull/300

-- 
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] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:

Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):

On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
>> Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
>> the near future, but *please* lets use it to deprecate / drop stuff we
>> no longer want to maintain. Otherwise there's no real point to it.
>
>I agree we can take this "opportunity" to drop some deprecated things
>like V1 API, but I don't see many other things. We are pretty good in
>deprecating things using our "two releases" rule which should be
>followed no matter if we bump major version or not.

+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.

>Let's not block 2.0 with any feature, I wrote the reasons, if we fit
>in some deprecation work why not. But's let's agree on 2.0 timeframe
>regardless of any planning.

+1 on letting 2.0 drop block on dropping things rather than adding
things.


Actually I'd prefer to use this opportunity to drop or rewrite stuff we know
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup
provisioning, extracting puppet to a plugin, smart variables merging with
parameters (not smart class parameters), dropping unattended installation mode
(or at least refactoring).


These sound like good goals. How hard would it be to make the changes 
you're suggesting?


I have a slight preference to make 1.17 the 2.0 already because of the 
changes it's introducing but other than dropping API v1 and unattended 
installation mode they all sound like non-trivial tasks that will not be 
ready in time for 1.17.


Maybe we need a list of deprecated features/desired breaking changes so 
we can look at it after a release when we're starting to plan for the 
next. If it grows to a certain size or the release manager feels like 
it's time for a major then they can announce it's being considered. That 
way devs have time to give priority to the breaking changes a long time 
in advance rather than the 2 weeks prior to branching.


What I'm proposing are guidelines that mostly focus on clear 
communication - no strict policy. Communication is much more important 
than what we actually do.


--
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] Kanban tools and redmine

[Marek Hulán]

Dne středa 29. listopadu 2017 9:05:28 CET, Lukas Zapletal napsal(a):
> Can you elaborate on why something does not make sense to track in
> RedMine? I am not following, RedMine is a generic ticketing system and
> you can create as many tickets as you want, e.g. Buy milk. It will
> work. This is a dogma I do not take as an argument. What's relevant is
> if you need to create private work items, but we do have a private
> feature in RedMine and we use it from time to time. And frankly, we
> don't need these very often (mostly security issues).

Sorry for answering someone else question, but from my experience, redmine is 
great for tracking dev stuff, including back traces, links to PR, BZ, release 
that includes the fix etc. Stuff like buy milk that does not hopefully have a 
backtrace is easier to track in some board as it's easier to manipulate. More 
realistically, things like "review PR $number" is easier to add and track in 
more lightweight system. I think these are simply two different use cases and 
I'm fine using two different tools for them.

So for me, I'd prefer to keep using what I need, redmine and some board and 
not trying to combine both together.

--
Marek

> If you look to the past, various scrum teams tried dozens off tools.
> But hey, you know what is still here? RedMine (and RHBZ of course :-)
> - those systems survived. My sole opinion is let's ditch RedMine and
> use RHBZ for everything, many open source projects do this. But I
> understand many people cannot live with Bugzilla, that's fine. OK!
> Let's just stick to RedMine then. If people want to try RedMine
> plugins, I totally do support that. What I really like is to have
> everything in one place - no copies.
> 
> Historically, there have been problems with RedMine plugins for scrum,
> it was overloading the server when whole team was moving tickets. But
> we might upgraded to better hosting how, if infrateam approves I am
> all for trying anything that is a RedMine plugin and works with
> regular issues.
> 
> This could be a chance to setup "staging" redmine, since we still have
> some knowledge from the migration. There we can test it on our current
> data and vote how we like it.
> 
> LZ
> 
> On Wed, Nov 29, 2017 at 8:00 AM, Ivan Necas  wrote:
> > My uderstanding of kanban is, that moving the cards manually on the signal
> > board is actually part of the kanban way of doing things. Another thing,
> > that is integrated part of the kanban process is
> > WIP limits, that I don't even see on the redmine plugin. Another reason
> > for
> > actually not using
> > redmine for this is the rasks, that don't make sense to actually track in
> > redmine.
> > 
> > I have a pr to nice Marek's tooling around automating some common actions
> > around
> > Kanboard https://github.com/ares/kansync/pull/5 and so far, I'm happy with
> > this.
> > 
> > -- Ivan
> > 
> > út 28. 11. 2017 v 22:37 odesílatel Andrew Kofink 
> > 
> > napsal:
> >> I'm open to using other kanban style tools. To me it doesn't really
> >> matter
> >> that much how we plan - it's the same information just in a different
> >> format. So, if people have reasons, then I'm fine with switching.
> >> 
> >> On Tue, Nov 28, 2017 at 4:29 PM, Walden Raines  
wrote:
> >>> Hey,
> >>> 
> >>> With several teams moving to kanban style tools for the visualization of
> >>> tasks I'm wondering if anyone has tried redmine's PluginKanban [1].
> >>> 
> >>> I really like the idea of a trello/kanboard like tool but I hate having
> >>> to update tasks in multiple places.  Another idea I had was to switch
> >>> (back) to using GH issues and use GH projects [2] as well.
> >>> 
> >>> Any other thoughts on how to make these kanban boards work better with
> >>> redmine?
> >>> 
> >>> Cheers,
> >>> Walden
> >>> 
> >>> [1] http://www.redmine.org/projects/redmine/wiki/PluginKanban
> >>> [2] https://help.github.com/articles/about-project-boards/
> >>> 
> >>> --
> >>> 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.
> >> 
> >> --
> >> Andrew Kofink
> >> akof...@redhat.com
> >> IRC: akofink
> >> Software Engineer
> >> Red Hat Satellite
> >> 
> >> --
> >> 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/o

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden 
napsal(a):
> On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
> >> Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
> >> the near future, but *please* lets use it to deprecate / drop stuff we
> >> no longer want to maintain. Otherwise there's no real point to it.
> >
> >I agree we can take this "opportunity" to drop some deprecated things
> >like V1 API, but I don't see many other things. We are pretty good in
> >deprecating things using our "two releases" rule which should be
> >followed no matter if we bump major version or not.
> 
> +1 this is very similar to Django's release policy: in 1.x it was x
> deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
> suggest we do the same.
> 
> >Let's not block 2.0 with any feature, I wrote the reasons, if we fit
> >in some deprecation work why not. But's let's agree on 2.0 timeframe
> >regardless of any planning.
> 
> +1 on letting 2.0 drop block on dropping things rather than adding
> things.

Actually I'd prefer to use this opportunity to drop or rewrite stuff we know 
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup 
provisioning, extracting puppet to a plugin, smart variables merging with 
parameters (not smart class parameters), dropping unattended installation mode 
(or at least refactoring).

If the only reason is we the number is too high, I think it does not balance 
the missed chance and it would be a pity to not use such opportunity.

--
Marek

-- 
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] Missing github issues features (no migration)

[Marek Hulán]

Dne středa 29. listopadu 2017 11:09:03 CET, Greg Sutcliffe napsal(a):
> On 29/11/17 09:33, Lukas Zapletal wrote:
> > Or maybe I miss the main reason why we are not using Github issues at
> > all?
> 
> As you said, the last time we evaluated it, it simply wasn't suitable.
> The situation is more comparable now, however (in addition to BZ link
> and private issues) I think we would also lose flexibility. In the the
> last week or so, Marek and Walden have both proposed new plugins that
> could be added to our Redmine - not possible if we go to GH, we'd be
> stuck with waiting for them to implement new features (and in my
> experience that's not fast at all). That's always the downside of going
> proprietary over open source ;)
> 
> > I like github integration with PRs, speed and good reliability (only
> > few blackouts per year) and also new features like projects. On the
> > other hand, it's full commitment to something not under our control
> > (today we can easily move our git somewhere else, but we still loose
> > all PRs).
> 
> Side note: Actually the PR data is accessible over the API, and I have
> *all* of it in a MySQL DB. Yes, that's a lot of data - once I learn more
> about data analysis (studying R at the moment :P) I will be doing things
> with it.
> 
> > This email is just to discuss possibilities, I know that migration
> > to Github would be painful and even too expensive or perhaps
> > technically not doable (how to migrate so many tickets). It's a pitty
> > that github is now getting features it really needed.
> 
> I think that's the key point. There's no doubt we *could* make GH Issues
> fit our workflow (or any other bugtracker) - but the effort to migrate
> 20,000+ Redmine issues to multiple repos, as well as change all the
> automation, is more than likely not worth it. There needs to be a *huge*
> win for moving to GH Issues to make it happen, and I'm only seeing
> side-grades and incremental stuff, I'm afraid.
> 
> > I also really like gitlab which is packed with super nice features,
> > theoretically migration to something like that would be easier (open
> > source). On the other hand, we'd need to host this and one thing is
> > having redmine down for an hour, different thing is inability to
> > push. But this is definitely a possibility, we also have some know
> > how already running our internal instance.
> 
> I'd be +1 for GitLab-for-everything, assuming we can figure out some
> reliablity, as you say. Maybe using Gitlab.com is an option. But *wow*
> that is a lot of work :D
> 
> Greg

+1 to Greg reply, personally I'm fine with redmine.

--
Marek

-- 
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.

[foreman-dev] [Event] Foreman Community Demo Items - Thu 07 Dec 3pm [BST]

[Ori Rabin]

Hi all,

Demo time! As always, have a think for items which have been completed since
the last demo on 2017-11-16. There is a query that will show you items
completed (i.e. marked as closed) since the last demo [2].  Please add demo
items following the instructions on the agenda page [3].

If you can't be present but have something to show, add it to the
agenda and let me know - I'll be happy to talk about the feature in your
absence. Please do leave me enough time to familiarize myself with the
content
though :)

[1] https://www.youtube.com/watch?v=g8XnAKfG9xY
[2] http://tinyurl.com/ycf7wqcv
[3]
http://projects.theforeman.org/projects/foreman/wiki/Current_Sprint_Information

--
Ori
IRC: orabin

-- 
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.

AW: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Bernhard Suttner]

Totally agree with that. Vert nav + Rails 5.1 + Drop support of APIv1 would be 
the best reason for 2.0 for sure

-Ursprüngliche Nachricht-
> Von:Ondrej Prazak 
> Gesendet: Donnerstag 30 November 2017 09:08
> An: foreman-dev@googlegroups.com
> Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
> 
> 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 some major changes, then is vertical nav + Rails 5.1 
> significant enough to have 2.0 instead of 1.17?
> 
> O. 
> 
> On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller 
> mailto:hopfenmuel...@atix.de>> wrote:
> If you are still looking for new ideas for Foreman 2.0:
> I dont know whether this is seen by you guys as a major change-  but having a 
> consistent API v2 in Foreman and Katello would be a very nice thing.
> We are stumbling across some inconsistencies from time to time with our 
> foreman/katello Ansible  module work.
> The issue [1] I am linking here is for Satellite and not Foreman, but 
> problems like that are in Foreman as well.
> E.g the searching works a bit different for Katello and Foreman entities [2]
> 
> Regarding Erics suggestions:
> " Pick your own config management (aka dropping Puppet as default within the 
> application obviously stilled required for the installer)" 
> I dont think that is boring at all! ;)
> 
> Bernhard
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807 
> 
> [2] https://github.com/SatelliteQE/nailgun/issues 
> 
> ---
> ATIX - The Linux & Open Source Company
>  https://www.atix.de 
> 
> 
> -Original message-
> From: Eric D Helms mailto:ericdhe...@gmail.com>>
> Sent: Wednesday 29th November 2017 18:18
> To: foreman-dev  >
> Subject: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
> 
> My two cents are that we shouldnt arbitrarily bump the version. Versions have 
> and signal meaning to users. Especially when we are talking about the main 
> line, core project. Fortunately or unfortunately, major version bumps signal 
> either a major shift or change and/or a marketing opportunity. Further, major 
> version changes should signal that plugins are also going to have to change 
> to stay compliant. Id suggest we stick with folks suggestions of finding some 
> things to entirely deprecate and bump the version and/or adding some major 
> support components so that 2.0 is a major change. Things Ive head so far:
> 
>  * Rails 5.1 and Ruby 2.4 support
>  * Remove API v1
>  * Vertical Nav
> 
> Some further, potentially more boring ideas as part of a "Foreman 2.0, new 
> stack, new look" release:
> 
>  * Pick your own config management (aka dropping Puppet as default within the 
> application obviously stilled required for the installer)
>  * Updates to repository structure such as adding a client repository
>  * Tasks support in Core
> 
> 
> This, based on comments, also sounds like a good time to visit a versioning 
> policy so that we adhere to it and give plugins and users some predictability.
> 
> 
> Eric
> 
> 
> 
> On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms  > wrote:
> 
> 
> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner  > wrote:
> I also like the idea of a version 2.0 very much. Personally, I would be very 
> happy to move bastion from katello to foreman so that its possible to create 
> modern, angular js components within foreman. One more reason to do this is, 
> because I think foreman should be the structure, the base "framework" all 
> other plugins like katello can live in. Just my thoughts...
> 
> This is not going to happen regardless. All net new UI is being created in 
> React. Bastion is effectively in a critical bug fix state only. All React 
> work is being done in Foreman core, or plugins directly (e.g. all new React 
> work in Katello is going into Katello directly). You can consider the use of 
> Angular within Foreman and Katello dead  for all intents and purposes.
> 
> Eric
> 
>  Best regards,
>  Bernhard Suttner
>  
>  ATIX - The Linux & Open Source Company
>  https://www.atix.de 
>  
>  -Ursprüngliche Nachricht-
>  > Von:Lukas Zapletal mailto:l...@redhat.com>>
>  > Gesendet: Mittwoch 29 November 2017 14:18
>  > An: foreman-dev  >
>  > Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
>  >
>  > > Bikeshedding about SemVer aside, Im good with doing a 2.0 release in
>  > > the near future, but *please* lets use it to deprecate / drop stuff we
>  > > no longer want to maintain. Otherwise theres no real point to it.
>  >
>  > I agree

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ondrej Prazak]

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 some major changes, then is vertical nav + Rails 5.1
significant enough to have 2.0 instead of 1.17?

O.

On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller <
hopfenmuel...@atix.de> wrote:

> If you are still looking for new ideas for Foreman 2.0:
>
> I don't know whether this is seen by you guys as a major change-  but
> having a consistent API v2 in Foreman and Katello would be a very nice
> thing.
>
> We are stumbling across some inconsistencies from time to time with our
> foreman/katello Ansible  module work.
>
> The issue [1] I am linking here is for Satellite and not Foreman, but
> problems like that are in Foreman as well.
>
> E.g the searching works a bit different for Katello and Foreman entities
> [2]
>
>
> Regarding Eric's suggestions:
>
> " Pick your own config management (aka dropping Puppet as default within
> the application obviously stilled required for the installer)"
>
> I don't think that is boring at all! ;)
>
>
> Bernhard
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807
>
> [2] https://github.com/SatelliteQE/nailgun/issues
>
>
> ---
>
> ATIX - The Linux & Open Source Company
> https://www.atix.de
>
>
>
>
> -Original message-
> *From:* Eric D Helms 
> *Sent:* Wednesday 29th November 2017 18:18
> *To:* foreman-dev 
> *Subject:* Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
>
> My two cents are that we shouldn't arbitrarily bump the version. Versions
> have and signal meaning to users. Especially when we are talking about the
> main line, core project. Fortunately or unfortunately, major version bumps
> signal either a major shift or change and/or a marketing opportunity.
> Further, major version changes should signal that plugins are also going to
> have to change to stay compliant. I'd suggest we stick with folks
> suggestions of finding some things to entirely deprecate and bump the
> version and/or adding some major support components so that 2.0 is a major
> change. Things I've head so far:
>
>  * Rails 5.1 and Ruby 2.4 support
>  * Remove API v1
>  * Vertical Nav
>
> Some further, potentially more boring ideas as part of a "Foreman 2.0, new
> stack, new look" release:
>
>  * Pick your own config management (aka dropping Puppet as default within
> the application obviously stilled required for the installer)
>  * Updates to repository structure such as adding a client repository
>  * Tasks support in Core
>
>
> This, based on comments, also sounds like a good time to visit a
> versioning policy so that we adhere to it and give plugins and users some
> predictability.
>
>
> Eric
>
>
>
> On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms 
> wrote:
>
>>
>>
>> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner 
>> wrote:
>>
>>> I also like the idea of a version 2.0 very much. Personally, I would be
>>> very happy to move bastion from katello to foreman so that it's possible to
>>> create modern, angular js components within foreman. One more reason to do
>>> this is, because I think foreman should be the structure, the base
>>> "framework" all other plugins like katello can live in. Just my thoughts...
>>>
>>
>> This is not going to happen regardless. All net new UI is being created
>> in React. Bastion is effectively in a critical bug fix state only. All
>> React work is being done in Foreman core, or plugins directly (e.g. all new
>> React work in Katello is going into Katello directly). You can consider the
>> use of Angular within Foreman and Katello dead  for all intents and
>> purposes.
>>
>> Eric
>>
>>
>>>
>>> Best regards,
>>> Bernhard Suttner
>>>
>>> ATIX - The Linux & Open Source Company
>>> https://www.atix.de
>>>
>>> -Ursprüngliche Nachricht-
>>> > Von:Lukas Zapletal 
>>> > Gesendet: Mittwoch 29 November 2017 14:18
>>> > An: foreman-dev 
>>> > Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
>>> >
>>> > > Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
>>> > > the near future, but *please* lets use it to deprecate / drop stuff
>>> we
>>> > > no longer want to maintain. Otherwise there's no real point to it.
>>> >
>>> > I agree we can take this "opportunity" to drop some deprecated things
>>> > like V1 API, but I don't see many other things. We are pretty good in
>>> > deprecating things using our "two releases" rule which should be
>>> > followed no matter if we bump major version or not.
>>> >
>>> > Let's not block 2.0 with any feature, I wrote the reasons, if we fit
>>> > in some deprecation work why not. But's let's agree on 2.0 timeframe
>>> > regardless of any planning.
>>> >
>>> > --
>>> > Later,
>>> >   Lukas @lzap Zapletal
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Gr