В пн, 2007-07-09 в 01:50 +0300, Hisham Mardam Bey написа: > 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. Judging from the projects currently included into CVS, it seems that the 'Enlightenment' project has grown well past the 'desktop shell' stage. While 'E' itself is currently a glorified WM, the whole 'Enlightenment' project has all the ingredients to claim a 'desktop environment' title. > > > 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. My personal view is that dedicated maintainers might be a bit overkill at this point. Once projects are finally released, then a dedicated maintainer is really justified. But the current code base is constantly changing, even if not as drastically as it used to. Furthermore, maintainers can never be truly 'dedicated', mainly because of the spare time issue. And we all know that spare time is hart to come by, even sometimes impossible to obtain.
An intermediate solution would be to discuss any changes on the dev mailing list. And by discussing, I don't mean that the proposer should post a message, which will be ignored, but people should actually try and participate. Furthermore, we should really stick with discussing important issues in the dev list, instead of on irc. Mainly, because theres a centralized 'log' of the discussions going on here, and there is no excuse for someone missing a conversation. I myself have made the terrible mistake of discussing changes on irc only, thus keeping interested people out of the loop. > > 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. At this stage of development, API breakages should not be a concern. As you said, there have been no 'stable' releases yet, so we can't really piss off users of the libraries, as they should be bloody aware that the code is unstable. Internal breaks can easily be fixed, thanks to /insert_your_diety_here/'s great inventions, find and grep. > > 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? Truer words have never been spoken. > > 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. > -- Виктор Кожухаров /Viktor Kojouharov/
signature.asc
Description: Това е цифрово подписана част от писмото
------------------------------------------------------------------------- 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
