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

[Bernhard Hopfenmüller]

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 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] Re: Katello Rails 5 PR Testing

[Eric D Helms]

Updates. The test job is currently working as expected for Katello and
failing with an error a developer will need to look into. See traceback
below.

NOTE: For any other plugin maintainers reading this if you'd like a
dedicated Rails 5 PR test job let me know and we can work to add one
similar to what I've done for Katello.

 |   class AddDockerManifestList < ActiveRecord::Migration[4.2]
(called from load at
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/bin/rake:22)
== 20171010172724 AddDockerManifestList: migrating 
-- create_table(:katello_docker_manifest_lists, {})
   -> 0.0028s
-- create_table(:katello_repository_docker_manifest_lists, {})
   -> 0.0020s
-- create_table(:katello_docker_manifest_list_manifests, {})
   -> 0.0019s
-- remove_foreign_key(:katello_docker_tags, :docker_manifest)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

Table 'katello_docker_tags' has no foreign key for docker_manifest
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract/schema_statements.rb:970:in
`foreign_key_for!'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract/schema_statements.rb:940:in
`remove_foreign_key'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:846:in
`block in method_missing'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:815:in
`block in say_with_time'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:815:in
`say_with_time'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:835:in
`method_missing'
/var/lib/workspace/workspace/katello-pr-test/db/migrate/20171010172724_add_docker_manifest_list.rb:23:in
`up'


On Wed, Nov 29, 2017 at 3:36 PM, Eric D Helms  wrote:

> Katello developers may notice a 'rails-5' status pop up on pull requests.
> I am working to add testing against Rails 5 stack. This currently fails so
> it can safely be ignored. This thread will get an update when the testing
> has been officially implemented and thus should be a gate for new PRs.
>
> --
> Eric D. Helms
> Red Hat Engineering
>



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

[Tomer Brisker]

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



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

[Walden Raines]

> My sole opinion is let's ditch RedMine and use RHBZ for everything, many
open source projects do this.

This conversation has somewhat derailed from my original intent but I would
also be in favor of getting rid of redmine entirely and using only BZ, even
though BZ has a horrendous UI, because I want to minimize the number of
places I have to track my work items.  Currently we have BZ, redmine, GH,
gitlab, potentially a kanban board depending on your team, and aha! if you
keep up with that.  Perhaps the solution is more integrations between the
various tools or perhaps the solution is combining tools that do the same
thing.

I would also be in favor of using GH issues and projects in lieu of redmine
and trello/kanboard/etc. since we are already using GH for pull requests.

But if we're going to keep redmine then I would like to test out the
PluginKanban so I at least don't make matters worse by adding an additional
tool.  I would be happy to test it out and report back if someone could
install it for me.

Cheers,
Walden



On Wed, Nov 29, 2017 at 6:26 AM, Greg Sutcliffe 
wrote:

> On 28/11/17 21:29, 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].
>
> Haven't tried it, yet :). Performance would be good to find out about
> (Redmine Backlogs was *awful* for that), and also what versions of
> Redmine it supports (can't just see that info).
>
> I need to do an update for the list about the redmine status, so let me
> include this on that.
>
> 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.

Re: [foreman-dev] Unique IDs and UI testing automation

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Unique IDs and UI testing automation

[Andrew Kofink]

Seems reasonable to me. I don't really see a downside other than the work
to add all the IDs.

On Wed, Nov 29, 2017 at 1:08 PM, Walden Raines  wrote:

> Hey,
>
> 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?
>
> Thanks,
> Walden
>
> --
> 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.

[foreman-dev] Unique IDs and UI testing automation

[Walden Raines]

Hey,

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?

Thanks,
Walden

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

[Eric D Helms]

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



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

[Eric D Helms]

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
> 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 options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] 1.16.0 release builds started

[Ewoud Kohl van Wijngaarden]

Usually that's as fast as possible. Given the current status and time in 
this timezone I'd expect that's somewhere tomorrow.


On Wed, Nov 29, 2017 at 08:22:20AM -0500, Eric D Helms wrote:

Is there an expected or target date for the release to go out since builds
have started? That would help plugins plan for release work.

On Wed, Nov 29, 2017 at 8:16 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


A quick heads up: 1.16.0 final was tagged and we started the builds.
Especially the ARM builds a take a while.


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

[Andrew Kofink]

+1 to 2.0 and removing API v1! Oh, and 2.0 should cook breakfast. Also,
should we bump Katello to 4.0? Just a thought.

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



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

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

[Bernhard Suttner]

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

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

[Ewoud Kohl van Wijngaarden]

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.


--
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] Community-developed Ansible modules for Foreman API objects

[Eric D Helms]

As well, hammer is a bit of a beast dependency wise. We currently package
it in the SCL, I'm not sure how well it works from gem install and even if
with all of that you are increasing the barrier to entry for users by
requiring Ruby, gem installs, potentially the SCL for newer Ruby versions.
I appreciate the thought behind it but it feels more like a can of worms
that is better off with the lid staying on.

Eric

On Wed, Nov 29, 2017 at 8:06 AM, Andrew Kofink  wrote:

> Yeah, modules have to be written in Python for inclusion in Ansible core
> [1].
>
> [1] http://docs.ansible.com/ansible/latest/dev_guide/
> developing_modules_checklist.html
>
> On Wed, Nov 29, 2017 at 4:40 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> I had a look at this at some point but what I really dislike about Hammer
>> as an API is that the JSON output is also capitalized and inconsistent.
>> Ended up with large mappings and quickly gave up. Maybe I missed something
>> and it can be done easily.
>>
>>
>> On Wed, Nov 29, 2017 at 09:35:46AM +, Sean O'Keeffe wrote:
>>
>>> Here's a radical thought, use Hammer...
>>>
>>> Ansible modules do not have to be written in Python[2], although Ansible
>>> does provide some nice shortcuts with Python, all that is really required
>>> is JSON output... Some Ruby examples [1]
>>> A couple of things to note if we were to entertain going down this route;
>>> - How does DOCUMENTATION work for non-python modules? I played around
>>> for a
>>> bit, but couldn't get ansible-doc to work..
>>> - If the goal is to get them into Ansible core, will they accept Ruby
>>> modules? Looking at Ansible core I think all the modules are python...
>>>
>>>
>>> [1] https://github.com/ansible/ansible-for-rubyists
>>> [2]
>>> http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/develop
>>> ing_modules.html
>>>
>>> On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
>>> michael.ho...@adfinis-sygroup.ch> wrote:
>>>
>>> On Wed, 25 Oct 2017 08:09:10 -0400
 Andrew Kofink  wrote:
 [...]
 > If given a choice, I would vote for Nailgun, a more mature project
 with
 > more contributors and guaranteed future contribution from Satellite
 QA.
 > There is a bit of a gap between foreman-ansible-modules and Nailgun,
 given
 > that it is not purpose built; for this, we do include
 > ansible_nailgun_cement.py [1].
 >
 > I appreciate the support and interest from the community.

 So far we've only used python-foreman in a few different projects, one
 to
 configure Foreman based on a YAML file. We use python-foreman to resolve
 the
 IDs first thus the actual names of the templates, etc. can be used.
 Working
 with the lib is nice but it still needs some glue because the API is
 inconsistent and doing a lookup for the ID is not aligned for all
 resources.

 I have no experience with nailgun but from my point of view dependencies
 are
 not that big of a deal when provided as proper packages. E.g. to use the
 Ansible mysql_db module you require python-mysqldb.

 I'd love to switch to an upstream Ansible module to configure Foreman
 and
 improve our existing playbooks.

 Thanks for all the hard work so far!

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



-- 
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] 1.16.0 release builds started

[Eric D Helms]

Is there an expected or target date for the release to go out since builds
have started? That would help plugins plan for release work.

On Wed, Nov 29, 2017 at 8:16 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> A quick heads up: 1.16.0 final was tagged and we started the builds.
> Especially the ARM builds a take a while.
>
> --
> 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] Proposal: Foreman 1.18 = 2.0

[Lukas Zapletal]

> 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 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.16.0 release builds started

[Ewoud Kohl van Wijngaarden]

A quick heads up: 1.16.0 final was tagged and we started the builds. 
Especially the ARM builds a take a while.


--
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] Community-developed Ansible modules for Foreman API objects

[Andrew Kofink]

Yeah, modules have to be written in Python for inclusion in Ansible core
[1].

[1]
http://docs.ansible.com/ansible/latest/dev_guide/developing_modules_checklist.html

On Wed, Nov 29, 2017 at 4:40 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> I had a look at this at some point but what I really dislike about Hammer
> as an API is that the JSON output is also capitalized and inconsistent.
> Ended up with large mappings and quickly gave up. Maybe I missed something
> and it can be done easily.
>
>
> On Wed, Nov 29, 2017 at 09:35:46AM +, Sean O'Keeffe wrote:
>
>> Here's a radical thought, use Hammer...
>>
>> Ansible modules do not have to be written in Python[2], although Ansible
>> does provide some nice shortcuts with Python, all that is really required
>> is JSON output... Some Ruby examples [1]
>> A couple of things to note if we were to entertain going down this route;
>> - How does DOCUMENTATION work for non-python modules? I played around for
>> a
>> bit, but couldn't get ansible-doc to work..
>> - If the goal is to get them into Ansible core, will they accept Ruby
>> modules? Looking at Ansible core I think all the modules are python...
>>
>>
>> [1] https://github.com/ansible/ansible-for-rubyists
>> [2]
>> http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/
>> developing_modules.html
>>
>> On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
>> michael.ho...@adfinis-sygroup.ch> wrote:
>>
>> On Wed, 25 Oct 2017 08:09:10 -0400
>>> Andrew Kofink  wrote:
>>> [...]
>>> > If given a choice, I would vote for Nailgun, a more mature project with
>>> > more contributors and guaranteed future contribution from Satellite QA.
>>> > There is a bit of a gap between foreman-ansible-modules and Nailgun,
>>> given
>>> > that it is not purpose built; for this, we do include
>>> > ansible_nailgun_cement.py [1].
>>> >
>>> > I appreciate the support and interest from the community.
>>>
>>> So far we've only used python-foreman in a few different projects, one to
>>> configure Foreman based on a YAML file. We use python-foreman to resolve
>>> the
>>> IDs first thus the actual names of the templates, etc. can be used.
>>> Working
>>> with the lib is nice but it still needs some glue because the API is
>>> inconsistent and doing a lookup for the ID is not aligned for all
>>> resources.
>>>
>>> I have no experience with nailgun but from my point of view dependencies
>>> are
>>> not that big of a deal when provided as proper packages. E.g. to use the
>>> Ansible mysql_db module you require python-mysqldb.
>>>
>>> I'd love to switch to an upstream Ansible module to configure Foreman and
>>> improve our existing playbooks.
>>>
>>> Thanks for all the hard work so far!
>>>
>>
> --
> 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.

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

[Greg Sutcliffe]

On 29/11/17 12:17, Ewoud Kohl van Wijngaarden wrote:

> So I'd disagree we use SemVer.

I didn't mean we use it *properly*, just that anytime I see X.Y.Z as a
versioning structure, my mind immediately thinks SemVer. That we *do*
use it in other places only adds to the confusion.

What I am thinking is that we *should* use SemVer, and not get so
hesitant to bump the X component in the future. We have stuff we've
wanted to deprecate for a while now, so let's use a tool for that which
we already use in other places. It might also allow us to be more formal
about those plugin contracts...

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.

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] Redmine upgrades - WIP

[Greg Sutcliffe]

Hi all,

As you all know, our Redmine instance is very very old, so I just wanted
to give a quick note about where I got to with upgrading it, and some
notes if anyone wants to take over, since I likely won't have time to
push this forward while I'm away. The TLDR is that plugins are a pain...

There are 3 main areas that need dealing with before we can upgrade
Redmine: code changes, db migration testing, and plugin compatibility.

For the code changes, I've finished this. At [1] you'll find a set of
branches containing rebased code for each of the Redmine version
branches. This will enable us to migrate up through 3.0, 3.1 etc.

For the db:migrate testing, I've run db:migrate with a recent backup of
the production DB, on each of those branches, using psql 9.6. and ruby
2.1 (I couldn't get 2.0, which is on the Redmine box, to install on my
laptop for some reason). No issues found, all migrations are fine.

Plugins is where we hit some issues. Firstly, Redmine Backlogs has no
compatibility above 2.X, so we'll have to drop it. I don't *think*
anyone is actually using the backlog feature, but we do need the Release
field it provides. We can either add this as a custom field (requiring
updates to our automation) or create a small new plugin that replicates
just this bit of functionality. Either way, some work is required.

All other plugins appear to migrate fine, although things like GitHub
auth can't be tested since they involve redirecting to the real site -
there are no code errors at least. I have updated the submodule commits
in my branches, where needed (lightbox2 has a bunch of versions).

We have requests for two new plugins as well:

* Marek - Question Plugin

I believe this is
http://www.redmine.org/projects/redmine/wiki/PluginQuestion but that
hasn't been updated in a long time. I haven't tried it yet, but I'd be
surprised if it works out of the box for Redmine 3.

I don't see anything similar in the 3.4.3-compatible plugin list [2], so
it may be necessary to get our hand dirty if we want this.

* Walden - Kanban plugin

https://github.com/edavis10/redmine_kanban - Same problem (both were
developed by the same person, who shut down his efforts in 2013). Not
updated since 2011 gives me little hope here...

http://www.redmine.org/plugins/redhopper may be an alternative, seems
maintained. There's also http://www.redmine.org/plugins/scrum-plugin but
that seems overkill (but could be a replacement for Backlogs, if we want
it).

So, the outstanding tasks are:

* Resolve the Release field we need from the defunct Backlogs plugin
* (optional) Find a Questions plugin and test it (or write one)
* (optional) Test one of the kanban plugins

If someone wants to volunteer to fix the Release field problem, I can do
the migration very easily one evening. I would guess an hour's downtime
is enough, given I've done all the rebasing already.

[1] https://github.com/GregSutcliffe/redmine/branches/active
[2] http://www.redmine.org/plugins?page=17==%E2%9C%93=3.4

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.


signature.asc
Description: OpenPGP digital signature

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

[Ewoud Kohl van Wijngaarden]

Anything that's on the mailing list with [plugin author action required] 
is likely breaking the API.


Recently we had the mass change from FactoryGirl to FactoryBot (which is 
causing a lot of pain while cherry picking to older releases as well).  
That had to be coordinated to sync it up with all plugins that were 
using it.


I recall Stephen got so sick of his salt plugin breaking every time he 
stopped maintaining it. That was mostly due to accidental breakage 
because there's no clear API that we guarantee.


So I'd disagree we use SemVer.

On Wed, Nov 29, 2017 at 01:04:45PM +0100, Lukas Zapletal wrote:

Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.

Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).

LZ

On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe
 wrote:

On 29/11/17 10:45, Lukas Zapletal wrote:

Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.


Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
 *Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P


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

[Lukas Zapletal]

Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.

Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).

LZ

On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe
 wrote:
> On 29/11/17 10:45, Lukas Zapletal wrote:
>> Oh no, *everyone* is talking features. :-) This has really nothing to
>> do with features, because that can easily fall into "neverending"
>> category of what's big enough change or not.
>
> Well, *technically* we use SemVer (I know, I know...). For that, while
> features play a part, for me it's more about correctly calling out
> breaking changes. So if we're every going to deprecate a bunch of stuff,
> then we should call *that* 2.0. Otherwise it's just grandstanding ;)
>  *Technically* we should be including the internal plugin API in our
> SemVer and bumping the major version every time plugins need to
> update... but that might get silly :P
>
> 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.



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

[Greg Sutcliffe]

On 28/11/17 21:29, 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].

Haven't tried it, yet :). Performance would be good to find out about
(Redmine Backlogs was *awful* for that), and also what versions of
Redmine it supports (can't just see that info).

I need to do an update for the list about the redmine status, so let me
include this on that.

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.


signature.asc
Description: OpenPGP digital signature

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

[Greg Sutcliffe]

On 29/11/17 10:45, Lukas Zapletal wrote:
> Oh no, *everyone* is talking features. :-) This has really nothing to
> do with features, because that can easily fall into "neverending"
> category of what's big enough change or not.

Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
 *Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P

Greg

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

[Lukas Zapletal]

Yeah I think I misinterpreted how this feature works. I thought its
just a discussion per project. This is per team I guess, as you
pointed out.

Ok I am migrating back to wiki unless there is some blocker raised.

LZ

On Wed, Nov 29, 2017 at 11:37 AM, Greg Sutcliffe
 wrote:
> On 29/11/17 08:47, Daniel Lobato Garcia wrote:
>> If it helps, I think
>> https://github.com/blog/2471-introducing-team-discussions looks also
>> like a good tool for these kind of discussions, without any need for
>> a moderator. The discussions are restricted to people in the GitHub
>> team.
>
> TLDR: -1 to this from me, I'm afraid. Let me explain.
>
> Firstly, we have to ask if this is a *replacement* for other
> discussions (i.e. dev-list), which I don't think you're proposing, or
> in-addition-to dev-list. I'll cover both, just to be complete.
>
> If it's an *additional* channel, then it will die. This is exactly what
> happened to the RFC repo the first time - we added an extra place to
> discuss things, the discussion fragmented, and then the network effect
> dragged all the discussion back to the dev-list.
>
> In addition, it's *even* more fragmented than the RFC repo, because it's
> per-team - and we have 63 teams. Yes, there's a "members" team, but even
> that only has 56 people in it (the org has 71, so something is out of
> line there). Limiting discussion to a single team means many more places
> to check if you want to know what's being discussed (but aren't already
> a part of the discussion).
>
> It's also worse than RFC repo in the sense that it still requires a
> GitHub account to participate - but now you *also* have to be in the
> team too. It does respect team structure, but we don't currently nest
> teams, and propagating discussions between child teams (eg plugins)
> looks awkward. That means we get into small, silo'ed discussions that
> don't get enough feedback from the wider community. That's dangerous
> echo-chamber / groupthink ground.
>
> On the other hand, if it's a *replacement* for dev-list (bear with me
> here :P), then I don't see anything here which is better than the
> *other* replacement for dev-list on the table (that's Discourse, which
> may happen looking at the current poll). There we *centralise* the
> discussion instead of fragmenting it, but keep the wiki-like powers, can
> use @group notifications to alert people, and users can join in too if
> they wish. As a *replacement*, team discussions thus feels inferior.
>
> Either way, I'm not a fan. This is a case of knowing the purpose of your
> communication channels and picking *one* way to handle it that suits the
> purpose. Having >1 just fragments everything (I learned that the hard
> way with the RFC repo, sadly). At the very least, I'd ask that we finish
> sorting out Discourse before we start on "communication changes, round
> 2" - we may find the new tooling should be part of that process.
>
> On 29/11/17 08:55, Lukas Zapletal wrote:
>
>> Greg, can you turn it on in RFC repo so we can test this? If this
>> fails, we can move to wiki and deprecate that repo.
>
> It's not per repo, it's per team, and GitHub has already enabled it
> across the entire site. It can't be disabled as far as I can see, so you
> can try it in any team you're a member of.
>
> example: https://github.com/orgs/theforeman/teams/discovery/discussions
>
> 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.



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

[Lukas Zapletal]

Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.

We've heard that 1.17 is possible, yeah I do agree but only if that's
confirmed by the release engineer, not sure if branches or anything
has been created already. Also we might already commented on the
internet about "upcoming 1.17", at least I did, so might be safer to
do 1.18. On the other hand, it's pretty easy for anyone to figure out
2.0 is the next version...

LZ

On Wed, Nov 29, 2017 at 11:14 AM, Sean O'Keeffe  wrote:
> +1 to the idea. Although 1.17 is a good candidate in terms of features, lets
> give ourselves time to decided what should be deprecated. Anytime after 1.17
> is good with me!
>
> On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe 
> wrote:
>>
>> Given 1.17 will have:
>>
>> * vertical nav
>> * rails 5.X
>>
>> I think this is a good candidate, if we're ever going to do it. It's
>> also a good chance to put the woes of 1.16 behind us :)
>>
>> 1.17 hasn't been branched, but it's soon. If we're going to do this,
>> we'll need to decide what should be deprecated.
>>
>> 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.



-- 
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] [RFC] Deprecate and move Github RFC repo content

[Greg Sutcliffe]

On 29/11/17 08:47, Daniel Lobato Garcia wrote:
> If it helps, I think 
> https://github.com/blog/2471-introducing-team-discussions looks also 
> like a good tool for these kind of discussions, without any need for
> a moderator. The discussions are restricted to people in the GitHub
> team.

TLDR: -1 to this from me, I'm afraid. Let me explain.

Firstly, we have to ask if this is a *replacement* for other
discussions (i.e. dev-list), which I don't think you're proposing, or
in-addition-to dev-list. I'll cover both, just to be complete.

If it's an *additional* channel, then it will die. This is exactly what
happened to the RFC repo the first time - we added an extra place to
discuss things, the discussion fragmented, and then the network effect
dragged all the discussion back to the dev-list.

In addition, it's *even* more fragmented than the RFC repo, because it's
per-team - and we have 63 teams. Yes, there's a "members" team, but even
that only has 56 people in it (the org has 71, so something is out of
line there). Limiting discussion to a single team means many more places
to check if you want to know what's being discussed (but aren't already
a part of the discussion).

It's also worse than RFC repo in the sense that it still requires a
GitHub account to participate - but now you *also* have to be in the
team too. It does respect team structure, but we don't currently nest
teams, and propagating discussions between child teams (eg plugins)
looks awkward. That means we get into small, silo'ed discussions that
don't get enough feedback from the wider community. That's dangerous
echo-chamber / groupthink ground.

On the other hand, if it's a *replacement* for dev-list (bear with me
here :P), then I don't see anything here which is better than the
*other* replacement for dev-list on the table (that's Discourse, which
may happen looking at the current poll). There we *centralise* the
discussion instead of fragmenting it, but keep the wiki-like powers, can
use @group notifications to alert people, and users can join in too if
they wish. As a *replacement*, team discussions thus feels inferior.

Either way, I'm not a fan. This is a case of knowing the purpose of your
communication channels and picking *one* way to handle it that suits the
purpose. Having >1 just fragments everything (I learned that the hard
way with the RFC repo, sadly). At the very least, I'd ask that we finish
sorting out Discourse before we start on "communication changes, round
2" - we may find the new tooling should be part of that process.

On 29/11/17 08:55, Lukas Zapletal wrote:

> Greg, can you turn it on in RFC repo so we can test this? If this 
> fails, we can move to wiki and deprecate that repo.

It's not per repo, it's per team, and GitHub has already enabled it
across the entire site. It can't be disabled as far as I can see, so you
can try it in any team you're a member of.

example: https://github.com/orgs/theforeman/teams/discovery/discussions

Greg

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sean O'Keeffe]

+1 to the idea. Although 1.17 is a good candidate in terms of features,
lets give ourselves time to decided what should be deprecated. Anytime
after 1.17 is good with me!

On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe 
wrote:

> Given 1.17 will have:
>
> * vertical nav
> * rails 5.X
>
> I think this is a good candidate, if we're ever going to do it. It's
> also a good chance to put the woes of 1.16 behind us :)
>
> 1.17 hasn't been branched, but it's soon. If we're going to do this,
> we'll need to decide what should be deprecated.
>
> 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.

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

[Greg Sutcliffe]

Given 1.17 will have:

* vertical nav
* rails 5.X

I think this is a good candidate, if we're ever going to do it. It's
also a good chance to put the woes of 1.16 behind us :)

1.17 hasn't been branched, but it's soon. If we're going to do this,
we'll need to decide what should be deprecated.

Greg

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Missing github issues features (no migration)

[Greg Sutcliffe]

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

-- 
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 Wed, Nov 29, 2017 at 10:39:42AM +0100, Lukas Zapletal wrote:

What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.

I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)

I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.

If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.

I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.


While I don't care if we pick 1.18, 1.19 or maybe even 1.17 I do agree 
it's getting to the point where we are hard to compare with the 1.0 
release.


I'd like to consider implementing semver as well. Some things I can 
think of:


* A formal plugin API
* Functions in templates

Deprecations can happen but are only removed in 3.0. This might mean we 
do 2 -> 3 a lot faster than 1 -> 2 but that's ok IMHO.


We can also implement APIs as experimental if we're unsure if they're 
the best.


With this in mind the rails 4.2 -> rails 5.1 might be a good reason to 
adopt 2.0. Since rails 5.2 will the last 5.x, rails 6.0 might be a 3.0 
reason.


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

[Timo Goebel]

... I think we should take increasing the major version as a chance and remove 
some old compatibility stuff with it like e.g. APIv1.
Or fix some APIv2 inconsistencies. Maybe we could move foreman tasks to core. 
Just some suggestions. Just increasing the major version is in, but I think 
just a cosmetic thing.

Timo

> On 29. Nov 2017, at 10:39, Lukas Zapletal  wrote:
> 
> What have Linus Torvalds and me in common? We both don't remember
> numbers higher than ten.
> 
> I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
> for no other reason that it's just too high number and it's
> approaching crazy 20. "One point eighteen" sounds crazy, I always mess
> up with "One point eight". Frankly, I kinda lost track somewhere after
> 1.14. :-)
> 
> I'd like also to propose to avoid exceeding 10 in the future - someone
> speak up as we will approach to 1.8. Or we can put this to release
> wiki.
> 
> If we already have some infrastructure set for 1.18, I propose 1.19 to
> be 2.0 and act now - let's define a plan what needs to be done in
> advance. I can only think of version number in RedMine, but you tell
> me here what's needed.
> 
> I really hope it's not just me messing around with higher numbers or
> having problems with typing four characters instead of three many
> times.
> 
> -- 
> 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.

-- 
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] Community-developed Ansible modules for Foreman API objects

[Ewoud Kohl van Wijngaarden]

I had a look at this at some point but what I really dislike about 
Hammer as an API is that the JSON output is also capitalized and 
inconsistent. Ended up with large mappings and quickly gave up. Maybe I 
missed something and it can be done easily.


On Wed, Nov 29, 2017 at 09:35:46AM +, Sean O'Keeffe wrote:

Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around for a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...


[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
michael.ho...@adfinis-sygroup.ch> wrote:


On Wed, 25 Oct 2017 08:09:10 -0400
Andrew Kofink  wrote:
[...]
> If given a choice, I would vote for Nailgun, a more mature project with
> more contributors and guaranteed future contribution from Satellite QA.
> There is a bit of a gap between foreman-ansible-modules and Nailgun,
given
> that it is not purpose built; for this, we do include
> ansible_nailgun_cement.py [1].
>
> I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one to
configure Foreman based on a YAML file. We use python-foreman to resolve
the
IDs first thus the actual names of the templates, etc. can be used. Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all
resources.

I have no experience with nailgun but from my point of view dependencies
are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman and
improve our existing playbooks.

Thanks for all the hard work so far!


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

[Lukas Zapletal]

What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.

I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)

I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.

If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.

I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.

-- 
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] Community-developed Ansible modules for Foreman API objects

[Sean O'Keeffe]

Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around for a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...


[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
michael.ho...@adfinis-sygroup.ch> wrote:

> On Wed, 25 Oct 2017 08:09:10 -0400
> Andrew Kofink  wrote:
> [...]
> > If given a choice, I would vote for Nailgun, a more mature project with
> > more contributors and guaranteed future contribution from Satellite QA.
> > There is a bit of a gap between foreman-ansible-modules and Nailgun,
> given
> > that it is not purpose built; for this, we do include
> > ansible_nailgun_cement.py [1].
> >
> > I appreciate the support and interest from the community.
>
> So far we've only used python-foreman in a few different projects, one to
> configure Foreman based on a YAML file. We use python-foreman to resolve
> the
> IDs first thus the actual names of the templates, etc. can be used. Working
> with the lib is nice but it still needs some glue because the API is
> inconsistent and doing a lookup for the ID is not aligned for all
> resources.
>
> I have no experience with nailgun but from my point of view dependencies
> are
> not that big of a deal when provided as proper packages. E.g. to use the
> Ansible mysql_db module you require python-mysqldb.
>
> I'd love to switch to an upstream Ansible module to configure Foreman and
> improve our existing playbooks.
>
> Thanks for all the hard work so far!
>
> Kind regards
>
> Michael
>
> --
> 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] Missing github issues features (no migration)

[Lukas Zapletal]

Sup!

When we introduced RedMine, Github issues were very limited. Calm
down, this is just a review of what's missing from Github issues, I am
not planning to propose or do anything :-) Let me do quick review of
missing features as of today (fall 2017) and possible mapping to
issues:

REDMINE - ISSUE

Status = Label
Priority = Label
Assigned To = Assignee
Category = Label
Target version = Milestone
Difficulty = Label
Found in release = Label
Votes = Reaction (+1)
Related issue = Issue link
Issue type = Subject (e.g. [TRACKER])
Bugzilla link = ???

So theoretically, we could map mostly everything to labels. There are
two ways of creating those labels, free form or with prefix. The
latter would look like:

Status-NeedMoreInfo
Priority-Urgent
Cat-Hostgroups
Difficulty-Easy
FoundIn-1.16

That looks ugly, frankly I'd prefer free form, because we often only
set just few (if not none) of the flags - Found In Version is one of
the most important ones and that could be as simple as "In 1.16".

So basically, we are missing bugzilla link and private comments. Is
the BZ link item only informative, or is there some non-human
processing behind? I know there is a bot but does it need BZ link? It
could search comments for some token for the same thing. For private
issues we could use Bugzilla (usually security bugs only), there is no
solution other than pay them for private repo.

Or maybe I miss the main reason why we are not using Github issues at all?

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

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

*Sigh*

-- 
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: Re: [foreman-dev] Kanban tools and redmine

[Lukas Zapletal]

> Projects in GitHub are also per-team,

Those Projects look great, but it's a good fit only when you use
Issues as well. Having RedMine + GH Projects is not much added value I
think.

Ivan: Those votes I proposed would only choose if to put a plugin to
prod instance or not of course. You would choose whatever you like.

-- 
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: Re: [foreman-dev] Kanban tools and redmine

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 09:45:49AM +0100, Daniel Lobato Garcia wrote:

On 11/28, Ewoud Kohl van Wijngaarden wrote:

On Tue, Nov 28, 2017 at 04:29:01PM -0500, Walden Raines wrote:
> 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.

Just going to jump on the GH projects. While I really like the idea, for me
they're too limiting since they're only within a single repo while a lot of
work involves multiple PRs in different repos.

> [2] https://help.github.com/articles/about-project-boards/


Projects in GitHub are also per-team,
https://github.com/orgs/theforeman/projects, which allows to track
issues in multiple repos. I'm fine with anything, but as Lukas said
previously, the less places we have to look at the better.


Regardless of the current discussion this is useful. I was sure I read 
somewhere that it was possible but couldn't find it.



BZ + GitHub would work for me, we would have to update our Redmine
automation to BZ of course.


There's a lot of automation downstream too and yesterday we discussed 
adding the ability of use BZ + GH directly. Many installer module PRs 
don't have a Redmine issue which would be similar. Currently it's still 
causing a lot of manual work.


--
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: Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

[Lukas Zapletal]

Yeah, I also think this would make sense. It's basically a wiki with
discussion - ideal.

Greg, can you turn it on in RFC repo so we can test this? If this
fails, we can move to wiki and deprecate that repo.

--

LZ
  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: Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

[Daniel Lobato Garcia]

On 11/15, Tomer Brisker wrote:
> Since I already suggested this some months ago, obvious +1 from me :)
>
> On Wed, Nov 15, 2017 at 1:41 PM, Greg Sutcliffe  
> wrote:
> > +1 to moving them to the Redmine wiki. The RFC repo was a good
> > experiment but handled badly (at least some of the blame for that is on
> > me). At this point I don't think it's possible to rescue it.
> >
> > On 15/11/17 10:52, Sean O'Keeffe wrote:
> >> Without wanting to hijack this thread... I think this is actually one of
> >> the areas Discourse can benefit us, generally as a community I think were
> >> not very good at making a decision after a discussion. I think some of the
> >> features it seems to provide (voting system) could help with that.
> >
> > Clearly I'm going to +1 that comment too ;) - the other really useful
> > thing is the per-thread analytics you can get about views, top links, etc.
> >
> > 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.

If it helps, I think
https://github.com/blog/2471-introducing-team-discussions looks also
like a good tool for these kind of discussions, without any need for a
moderator. The discussions are restricted to people in the GitHub team.

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

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

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


signature.asc
Description: PGP signature

Re: Re: [foreman-dev] Kanban tools and redmine

[Daniel Lobato Garcia]

On 11/28, Ewoud Kohl van Wijngaarden wrote:
> On Tue, Nov 28, 2017 at 04:29:01PM -0500, Walden Raines wrote:
> > 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.
>
> Just going to jump on the GH projects. While I really like the idea, for me
> they're too limiting since they're only within a single repo while a lot of
> work involves multiple PRs in different repos.
>
> > [2] https://help.github.com/articles/about-project-boards/

Projects in GitHub are also per-team,
https://github.com/orgs/theforeman/projects, which allows to track
issues in multiple repos. I'm fine with anything, but as Lukas said
previously, the less places we have to look at the better.

BZ + GitHub would work for me, we would have to update our Redmine
automation to BZ of course.

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

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

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


signature.asc
Description: PGP signature

Re: [foreman-dev] Kanban tools and redmine

[Ivan Necas]

On Wed, Nov 29, 2017 at 9:05 AM, Lukas Zapletal  wrote:
> 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).

Few classes:

* branding plugin
* tasks that are not related to the code: such as
  * help on specific customer cases
  * triage cards

Another thing, that Ewoud also mentioned is, some logical item is quite often
split into various redmine issues, due to the policy of one ticket per
repo (which
is a good thing, but not that much suitable for organizing of the work IMO)

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

I like to think about Redmine as a system for tracking issues + changes
in the code. Trying to use it for other things as well seems to me like misusing
it. I'm not holding anyone's hands to try it out, just expressing my opinion
on why I don't feel that's something I would be interested in at the moment.

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

I would leave this in autonomy of the teams and choosing by what works best
for the particular team, than voting and than forcing everyone to use the same.
You can of course decide in your team to do the voting. If this proves to work
well, I'm sure folks will vote by their feet.

-- Ivan

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

Re: [foreman-dev] Kanban tools and redmine

[Lukas Zapletal]

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

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