Re: Dogfooding discussion

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

On Fri, 2018-06-29 at 17:56 +0100, Richard Maw wrote:
> On Wed, Jun 20, 2018 at 02:56:58PM -0400, Tristan Van Berkom wrote:
> > Hi Richard,
> >
> > On Wed, 2018-06-20 at 17:22 +0100, Richard Maw via Buildstream-list wrote:
> > > For anyone unfamiliar with the term, dogfooding means to use your own product,
> > > > see https://en.wikipedia.org/wiki/Eating_your_own_dog_food.
> > >
> > > We've let our team develop how they feel most comfortable.
> > > This predictably has not resulted in using BuildStream to develop BuildStream,
> > > since it's a new tool to us when we start
> > > and then changing afterwards is extra effort so a reason to change is needed.
> > > It's been decided that now we have a reason, and that is dogfooding.
> > >
> > > The purpose of this E-Mail is to state our intent
> > > and solicit feedback on how we propose to go about it.
> > >
> > > It is not our intention to advocate everybody develop BuildStream this way,
> > > for now we're only concerned with our team,
> > > though we hope we'll be able to recommend it as a superior experience
> > > after ironing out kinks in the workflow.
> > >
> > > We're interested in feedback,
> > > since the risk of dogfooding is optimising for our use-cases,
> > > so if our approach isn't close enough to what other users are doing
> > > we could make the experience worse.
> >
> > Hmmm, ok so my thoughts in general are: Making use of BuildStream in
> > the daily activities of developing BuildStream is good, and I think the
> > appropriate amount of that will fall into the right place if we let it
> > happen at the right time.
> >
> > By just building BuildStream with BuildStream, we cover a very small
> > surface of the BuildStream featureset; it really is the freedesktop-sdk
> > project (and GNOME project) which ensures we get fairly good usage
> > coverage of our features. If developers need a real project to test the
> > BuildStream feature they are working on, they *really* should be using
> > freedesktop-sdk or gnome-build-meta as a sample.
> >
> > As you mention, this could cause us to optimize for our own use cases;
> > worse than this, we could invent our own problems by contorting our
> > workflow into something which requires BuildStream, causing friction in
> > other areas of our development process (or inventing unnecessary
> > features).
>
> Our team doesn't develop freedesktop-sdk or gnome-build-meta though,
> so bringing them into our workflow for dogfooding purposes
> would be the same contortion you are concerned about.
>
> From my understanding one of the use-cases for BuildStream
> is to develop a single application,
> so there would be value in us developing BuildStream with BuildStream.
>
> If there's other developers working on both freedesktop-sdk or gnome-build-meta
> and BuildStream then that should work as an appropriate counter-balance
> shouldn't it?

To be clear: The gnome-build-meta and freedesktop-sdk projects are our
real world users.

If you are developing features for BuildStream:

  o I definitely expect that you are running your code and testing it
    out yourself, hunting down the edge cases yourself, beyond *only*
    relying on our regression tests.

    Regression tests are just an extra line of defense.

  o I definitely expect that you would be using a real world sample
    project which exercises a decent portion of BuildStream's feature
    surface.

    The right choices to use for testing your BuildStream work, are
    the real world projects which we are supporting with BuildStream.


Is there value in developing BuildStream with BuildStream ?

Sure, but don't expect to get good enough mileage out of that,
certainly not enough mileage to start changing things for the sake of
being dogfooding alone.

Cheers,
    -Tristan