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, 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.
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. 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] > > ------------------------------------------------------------------------------ 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
