Re: Adding experimental arguments to nmcli tool

[Thomas Haller <thaller redhat com>]

On Tue, 2022-03-08 at 14:57 +0100, Till Maas wrote:
> Hi,
>
> Am Mo., 7. März 2022 um 22:38 Uhr schrieb Thomas Haller via
> networkmanager-list <networkmanager-list gnome org>:
> > Hi,
> >
> > On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via
> > networkmanager-list wrote:
> > > It has been considered to add experimental new arguments to
> > > 'nmcli'
> > > tool 
> > > related to keyfiles. These arguments will be added with a warning
> > > message on documentation specifying they are experimental. The
> > > main
> > > idea 
> > > is to experiment and not commit to them for a long time.
> >
> > re:experimental.
> >
> > I don't think it's good to mark new API as experimental. Breaking
> > API
> > is annoying to users, and should only be done if there are very
> > very
> > good reasons or when no users are affected. Otherwise, the
> > annoyance is
> > the same regardless whether the API is marked as experimental. With
> > the
> > difference, that if the API was experimental, it has the notion of
> > being the fault of the user using the API (which it really isn't).
>
>
> Currently, the API is not delivered to users since there is no
> agreement on how to do it.
> For example the features that Fernando mentioned are not that complex
> to code but hard to find an agreement on for the command-line flags.
> Therefore, the possible annoyance of users is solved by not giving
> them a choice at all, They simply cannot use the API, therefore they
> will also not have to change it. By delivering something as
> experimental, the users get a choice: They
> can use it and accept that they might have to adapt or they can
> choose not to use it and be in the same situation as if we did not
> deliver the API at all. Basically, we will provide additional value
> to early adopters, unblock our development (the code can be written
> already) and once there is an agreement on the final API, only small
> changes would be necessary if at all. Therefore, adding experimental
> features seem to be an overall benefit.


Let's just discuss how the feature should be done. Which is not a very
controversial or hard question.

I think it's not necessary to have a meta discussion about the process
how we do it. And it's not necessary to introduce an "experimental"
API, when we can just add the real thing.

We can find agreement on the real thing, at which point it's not
experimental. That in the future the choice might turn out to be
suboptimal, is always the danger and not special about this.


best,
Thomas