On 7/8/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > Hi guys, > > > Recent discussions about config dialogs being moved to modules leads me > to a question I've been asking myself quite often recently. I'm working > on the E-project for at least a couple of years now, and actually, I > still can't tell what is the scope of this project? How would you > define it? >
This is a question that needs to be answered both on this thread and later made into a more formal goal on our website. We can not keep our plans in our head and to ourselves. > Are we just working on a WM or are we trying to have a decent desktop > environment? If we are working on a WM, should it include a FM (well.. > it seems so..), should it have its own toolkit (it seems so > too...)? Does it aim to be a WM for desktop configs or for embedded > devices? And if this project is about getting a nice desktop > environment, what apps should be part of it? What should be the "point > in common" of all these apps? Is using the EFL enough to be a part of > the environment? Or maybe we should have guidelines that all the apps > would have to respect (like the Gnome HIG)?! > I'm pretty sure that we can't find two devs with the exact same > definition of the project. We all see it differently! If we want to go to what we had in mind a few years ago, then E should be a WM with a "bit more functionality". The term used back then was (and still is) "desktop shell", What exactly is that? Thats a question we need to answer. After several discussions with lots of developers, I managed to find out that they are interested in a bit more than that. They want to create a development platform that people can use and rely on for personal computing applications and embedded applications. > In these conditions, how can we work together on this? If this a > one-man project, it's ok to share nothing.. But since it *tends* to be a > community project, we need to share ideas and to establish a common > project on which we all agree! If I could have known two years ago that > e17 would now have its own toolkit, its own FM, its config dialogs > moved to modules, shelves and a lot of other recent changes that I > don't necessarily agree with, I would probably have not spent so much > time on this project.. And I know I'm not the only dev feeling like > this right now... It would be nice if "evolutions" were discussed > publicly on the ML. For now, it just seems that when one dev wants a > new feature, he implements it without asking others what they think > about it. And most of these new features were not even in the TODO list > before... This again boils down to the issue of having a clear goal for the project in mind. The issue here is that saying what you want to finally reach is not good enough. You need to be clear about how and when you want to reach it. Any changes along the way need to be brought up and discussed. I'm not saying we need to discuss everything, but it would be nice (and helpful) to discuss the bigger changes and plans that affect the entire project and its goal(s). > Personally, I don't think I will ever commit any other code to this CVS > (on Etk mainly) if I don't feel the situation has changed (i.e. if we > don't have a precise roadmap and if we don't have defined precisely > the scope of the project). I'll probably just move Etk and other > projects I have in mind to another place. It's not a threat or > blackmail (anyway, I'm pretty sure most of the devs working on e17 > don't even care about Etk...), I just don't see why I would share a CVS > with a project that I can't even define and that I can't even tell where > it is heading toward.. The more important point, aside all of this, that we *need* to address, is that of decision making. We all know that raster (himself included) is too busy to handle everything by himself. Patches take ages to review, emails take ages to answer, decisions take a long time as well. So, given that, what can we do about it? The way I see it, we have several options. One of the options would be to assign a maintainer to each piece of code in our CVS. That maintainer should obviously know the code very well and should be able to take a decision about a feature improvement, an addition, a patch, a major redesign, and API break, etc... When things have to do with that piece of code, anyone can obviously pitch in, but it will be more or less his decision. If he is too busy, that person can have a "helper" that is also knowledgeable about that code and can take a decision. This should help the entire lag we always have with emails, patches, features, etc. finding their way into our CVS. I personally think that this is one of the best ways to handle this issue. Another way would be to simply discuss something on the mailing list, and if the developer is knowledgeable about the code he is working on, he can simply commit it if no one minds it. I would like to go with the first option though. It is a much more structured and organized approach. Examples of the problems we have run into include a lot of code that was going to be committed to Evas and Ecore. That code never made it for several reasons. Firstly, it was never really reviewed and given its fair share of time. Secondly, the "API break in a core library" issue was raised. And what was the result of that? Good (hopefully) code was discarded and we lost the developers (hopefully they will want to come back and work on the code if we let it in). So what if we have an API break? We can take care of it - we have not even made a stable release yet! If a developer takes the time to improve something that no one else has the time (or will) to work on, and it results in an API break, lets get his code into CVS (on the condition that he fixes the core libraries and applications that are affected). What are the core libraries and applications? Thats a good question that we need to answer as a community and as a group of developers. We have to face it people, over the past few of years, we have wasted a lot of time and a lot of talent because we have been waiting for E to be released. And with all of those new features being put aside (for Evas, Ecore, Edje, etc.), has E been released yet? No, it has not. Has it come closer to a release? Certainly. But, whats the harm in letting someone work, in parallel, on a library then merge it into CVS as a better, faster, leaner library, and supply patches to fix anything resulting in an API break? Folks, please take the time to answer these emails properly. We're talking about the future of this entire project here. It has grown beyond being a simply toy WM, its becoming a real development environment that is attracting more and more people every day. We should plan and do things properly to attract (and keep) as much users and developers as possible. Do not ignore this, do not dismiss it, take the time to discuss these issues (and any others you might have) for the sake of the project and its future. Regards, hisham. -- Hisham Mardam Bey http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
