On Fri, Feb 27, 2015 at 11:08 AM, Daniel Kolesa <dan...@octaforge.org> wrote: > On Fri, Feb 27, 2015 at 7:41 AM, Stefan Schmidt <ste...@datenfreihafen.org> > wrote: >> On 26/02/15 23:08, Daniel Kolesa wrote: >> > On Thu, Feb 26, 2015 at 9:29 PM, Cedric BAIL <cedric.b...@free.fr> >> wrote: >> >> On Thu, Feb 26, 2015 at 8:53 PM, Daniel Kolesa <dan...@octaforge.org> >> >> wrote: >> >>> On Thu, Feb 26, 2015 at 7:19 PM, Cedric BAIL <cedric.b...@free.fr> >> >> wrote: >> >>>> On Thu, Feb 26, 2015 at 11:19 AM, Tom Hacohen < >> tom.haco...@samsung.com> >> >>>> wrote: >> >>>>> On 25/02/15 14:52, Cedric BAIL wrote: >> >>>>>> On Mon, Feb 23, 2015 at 5:41 PM, 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. >> >>>>>> submodule only bring pain and agony to its users last time I tested >> >>>>>> them. And the web is still full of complains so nothing did change >> >>>>>> there, but you are welcome to enlighten me on how great they are. >> >>>>> submodule are quite easy to use, but yeah, I guess they are a bit >> >>>>> annoying for noobs. Luckily, we are not going to use them for >> anything >> >>>>> that matters for the non technical user, we are only going to use it >> >> for >> >>>>> external shit no one uses anyway. >> >>>> Seriously ? Either you never used submodule and are a complete >> >>>> ignorant, or you want to inflict pain on other and cripple EFL with >> >>>> problem. Everyone who used submodule will have lost commit, feel the >> >>>> pain of managing a branch or rebasing work while working with others. >> >>>> submodule is a sure recipe for poor quality delivered to user. Just >> >>>> use google to search about all the bad experience that come out of >> >>>> submodule (You don't even need to search for bad experience >> >>>> specifically, just google "git submodule" and you already have on the >> >>>> first page web page that explain why you should not use them...). >> >>> I've used submodules successfully for similar purposes. Stop saying >> >>> bullshit. They work just fine for this kind of stuff - people get >> >> problems >> >>> when they use them wrong (for example when subtree should've been used >> >>> instead); for an optional repo (and examples ARE optional) it's >> perfectly >> >>> fine and easy to manage. >> >> Bullshit is not a valid argument to dismiss the fact that git >> >> submodule work by using a detached HEAD. That's what create problem >> >> and that didn't change in the past years as far as I know. How many >> >> people where active daily on your project where you used them ? How >> >> many branch did you manage ? The fact it worked for you is not a valid >> >> argument. Addressing the problem it create, would be. >> >> >> > There is no problem, because majority of people are not even interested >> in >> > downloading examples (look at how often "make examples" is broken - and >> > nobody cares until release, when distcheck fails). >> >> Distcheck has nothing whatsoever to do with the examples. No idea why >> you are mixing up these two targets here. >> > > I thought distcheck tried to compile examples. I may be wrong though. > >> > By using a submodule you >> > essentially allow people who are not interested in downloading them not >> to >> > download them, and those who want them can easily pull them in. They do >> NOT >> > belong into the primary repo. >> >> As so often we are mixing various things into one argument on this list. >> Maybe one of the reasons we seldom come to clear decisions here. :) >> >> o You and Tom don't want them in I heard no one else complain about it. >> Personally I like them in tree simply because it makes them easier for >> developers to find and look at when testing out some new APIs or features. >> > > Relatively few actually do so. Those that do can "git submodule init; git > submodule update" very easily. > > >> o On the other hand getting 50MB of resources is for just an example if >> for sure to much. This case is similar to the ephysics demo game which >> is also not in examples. Normal examples are fine though in my book. >> > > If we encourage storage of examples in the main repo, we also sort of > encourage this kind of binary dumps, and this recent issue proves that. > > >> o Getting this patch with 50MB resources plus broken names in should >> have really been caught during the review and pushed back on. >> > > Yes. But nobody did until I pointed it out. > > >> o If we look at the recent example why examples (pun intended) have been >> broken that was the EO change. And clearly Tom is not running make >> examples because he dislikes this so much. :) >> o If you really want to move them into a submodule you should start >> answering Cedric's questions about them and not simply stating its fine >> and ignoring his technical objections. > > > Dude... Cedric hasn't even presented any decent technical objections. All > he kept saying was "people complain about them, so they must be bad"... how > about some real technical arguments?
I have : "Everyone who used submodule will have lost commit, feel the pain of managing a branch or rebasing work while working with others. submodule is a sure recipe for poor quality delivered to user." That should have been enough for anyone who used submodule to know what I mean, but let me be explicit so that even the one who didn't use it can give their feedback. First loosing commit. As I said before, submodule runs on a detached HEAD. It is quite common to forget that and just commit on top of that detached HEAD. Nothing prevent you from doing it and you can use the commit ID for the submodule without trouble... Until someone does a commit on the real HEAD of the git submodule tree, and then your commit just vanish... without any notice, so it can takes time until you do notice that it is gone. Now the most painful experience is with branch. Imagine you have a branch with multiple commit in your example (It means multiple commit in efl tree and the same amount in your examples branch). Now someone does a commit in example in master. You need to rebase, first the examples branch and then your efl branch. Their every commit will conflict and you will have to find the new commit ID from the example branch for each of those commit. As I said, pain ! Finally the recipe for poor quality. First the fact, as you pointed, that their will be even less developers that will care about that submodule and wont even download it. That won't help the quality of the examples at all in my opinion, quite the opposite. Also their will be more risk for the release manager to not forget to update submodule before he does the packaging. Some of this problem are technical other are humans and I don't see how you are going to fix those nor do I see any benefit for the project. -- Cedric BAIL ------------------------------------------------------------------------------ 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
