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
