On 24/02/15 07:24, Jean-Philippe André wrote: > Ah I was wondering what took git a few extra seconds to update last time. > Ha! > > On Tue, Feb 24, 2015 at 1:41 AM, Tom Hacohen <tom.haco...@samsung.com> > wrote: > >> On 23/02/15 16:27, Cedric BAIL wrote: >>> On Mon, Feb 23, 2015 at 4:56 PM, Daniel Kolesa <dan...@octaforge.org> >> wrote: >>>> On Mon, Feb 23, 2015 at 3:55 PM, Daniel Kolesa <dan...@octaforge.org> >> wrote: >>>>> On Mon, Feb 23, 2015 at 3:50 PM, Oleksandr Shcherbina < >>>>> o.shcherb...@samsung.com> wrote: >>>>>> Sorry guys, >>>>>> >>>>>> capital letters will be changed asap. >>>>>> >>>>>> Also we plan reduce quality of resources. >>>>>> >>>>>> It example useful for testing, because gathers features together. >>>>>> >>>>>> Can you advice acceptable size for 3d models and images for >> textures? >>>>>> >>>>> >>>>> 256x256 for this kind of stuff at most (everything above that is an >>>>> overkill; i believe in most cases even 128x128 would do). Fix up the >> names >>>>> and paths (all lowercase, no spaces). Keep all textures with >> power-of-two >>>>> sizes (32, 64, 128 etc) so that mipmapping behaves correctly (and so >> that >>>>> the examples work with all versions of opengl and with all supported >>>>> hardware). As for the models, you can probably dramatically reduce >>>>> polycount on everything (and scale down the skins). Make sure the >> assets >>>>> dir stays small, 50MB is really bad. >>> >>> I think the requirement on being power-of-two is irrelevant in the >>> case of Evas as we should be using Evas_GL_Image which already does >>> automatic packing into an atlas with the right size for us (Otherwise >>> we would have trouble with all the other image we load for widgets). >>> As for size, I agree 256x256 should be enough for this example and I >>> should start paying attention to file size... >>> >>>> And yeah, as Tom said, this would best go into a separate repository. We >>>> don't really want this kind of stuff in efl.git. >>> >>> This I disagree. I think this is not orthogonal to efl. We are pushing >>> a 3d and a vector scenegraph in efl to use it for widget and >>> application. Showing how to use that infrastructure does make sense. >>> >>> Same actually goes with exactness data, as we are doing a graphical >>> toolkit and we don't have visual test in our make check. It's just a >>> shame and a bad excuse for not having it. If you really want that out >>> of the main git, I guess we could use some submodule and force make >>> check/examples to pull that part if necessary, but that doesn't feel >>> reliable at all. >>> >> >> Submodules, as I've suggested a million times before. That's the only >> sane way of doing it. >> > > Yes, submodules. > I wouldn't mind having only code in the main EFL repo and all doc, test, > examples DATA would come from submodules.
Yes, exactly. All the non-essentials should be external. We don't need to pollute history, or force people to download shit they don't need. > > Unfortunately by default Git clones the entire history, so in the current > case what's done is done. Not quite. Packagers should (and often) do shallow clones, so they won't get it if we remove it, and also, there's the advantage of not having it expanded to the working directory and giving a bad example by removing it. -- Tom. > > > >> Also, as for exactness, as I've said before, it's too fat to put here >> and too slow to put it as part of make check. It should be part of make >> check-full/slow or we should have a make check-fast that only does unit >> tests and not also the slow regression tests. This will make it >> unreasonably slow and useless for people like me who actually run make >> check on everything they do. I can't afford to wait an hour for a >> response that a unit test can easily give me. >> > > > Unrelated, but a git-hook could be installed. Like in: > http://stackoverflow.com/questions/7147699/limiting-file-size-in-git-repository > > We already have some binary files that are quite big, and the po updates > are also large commits. So need to be a bit careful, of course. But we > could sum the file sizes, filter on the binary ones only, for instance. > > We could also check for filename formats (eg. no spaces, no caps or look > for other files with same name but in a different case), etc... > > Who mentionned refusing commits with an invalid name? ;) > > > Of course we don't want our repo to become a huge pain to push commits to, > just prevent accidents such as this one. > > Best regards, > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
