Subject: Re: RFC Playground

From: Daniel van Vugt <[email-masked]>
Date: Wed, 01 Apr 2015 09:40:58 +0800

Last I checked mir_proving_server was more functional and less buggy 
than our other example servers. That and our colleagues tend to use it 
as their primary development platform when testing toolkit/app ports. So 
mir_proving_server is important and should be reworked to use any newer 
APIs you would prefer it to use.

I know it's frustrating the number of regressions we've had this past 
week or so. But to blame the functionality that regressed more than the 
person who regressed it I think is disproportionate.

Yeah that "god" function is annoying. It needs to be teased apart. I can 
help with that but it's not a major priority right now.

Please try to avoid belittling the project by using words like 
"playground" and "dark corner". It's important and useful example code 
that myself and others use every day to do our jobs. So if you want it 
modernised, let's do it.

On 31/03/15 21:12, Alan Griffiths wrote:
> There's a bunch of code in the mir project that isn't needed for
> supporting the public interfaces (neither by implementing them, testing
> them nor demonstrating their use). This code lies in "playground" and
> shares that location with the following README:
>
>     The Playground
>
>     These are mir demos that excercise private in-flux mir functionality.
>     As such functionality matures, related headers become public and the
>     playground
>     code may become an example of how to use such feature.
>
> It has now been some time since any functionality has "matured" from
> playground and become public (either as APIs or examples). I don't see
> any evidence that the code there is being developed toward such an event
> in the foreseeable future.
>
> The requirement to support this code is becoming a burden as it makes
> use of internal APIs in a way that limits the evolution of Mir
> internals. Updating the code is also costly as it has grown in an
> uncontrolled manner (most of the logic seems to be in one 223 line "god"
> function). Because it not under test to the same extent as Mir
> production code we've had a number of breakages to this code land on
> trunk recently (often to features I wasn't previously aware of).
>
> So the questions:
>
> 1. Does "playground" still provide a proving ground for new code to
> germinate? Or is it dark corner for legacy code to go and die?
> 2. Do we still need a proving ground like this? Or do our public APIs
> now support enough functionality to drive feature development?
> 3. If we still need a proving ground is it desirable to rework this code
> to be better aligned with the rest of the project?
> 4. If we don't need "playground" is there anything we need to provide
> before dropping it from the project.
>
>

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 01 Apr 2015 11:02:03 +0100

Despite your tone it appears that we agree that "playground" (I'm not
belittling - that name has nothing to do with me) no longer serves its
stated purpose: there is no "private in-flux mir functionality" there.

What is there is mir_proving_server which is useful to you and "our
colleagues testing toolkit/app ports". At the very least that suggests
that the name and README are misleading. If mir_proving_server is an
important deliverable it should be maintained as such - not as
"playground" code. Maintaining as an important deliverable means using
the recommended (public and tested) APIs and tests. (In contrast even
our "examples" code is run in the CI environment.)

The question is then whether it is simpler to fix mir_proving_server (by
updating the implementation) or to fix mir_demo_server (by adding the
missing functionality).

On 01/04/15 02:40, Daniel van Vugt wrote:
> as their primary development platform when testing toolkit/app ports.
> So mir_proving_server is important and should be reworked to use any
> newer APIs you would prefer it to use.
>
> week or so. But to blame the functionality that regressed more than
> the person who regressed it I think is disproportionate.
>
> Yeah that "god" function is annoying. It needs to be teased apart. I
> can help with that but it's not a major priority right now.
>

---

From: Kevin DuBois <[email-masked]>
Date: Wed, 1 Apr 2015 08:36:03 -0400

The proving server definitely needs to move out of playground/, and rely on
the public API's. I would think that the public api's are more-or-less
equivalent to what the proving_server is doing privately, and where they
differ is a healthy topic to explore what we want to do about it. IMHO, We
twist the server's interfaces and object structure a bit to support the
proving server, as it has private access to the mir code, and can add
functions to core mir objects without the scrutiny that we should be giving
to public API changes.

I tried to port the proving server to use the newer window manager
infrastructure on Friday (a line of work that ended up being
~kdub/mir/public-scene-element) I think that porting is semi-possible,
although I got tangled up in me::WindowManager::handle, which would benefit
as a first step from porting to MirEvent 2.0. I also think that examining
what features from the proving server we want to port is healthy. Just
because the proving server has a certain feature doesn't seem a good reason
to invest the time in porting the feature over, especially if we can make a
reasonable argument that the feature is doable from the public API.

That leads to the topic of effort... bzr rm playground/ seems a lot easier
than porting me::WindowManager::handle function, especially if we in our
individual development routine don't tend to use the proving server often,
have gotten accustomed to the demo servers, or think the feature gap is
just a question of investment of time. For my typical tests, the proving
and demo servers have become mostly coincidental in what I want to test
with them.

Kevin

On Wed, Apr 1, 2015 at 6:02 AM, Alan Griffiths <[email-masked]
> wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Alberto Aguirre <[email-masked]>
Date: Wed, 1 Apr 2015 11:03:39 -0500

Once we release mir 0.13 we can tell our colleagues to use mir_demo_server
instead.

>From what I can see, features missing from the demo server in comparison to
proving server are mostly cosmetic. If they are not, can Daniel list the
features that are missing?

On Tue, Mar 31, 2015 at 8:40 PM, Daniel van Vugt <
[email-masked]> wrote:

> Last I checked mir_proving_server was more functional and less buggy than
> our other example servers. That and our colleagues tend to use it as their
> primary development platform when testing toolkit/app ports. So
> I know it's frustrating the number of regressions we've had this past week
> or so. But to blame the functionality that regressed more than the person
> who regressed it I think is disproportionate.
>
> "playground" and "dark corner". It's important and useful example code that
> myself and others use every day to do our jobs. So if you want it
> modernised, let's do it.
>
>
>
> Mircosmonauts mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.canonical.com/
> mailman/listinfo/mircosmonauts
>

---

From: Cemil Azizoglu <[email-masked]>
Date: Wed, 1 Apr 2015 11:50:01 -0500

I agree with Alberto that we should try to get (people) away from using
playground as a validation tool and onto mir_demo_server (after 0.13). We
then move the renderer related things to the public realm.

Reiterating the original intent of the playground area : An area to
experiment with interfaces without having to publish them, with the idea
that, should they be deemed useful, they will be published eventually, or
be deleted.

If there is any other use (besides as a validation tool for the toolkit
developers in the interim) for it, we should discuss and perhaps support it
via other means.

Thanks
Cemil

On Wed, Apr 1, 2015 at 11:03 AM, Alberto Aguirre <
[email-masked]> wrote:

> From what I can see, features missing from the demo server in comparison
> to proving server are mostly cosmetic. If they are not, can Daniel list the
> https://lists.canonical.com/mailman/listinfo/mircosmonauts
>
>

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Thomas Voß <[email-masked]>
Date: Wed, 1 Apr 2015 20:08:01 +0200

On Wed, Apr 1, 2015 at 6:50 PM, Cemil Azizoglu <[email-masked]

> that, should they be deemed useful, they will be published eventually, or
​I might have missed the original conversation, but why not call it "labs"?
Highly experimental, potentially dangerous stuff that is a lot of fun to
play with?

In addition, there is a clear concept of graduating useful code out of the
labs area into the production code base.

At any rate: We should *not* rely on non-production code to validate any
code outside of Mir.

Cheers,

  Thomas​

>> Once we release mir 0.13 we can tell our colleagues to use
>> mir_demo_server instead.
>>
>>> than our other example servers. That and our colleagues tend to use it as
>>> their primary development platform when testing toolkit/app ports. So

---

From: Robert Carr <[email-masked]>
Date: Wed, 1 Apr 2015 16:31:07 -0700

+1 for removal. I'm not aware of any downstream requirements for features
in proving server. I'm also not aware of any downstream intentions to
customize the renderer in the fashion used by proving server.

On Wed, Apr 1, 2015 at 9:50 AM, Cemil Azizoglu <[email-masked]

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 02 Apr 2015 10:36:36 +0800

All the features are useful. And use of the word "playground" was not my 
choice (I was outvoted). They have all been used to develop other 
features or to diagnose bugs in Mir, or soon will be used when I find 
the time. By function you can see them documented here:
http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/demo_shell_controls.md

The "cosmetic" stuff is also very useful. Shadows for example make the 
stacking order obvious. Title bars show you that you have the correct 
title string and that the new API for that works. Which I needed just 
recently. The zoom feature I've used repeatedly to see fine pixel 
details and even yesterday as an aid in measuring latency.

I use mir_proving_server every day. It helps me to find bugs that no one 
else on the team is noticing (but should). Management has asked me on a 
couple of occasions "what is your trick to finding bugs that nobody else 
does?". The answer is daily manual testing with mir_proving_server.

It's also worth noting that one of Cemil's first contributions (seamless 
rotation) would not have been possible without mir_proving_server. And 
Gerry uses mir_proving_server regularly to compare features. Including 
yesterday, he used it to test resizing, which is more feature complete 
in mir_proving_server than elsewhere.

Most importantly however, something slightly pretty motivates people to 
get involved. Either directly in Mir or downstream, it allows them to 
see potential for Mir which is impossible for most people to see in flat 
rectangles. Sparking peoples' imagination is invaluable.

Something like this that people use every day should not be deleted. 
That would be most unhelpful. But mold it into some slightly different 
form, sure.

On 02/04/15 00:03, Alberto Aguirre wrote:
>  From what I can see, features missing from the demo server in
> comparison to proving server are mostly cosmetic. If they are not, can
> Daniel list the features that are missing?
>
>
>
> On Tue, Mar 31, 2015 at 8:40 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     than our other example servers. That and our colleagues tend to use
>     it as their primary development platform when testing toolkit/app
>     ports. So mir_proving_server is important and should be reworked to
>     use any newer APIs you would prefer it to use.
>
>     I know it's frustrating the number of regressions we've had this
>     past week or so. But to blame the functionality that regressed more
>     than the person who regressed it I think is disproportionate.
>
>     "playground" and "dark corner". It's important and useful example
>     code that myself and others use every day to do our jobs. So if you
>     want it modernised, let's do it.
>
>
>
>     [email-masked]
>     <mailto:[email-masked]>
>     https://lists.canonical.com/__mailman/listinfo/mircosmonauts
>     <https://lists.canonical.com/mailman/listinfo/mircosmonauts>
>
>

---

From: Thomas Voß <[email-masked]>
Date: Thu, 2 Apr 2015 09:50:22 +0200

On Thu, Apr 2, 2015 at 4:36 AM, Daniel van Vugt <
[email-masked]> wrote:

> choice (I was outvoted). They have all been used to develop other features
> or to diagnose bugs in Mir, or soon will be used when I find the time. By
> function you can see them documented here:
> http://bazaar.launchpad.net/~mir-team/mir/development-
> branch/view/head:/doc/demo_shell_controls.md
>
> stacking order obvious. Title bars show you that you have the correct title
> string and that the new API for that works. Which I needed just recently.
> The zoom feature I've used repeatedly to see fine pixel details and even
> yesterday as an aid in measuring latency.
>
> yesterday, he used it to test resizing, which is more feature complete in
> mir_proving_server than elsewhere.
>
> get involved. Either directly in Mir or downstream, it allows them to see
> potential for Mir which is impossible for most people to see in flat
> Something like this that people use every day should not be deleted. That
> would be most unhelpful. But mold it into some slightly different form,
> sure.
>
>
​I'm not sure where your reservation arises from, but no one proposes to
delete useful code. On the contrary, people appreciate the usefulness of
the code and propose to graduate it to the production base such that it is
under test and guaranteed to be working.​

Thanks,

  Thomas

---

From: Cemil Azizoglu <[email-masked]>
Date: Thu, 2 Apr 2015 11:51:34 -0500

Definitely not suggesting it's not useful, or that we should remove it. But
"playground" (I am not a big fan of the name either) has one specific
purpose stated previously but now includes code that doesn't contribute to
that purpose (again, it does contribute to other just as useful purposes).

What I'm suggesting is we should migrate to public whatever we think should
be public, so you got solid support for that code. The rest should move
elsewhere (perhaps "internal examples" as opposed to "examples" which I'd
consider external)  and even perhaps off the tree.

Regards,
Cemil

---

From: Robert Carr <[email-masked]>
Date: Thu, 2 Apr 2015 11:15:10 -0700

>> Definitely not suggesting it's not useful, or that we should remove it.

I am suggesting both. I think we've found uses for it given its existence
but it's existence is overall harmful.

I think mir_demo_server is just as useful for testing downstream projects.
Neither is useful for testing Unity8. For testing QtUbuntu or testing
client behavior I think it is most useful to use something assembled from
the public components of Mir.

It's true that as it stands mir_proving_server more closely approximates
realistic WM functionality as it stands: but why would this matter? It
doesn't constitute progress on the Mir-product.

The harm comes out of the cost to support it, both in the pulls it makes on
interfaces, and in the features (and bugs) it creates.

I speculate we are having this discussion as a proxy about an unsettled
disagreement about how implement the shell rather than serious belief in
the merit of using proving server for product testing.

Thanks,
Robert

On Thu, Apr 2, 2015 at 9:51 AM, Cemil Azizoglu <[email-masked]

> Definitely not suggesting it's not useful, or that we should remove it.
> But "playground" (I am not a big fan of the name either) has one specific
> What I'm suggesting is we should migrate to public whatever we think
> should be public, so you got solid support for that code. The rest should
> move elsewhere (perhaps "internal examples" as opposed to "examples" which
> I'd consider external)  and even perhaps off the tree.
>
> Regards,
> Cemil
>
>
>

---

From: Kevin Gunn <[email-masked]>
Date: Thu, 2 Apr 2015 13:20:02 -0500

First, I agree, with moving useful/mature features to mir_demo_server. To
the name "playground" and voting, if it was voted on and implemented we
should follow the convention. Or rename & update readmes...we just need to
fix it.
What we have at the moment seems contradictory and confusing (e.g.
encouraging toolkits to test with proving, but demo only uses what's
public, and a readme that indicates things in playground are in
flux...where proving is).

I would like to voice a tangential concern. If today Daniel is using
mir_proving_server and catches bugs and the rest of the team is not, why is
that happening?
I would suggest that we need to (at best) we get features under automated
test or (at worst) Daniel should document the manual desk testing so this
can be applied to our mir release testing. And if documented, it can be
shared, kept up to date and referenced for following as part of testing.

Moreover, we should have a goal of placing features that are "useful" under
test immediately as they are developed. Otherwise it's a setup for endless
regression-fixing cycles. We as a team can't claim to have a feature we
care about, and then not make it part of our test runs.

br,kg