Could we look at this the other way around? Say you must add a test and the harnesses will get better out of necessity?
It is said that legacy code is any that does not have automated test coverage ;) Andy On Tue, 3 Jan 2017 at 23:29, Carsten Haitzler <[email protected]> wrote: > On Tue, 03 Jan 2017 15:14:55 +0000 Mike Blumenkrantz > <[email protected]> said: > > > To elaborate, my issue in this case is that the test plan is "Tizen 3.0" > as > > though that's something that can be tested. Yes, the issue is described, > > i know. it's "stupid". to the point where i ignore it. realistically just > leave > it blank instead of fill it in with a pointless test plan. a test plan > should > be "run app x, do action y, see if thing z happens or not" or "make check: > test > xyz fails or succeeds" which might be better as its automated. :) and > that's > where i'm picking this up from... :) > > > but for most bug fixes the test plan is something like "follow steps 1, > 2, > > 3 in app XYZ", where XYZ is a publicly available and easily executed app. > > dude. do you know how many "tizen custom" patches efl in tizen has? it's > 1000+. > it's also efl 1.16 plus 1000+ patches. it's missing lots of fixes and > improvements in 1.17, 1.18, so there is very little hope of reproducing > anything really equivalent... > > > In cases such as this one, the burden is now on upstream developers to > > create a new test case according to the listed steps (which may or may > not > > be accurately described) in order to verify that the issue has not > > regressed. This is not going to scale based on our available resources. > > i know it won't. we do need to reduce the work needed to add a test > regardless > so it's EASY to say "you must add a test". right now it's not easy to ask > that > of people. > > > On Mon, Jan 2, 2017 at 6:33 PM Carsten Haitzler <[email protected]> > > wrote: > > > > > On Mon, 02 Jan 2017 15:50:28 +0000 Mike Blumenkrantz > > > <[email protected]> said: > > > > > > > Hi, > > > > > > > > I am not sure that "Tizen 3.0" is a valid test plan for our > purposes. If > > > a > > > > fix is submitted upstream, I think it makes sense to also submit a > > > > corresponding test to verify that the issue is solved and does not > recur > > > in > > > > the future. > > > > > > i'm not so sure that "test plan" is worth paying attention to... > > > > > > BUT... "for every bug you fix with an @fix as it was an existing bug > in a > > > release, provide a test case to check for the bug so it doesn't come > back" > > > is > > > what i think you are getting at. > > > > > > at this stage that'd raise the cost of doing bug fixes a LOT. i think > we > > > need > > > to improve our testing harness first - e.g. a thread a few weeks back > about > > > this. we need a far simpler way to put tests together. we also need > good > > > "template" harnesses - e.g. a raw evas canvas test that sets up a > canvas > > > with > > > some default state (a white, pink, blue, green rect background or > > > transparent) > > > then you can do things like: > > > > > > code1(); > > > code2(); > > > CHECK(); > > > code3(); > > > code4(); > > > code5(); > > > CHECK(); > > > code6(); > > > ... > > > > > > which would force manual renders of the state at the time when you > > > CHECK(); and > > > save an image and compare against a known good one (stored in tree) > etc. > > > etc. > > > as well as just drop that test into a dir without having to modify > > > makefiles > > > and thus basically do a full rebuild (autogen etc.) just to begin to do > > > testing. > > > > > > before we start making rules like this - we should get our testing > harness > > > into > > > an optimal state. > > > > > > > Thoughts? > > > > > > > > On Mon, Jan 2, 2017 at 2:44 AM Minkyoung Kim <[email protected]> > > > wrote: > > > > > > > > > jpeg pushed a commit to branch master. > > > > > > > > > > > > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=40e9da0101e2c9afb6f823c7b21c02a011cc5300 > > > > > > > > > > commit 40e9da0101e2c9afb6f823c7b21c02a011cc5300 > > > > > Author: Minkyoung Kim <[email protected]> > > > > > Date: Mon Jan 2 15:29:48 2017 +0900 > > > > > > > > > > Evas GL:Bind texture to correct one. > > > > > > > > > > Summary: > > > > > If user bind textureA and want to use it continuously, do not > call > > > > > glBindTexture(textureA) again. > > > > > But expect that textureA will be binding. > > > > > So EvasGL sould not change binded texture silently. > > > > > Restore texture to previous bound one after allocating new > texture. > > > > > And when destroy texture, reset texture to 0 if it is current > bound > > > > > texture. > > > > > > > > > > Test Plan: Tizen 3.0 > > > > > > > > > > Reviewers: wonsik, dkdk, cedric, jpeg > > > > > > > > > > Reviewed By: jpeg > > > > > > > > > > Differential Revision: https://phab.enlightenment.org/D4524 > > > > > --- > > > > > src/modules/evas/engines/gl_common/evas_gl_core.c | 9 ++++++++- > > > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c > > > > > b/src/modules/evas/engines/gl_common/evas_gl_core.c > > > > > index 14d17f6..8292b5c 100644 > > > > > --- a/src/modules/evas/engines/gl_common/evas_gl_core.c > > > > > +++ b/src/modules/evas/engines/gl_common/evas_gl_core.c > > > > > @@ -234,19 +234,26 @@ _texture_allocate_2d(GLuint tex, GLint ifmt, > > > GLenum > > > > > fmt, GLenum type, int w, int > > > > > { > > > > > //if (!(*tex)) > > > > > // glGenTextures(1, tex); > > > > > + GLint curr_tex = 0; > > > > > + glGetIntegerv(GL_TEXTURE_BINDING_2D, &curr_tex); > > > > > + > > > > > glBindTexture(GL_TEXTURE_2D, tex); > > > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, > > > GL_CLAMP_TO_EDGE); > > > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, > > > GL_CLAMP_TO_EDGE); > > > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, > GL_NEAREST); > > > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, > GL_NEAREST); > > > > > glTexImage2D(GL_TEXTURE_2D, 0, ifmt, w, h, 0, fmt, type, NULL); > > > > > - glBindTexture(GL_TEXTURE_2D, 0); > > > > > + glBindTexture(GL_TEXTURE_2D, (GLuint)curr_tex); > > > > > } > > > > > > > > > > // Destroy Texture > > > > > static void > > > > > _texture_destroy(GLuint *tex) > > > > > { > > > > > + GLint curr_tex = 0; > > > > > + glGetIntegerv(GL_TEXTURE_BINDING_2D, &curr_tex); > > > > > + > > > > > + if ((GLuint)curr_tex == *tex) glBindTexture(GL_TEXTURE_2D, 0); > > > > > if (*tex) > > > > > { > > > > > glDeleteTextures(1, tex); > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) [email protected] > > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
