Re: Relaxed STATUS voting rules for experimental features?

[Daniel Shahaf]

Branko Čibej wrote on Mon, 12 Feb 2018 23:11 +0100:
> Backporting experimental features isn't crucial, surely? Yet if there
> are changes in trunk, they _might_ affect other code; in that case, more
> eyes is better.

So perhaps something like 'two +1s and one "I verified no non-
experimental code is affected"'.  There were some shelving-related
nominations in the past weeks that I would have easily been able to cast
the latter vote for, but not the former.

The thinking here is to have a three-man rule for the "Stable features
aren't affected" part but a two-man rule for the "Changes to an
experimental feature" part.

Re: Relaxed STATUS voting rules for experimental features?

[Branko Čibej]

On 12.02.2018 16:00, Daniel Shahaf wrote:
> The shelving functionality is experimental:
>
> /** Shelve a change.
>  ⋮
>  * @since New in 1.10.
>  * @warning EXPERIMENTAL.
>  */
> SVN_EXPERIMENTAL
> svn_error_t *
> svn_client_shelve(const char *name,
>   const apr_array_header_t *paths,
>   svn_depth_t depth,
>   const apr_array_header_t *changelists,
>   svn_boolean_t keep_local,
>   svn_boolean_t dry_run,
>   svn_client_ctx_t *ctx,
>   apr_pool_t *pool);
>
> Shall we relax the STATUS voting criteria for such features?
>
> Currently they are "three +1's"; we could relax to "two +1's".
>
> WDYT?

Backporting experimental features isn't crucial, surely? Yet if there
are changes in trunk, they _might_ affect other code; in that case, more
eyes is better.

-- Brane