On Wed, Apr 1, 2015 at 6:50 PM, Cemil Azizoglu <cemil.azizo...@canonical.com > 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.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
