+1 for the ConfigOptions and the automatic configuration description
generation once we've migrated all config keys.
Cheers,
Till
On Fri, Oct 28, 2016 at 2:18 PM, Robert Metzger wrote:
> You are right Stephan. The doc migration will be easier when we use the new
> logic for all keys.
>
> On Fri
You are right Stephan. The doc migration will be easier when we use the new
logic for all keys.
On Fri, Oct 28, 2016 at 4:27 AM, Jark Wu wrote:
> +1
>
> The automatic configuration page generating sounds really cool.
>
> - Jark Wu
>
> > 在 2016年10月28日，上午12:23，Stephan Ewen 写道：
> >
> > I think add
+1
The automatic configuration page generating sounds really cool.
- Jark Wu
> 在 2016年10月28日，上午12:23，Stephan Ewen 写道：
>
> I think adding descriptions to the options and auto-generating the config
> docs is a very good followup.
>
> How about we do that after we migrated all options? Then we
I think adding descriptions to the options and auto-generating the config
docs is a very good followup.
How about we do that after we migrated all options? Then we can add the
docs generation logic in that step as well.
On Thu, Oct 27, 2016 at 5:22 PM, Robert Metzger wrote:
> +1 good idea.
>
>
+1 good idea.
I'm wondering whether we can extend this a bit to include a description of
the configuration options as well. This way, we can generate the
configuration page for the documentation from the code. This makes
maintenance for developers really easy.
This is also the approach Apache Kafk
Hey!
Here is the parent issue (with per component sub-issues) for the option
migration.
https://issues.apache.org/jira/browse/FLINK-4765
Stephan
On Thu, Oct 27, 2016 at 11:06 AM, Maximilian Michels wrote:
> +1 I like it a lot. Much clearer and better maintainable!
>
> Do we have a plan to mi
+1 I like it a lot. Much clearer and better maintainable!
Do we have a plan to migrate ConfigConstants to the new ConfigOptions?
Where do we maintain a list of all config options?
-Max
On Wed, Oct 26, 2016 at 2:36 PM, Stephan Ewen wrote:
> Hi all!
>
> A few weeks back we introduced a new way t
Hi all!
A few weeks back we introduced a new way to define configuration parameters.
I would like to encourage everyone to use that new pattern for all new
options that we create, and lazily migrate existing parameters to that
pattern.
The current way of maintaining keys, defaults, and deprecated
