Re: RFC Playground
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: > 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. >> >> -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: RFC Playground
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 wrote: > 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: > > 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
Re: RFC Playground
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 < daniel.van.v...@canonical.com> 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 > 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. >> >> >> > -- > Mircosmonauts mailing list > mircosmona...@lists.canonical.com > Modify settings or unsubscribe at: https://lists.canonical.com/ > mailman/listinfo/mircosmonauts > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: RFC Playground
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 < alberto.agui...@canonical.com> wrote: > 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 < > daniel.van.v...@canonical.com> 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 >> 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. >>> >>> >>> >> -- >> Mircosmonauts mailing list >> mircosmona...@lists.canonical.com >> Modify settings or unsubscribe at: https://lists.canonical.com/ >> mailman/listinfo/mircosmonauts >> > > > -- > Mircosmonauts mailing list > mircosmona...@lists.canonical.com > Modify settings or unsubscribe at: > https://lists.canonical.com/mailman/listinfo/mircosmonauts > > -- Cemil Azizoglu Mir Display Server - Team Lead Canonical USA -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: RFC Playground
On Wed, Apr 1, 2015 at 6:50 PM, Cemil Azizoglu wrote: > 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. > > 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 > 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 < > alberto.agui...@canonical.com> wrote: > >> 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 < >> daniel.van.v...@canonical.com> 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 >>> 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. >>> -- >>> Mircosmonauts mailing list >>> mircosmona...@lists.canonical.com >>> Modify settings or unsubscribe at: https://lists.canonical.com/ >>> mailman/listinfo/mircosmonauts >>> >> >> >> -- >> Mircosmonauts mailing list >> mircosmona...@lists.canonical.com >> Modify settings or unsubscribe at: >> https://lists.canonical.com/mailman/listinfo/mircosmonauts >> >> > > > -- > Cemil Azizoglu > Mir Display Server - Team Lead > Canonical USA > > -- > Mircosmonauts mailing list > mircosmona...@lists.canonica
Re: RFC Playground
+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 wrote: > 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 < > alberto.agui...@canonical.com> wrote: > >> 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 < >> daniel.van.v...@canonical.com> 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 >>> 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. >>> -- >>> Mircosmonauts mailing list >>> mircosmona...@lists.canonical.com >>> Modify settings or unsubscribe at: https://lists.canonical.com/ >>> mailman/listinfo/mircosmonauts >>> >> >> >> -- >> Mircosmonauts mailing list >> mircosmona...@lists.canonical.com >> Modify settings or unsubscribe at: >> https://lists.canonical.com/mailman/listinfo/mircosmonauts >> >> > > > -- > Cemil Azizoglu > Mir Display Server - Team Lead > Canonical USA > > -- > Mircosmonauts mailing list > mircosmona...@lists.canonical.com > Modify settings or unsubscribe at: > https://lists.canonical.com/mailman/listinfo/mircosmonauts > > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscri
Re: RFC Playground
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: 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 mailto:daniel.van.v...@canonical.com>> 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 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 t
