Re: [BuildStream] bst CLI design and consistency (UI)

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi Sander,

On Fri, 2018-12-07 at 14:23 +0100, Sander Striker wrote:
> Hi,
[...]
> > While I do agree with Paul's adjacent reply here that breaking the
> > command line for us is much less of a concern than breaking format
> > compatibility, I think this is a temporary situation due to our tool
> > being relatively young
>
> It's young like pre-1.x :).

I believe this was a playful statement on your part, and I don't think
you mean to offend with it, but I honestly resent that people are
treating BuildStream as if it were some kind of unstable, unreliable
work in progress.

We have a reliable format, we are feature complete for a core set of
features and we have users relying on the stability of this core
feature set.

Making statements that we are "pre-1.x" only goes towards sewing
distrust in our existing user base, who have real needs, and to whom we
need to demonstrate our reliability.

>   Getting stable on the data format and cache keys early, would make
> life easier, as even with breakage in a CLI, versions would
> interoperate.  As such you could test new versions, decide to
> downgrade, and not lose the builds that you did with either version.

Stability of cache keys was *never* a guarantee, I'll re-post the link
to the original set of API stability guarantees:

    https://mail.gnome.org/archives/buildstream-list/2018-January/msg00006.html

Frankly, changing cache keys does not make BuildStream backwards
incompatible, it only means that when you change a minor point version,
you will need to rebuild everything.

It is a goal to reach this artifact stability, but it does not prevent
us from having a stable API.

> > (I'm sure that we would all be pretty upset if
> > the git developers were to bikeshed their CLI even once let alone
>
> I think we can all agree that the world would have been a better
> place had that happened and introduced consistency.

I am honestly unfussed about my personal taste of how I might think the
git CLI *should* have been, which probably differs from whoever else
you ask.

I maintain that it is mostly a matter of taste, and the more offensive
thing would be for the CLI I have already learned and built programs
which incorporate it as a tool, to change it's behavior and interface.

> > multiple times, given the amount of scripting which exists in the wild
> > and depends on the git CLI).
>
> You consider the current CLI work bikeshedding?

It doesn't really matter what I think because a vast majority of the
contributor base wants to overhaul the CLI.

My personal opinion is that it is definitely bikeshedding.

There will always be opinions about how the CLI could be better, and a
point comes when you need to put reliability and stability above
personal preferences and perfectionism - for BuildStream this time was
last year, and the fact that we are revisiting this worries me that it
might even happen again in the future.

I am however optimistic that the current set of contributors recognize
this, and that is why we are concentrating on it so vigorously, because
we recognize that we should never do it again.

That really is my own personal opinion on the matter, but as I said,
the majority of contributors really want this change and as such I am
not going to try and stand in the way of it.


That said, since the scope of these changes has gone so far, it is
really worth considering just calling the next release 2.0 (at first it
was just one or two workspace commands which were going to change).

[...]
> > I'd like to also underline that our motivations for remaining stable in
> > the long term should be a matter of dignity, it is what makes the tool
> > trustworthy for the new users we want to attract - in other words: the
> > volume of existing users should not be the motivating factor in being
> > stable.
>
> I don't think anyone wants to break anything for the sake of breaking
> things.  I think we want to break things because the project is young
> and is still making mistakes/learning lessons that are worth
> correcting early.  And while yes, we should consider users, let's
> also be honest in that our current user base are of the early adopter
> kind.  They can take a bit more churn for the sake of progress.  As
> the project matures, our user base will change and our APIs, UIs, etc
> will effectively cement and become unchangeable.

I agree and disagree.

Look at it this way: We have a hand full of users which we have a close
relationship with; GNOME and freedesktop-sdk, as much as it does pain
them when CI breaks with an upgrade, our relations are good enough such
that we take care of their needs and overall we overcome the small
breakages.

On the other hand, over the last year we have had some random people
come into the channel, report an issue, and take the time to thank us
for our work, it really is a good feeling when people you dont know at
all are using the work.

I think we should be even more proud about the successes we've had with
the users who show up out of nowhere, report issues and thank us, than
we should about the people we've worked closely with.

Even if these users are but a small hand full at this point, how our
breaking changes effects these people makes the largest impact in terms
of perception, and what these people are telling their colleagues goes
a long way to determining the future of our project.

Cheers,
    -Tristan