On Wed, Aug 6, 2008 at 4:52 PM, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > > You can't tell me that im wrong as i did eina and took the decisions > about it. I have to explain this as this totally wrong. Eina's attempt > was known, i already commented about it on irc and on ml, *with* > intention to get developers contribute to it, contribute not only on > the sense of coding it, but actually *using* it to have a common data > library.
You are wrong again, I can examine the evidence and draw conclusions and I'm perfectly capable of saying that I think you're wrong. You are repeating your opinion and drawing conclusions which are not founded by the arguments you present. You worked in a repository outside of the normal project. This means only developers that explicitly want to jump into your effort will follow the activity, you won't pick up work from the project members that don't sign on. How many E related side projects have you seen become heavily adopted before they went into CVS? I can't think of any except for maybe E-Live and that was primarily because it was well linked from E.org and was an entire distribution to help users try E. Myself, I did not follow eina outside CVS mainly because we have many people mention wanting to help with things that never come to fruition. I would not be surprised if others were in the same situation. I also did not see any statements from raster that he was willing to let evas depend on an external data type lib. Without that, there was not much point to another data structure lib as it would just be more duplication. >> Nothing to do with the >> license. Cedric may have been interested because it was LGPL, but most > > Cedric was interested on the project by himself and because it was > technically good, i think having a common library for data types is > something we all agree. I think he will reply on this. And yes, the > license do has something to do with this, as *i* want it to be lgpl. As I stated in another email, that's fine for you, but not necessarily fine for broader project. >> people I know of are interested because we can finally remove some >> redundant API's. > > If so, why on the past two years, no interest on this library > (concept) has been shown? i even received comments like: ecore already > provides it and ecore means "core" so it should belong there and not > in evas/eet. kind of absurd, imho. Because you were working in an external repository. By being outside CVS it was not really part of the project. E doesn't get a ton of developer attention as it is, and you expect an unknown experimental lib developed outside the project to get more attention? Also, you mentioned previously that it was already LGPL, if you're proposing the license "change" is the driving force for interest, how was there a change? I don't really know where those comments came from so it's not up to me to defend them. >> Why don't you ask Peter since he's the other one you >> mention making some effort on it? > > Peter already stated his POV on this, he said that he wont contribute, > so his stringshare code was respected with the bsd license on top of > the file. Did i do something wrong? what happens with edata when it > was on cvs, why he didnt put up his effort there and instead made a > new library? why he didnt contact me about eina on the beginning? I > respect his decision, but looks like mine isnt respected. Assuming Peter contributed under the understanding that it was BSD licensed, then you're fine. Since eina didn't have a license in CVS, or he may not have bothered to check since everything else is BSD, he probably assumed it was BSD. It may not seem like it to you, but being in an external repository is a huge problem for something you want integrated into a bigger project and I think you're experience reinforces that. >> You are misquoting this argument. The argument is we can't easily >> inter-change code with LGPL because it's now a one way relationship. >> We can only put things INTO eina because if we take anything out, we >> have to use the LGPL or GPL. > > True, so? i understand that having that flexibility is something you > are interested on, and i respect that; but i have a different vision > there, doing that is what e has exactly been doing with no real gain, > just moving/renaming and code things on a monolithic way; and i dont > like that approach. Like you moved code from evas into eina? Evas is a large monolithic structure, and I agree that the data structures needed to be split out. There is otherwise not that much code shifting going on. What we do see here and there is a nice abstraction in a piece of code which then gets split out into a lib, and on occasion an abstraction that is really only useful in one case that gets moved into a different component. Here's a realistic example. What if I decide to use the memory pools API from eina in EWL, but we find evidence that the memory pools are actually worse in most use cases than the standard allocator (trust me this happens, I've seen it specifically with memory pools). If you remove it and break EWL, I can no longer use my discretion to pull that code into EWL specifically, even if EWL happens to be one of a few use cases that benefit from them. > Well, that's just a words game, you can call it unhealthy community, > but for me a community is exactly that the community has the power to > change how it operates, which in this case has been broken (with > eina's license) because i dont think this is a community. Maybe this speaks more about your experience than the project as a whole. I certainly feel part of a community from years of working with good people that have treated each other with respect. I have regularly seen people come through and hurt the community by refusing to work with others or don't treat others with respect. Do you feel that every new person that comes to the project should be allowed to choose a new license? re-implement an existing component? Whether you try to dismiss what I have to say as "word games" or not, you are nowhere near arguing a strong reason that you should be able to impose a license change on the project. You are basically saying "This is what I want, so that's how it should be." And if you're listening to the people on this list, many of us only want one license in the project. Seeing as the point of eina was to unify the use of data structures and utility functions, this is a very fracturing decision. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
