On Mon, 9 Jul 2007 01:50:44 +0300 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled:
Simon - I know your mail has been lingering in my inbox for a while - but since it's out here... > 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. On a personal level - My goals STILL is to create a WM - a flexible one with "extra features" (the desktop shell) enough to launch what apps you need/want, manage them, access your files and configure your basic system/UI (that E can control). Creating libraries along the way to get there is a bi-product. I want the libs and apps to scale from low-end to high end (and that does imply embedded systems these days). But in doing this this opens up a whole host of new "mini-projects" which, IMHO should have a life of their own and do whatever the authors want them to do. The reason for this is that I'd like to keep control decentralised. I would prefer that we keep our goals small and realistic - something we can achieve in a reasonable time-frame. A whole desktop environment is a huge undertaking if you want to be on-par with others calling themselves that. If we aim for less, we can get there, then of course reach out further if needed/wanted. IMHO aiming for a desktop shell is doable - for a WM. Aiming for being able to do all that is needed for embedded devices is doable as it's a more limited problem space than the desktop "in general" as it mostly means building lots of mechanism and ability, with flair and style, rather than massive incredibly full featured apps. > > 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). I wish I had time for more discussion. Though frankly - if I discussed everything I did - I would be doing nothing. You may have noticed how little e-mail I keep up with these days. > > 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. I want - and have always wanted - people to make their OWN decisions. Within their fields of interest/responsibility etc. You do ETK stuff - make your own decisions. Do EWL stuff - same thing. Want to write image viewers - same thing. Like to write a media app? Same story. > 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. Agreed. And stuff that doesn't have a maintainer? (We are going to have a large chunk of code like that...) > 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). Breaking API's is serious work. Especially once it is heavily used and the effects of such a break mean changing 100's of files in CVS and more. That's life with API's. We need to evaluate every break and decide if it is REALLY needed OR if it can be done differently or it's not important enough to warrant the break. > 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 every break could be anything from almost no work to huge amounts to fix - for one small change. As above - we need to weight it up. Yes we CAN break the API right now - but there is a price to pay. Once we release 1.0 - we can't break the API until 2.0 - and that will cost us even more as people will then have more code outside our repo depending on EFL and thus the break affects and even wider audience. > 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. Not always. All breaks need to be examined. Sometimes it's just frivolous. Sometimes it can be done differently. Sometimes it's an indicator of a larger problem at hand that should be fixed - but not in the way the proposed change/break is being done. > 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? As long as they can fix the break - and it's warranted - sure. We have done this several times already in the past - so we are not closed to this. I would like to think that if we miss things it's due to being understaffed - unlike "GNOME" and "KDE" etc. we don't have dozens of fulltime PAID people working on E - Having 1000 "part time developers" is like herding cats. It's hard. You have few people with deep and/or broad knowledge. There is too little time to get that. People will have very limited views. We have done a pretty good job, IMHO, relative to our resources. > 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. Definitely - as I said. I do not want to LIMIT things. But I want to decentralise. I want people to take control OF their domain. I want separated domains of control and development to encourage parallelism. I am limiting my goals for E (the WM) so I can get it done. In the future it may expand, but until then - it's limited. E itself is moving along pretty well - except a bit more slowly as of late. It does have a TODO list - it's not badly organised. I have limited myself to "Core EFL". Recently I have allowed our "dependency freeze" to crack and we now use efreet and e_dbus. But I need to stay focused on what I have been doing to get it done. I need to put in place all the things needed to expand it in future without breaking it (or breaking it too badly), and yet still keep performance good. Eet is pretty solid and not going anywhere real soon. This is a good sign. It's stable. Evas is a solid canvas - but can do with improvements in functionality (of course) and internals. I am very happy with its API all-in-all. It's back-end can do with work, but this can be done behind the scenes without breaks in API's. Ecore just grows and grows - The intent is to eventually split ecore into N ecore_xyz libs that are 100% separate builds. Edje is powerful and works. It can do with lots of extra features, but there is enough to build on now, and no need to really break anything there IMHO. Embryo is pretty solid and not going anywhere - unless someone has something they ABOSLUTELY must have there, I see nothing to be gained here. It's stable and ready to roll. Sure the compiler code is UUUUUGLY, but it works. That covers the core stuff. Emotion is there and works - it can do with some expansion of API's to cover some missing controls for things like TV tuners, but all in all it's api is nice, powerful and works. Rage - it's a personal thing there and I'd work more on it if I had time, but it's in CVS due to popular demand. I'm open to people working on it. Just let me know. That covers my fiefdoms. I prefer others make calls for the other components/libs/apps/projects. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
