Re: [E-devel] E17's Direction and Development
On Sun, 4 Nov 2007 07:43:40 -0500 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled: > > it shouldn't take a tonne of time to complete. though from what you say you > > are suggesting a freeze to fix bugs - not "finish the TODO" ? > > > > Not entirely - just avoid any items on the TODO (if any) that are > big-ish new features as opposed to fixing bugs or completing currently > open (and incomplete) features. agreed - though these 2 biggish ones are imho needed, but that's it. > > i agree - the wizard i know i only want certain functionality - it's even > > modular in and of itself, so we only put the modules in we need. i even > > have a proposed list of modules we need to do - it's not long. it's in > > comments in the wizard code. most are simple. i'd be happy to drop some > > (xrender vs software test and just use software anyway), drop default ibar > > apps (just ship with a default set anyway - but make that a separate file > > for the list so it can be customised per distribution), drop the > > keybindings question and default wallpaper and theme q's - most of the rest > > are really trivial question pages. it just needs momentum and examples. the > > fm has more work - but not a lot more. it's so close i don't think it > > should be all dropped. it's been on the todo forever. after that we have > > done all major todo items left - the rest are minor things, cleanups, > > fixing gaps in complete functionality etc. > > > > Sounds good. :) > > we can set a schedule - and i will bet we will slip. if we set > > milestones/tasks and just do those - then we can get it done at a pace that > > allows that. if you want a schedule from me - i will currently put in 0 > > hours per week for the next 2 months as an allocation - why? i'm moving > > countries and who knows what time i will have. in essence those milestones > > are IN the TODO. i'm removing fm todo items i think can be dropped right > > now. i've dropped some other items. see cvs commit. > > > > Noted. > > I guess that after your last commit to the TODO, we can grab that file > and split it up into milestones. I agree that although it would be > nice to time things (set a schedule), it would also be hard since we > have very (VERY) few people who can work on E17 on a daily basis > giving in solid hours every (other) day. yup. thus N tasks to complete and dependencies will do just that for you. the tasks are in TODO. just no order for them or dependency info. > What I want us to try to get to is a point where we can associate > milestones with release candidates of some sort, and a final release > for the last milestone. When we have something like that going we'll > not only feel like we're getting somewhere, but we can have snapshots > / announcements on the ML and let people feel like we're approaching a > final release. > > So at this point, the next task is to create those milestones, > associate them with release candidates, split up the TODO items > between them, and just hack hack hack at them. hmm - for me a release candidate - ie first one being "alpha" would be all our feature todo items done. we are down to bugs (and maybe some spit and polish on dialog layouts, theme, etc.). thats alpha. beta is spit and polish stuff improved and most bugs gone if not all. and RC1,2,3 come after that based on more bug feedback etc. etc. once we get down to a very small # of bugs (eg 0) we do a release. > -- > Hisham Mardam Bey > http://hisham.cc/ > +1-514-713-9312 > Codito Ergo Sum (I Code Therefore I Am) > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On 11/3/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > Granted, but if the file manager functionality is going to take a lot > > of time to complete we should just put it on hold and work on the bugs > > in the TODO. > > it shouldn't take a tonne of time to complete. though from what you say you > are > suggesting a freeze to fix bugs - not "finish the TODO" ? > Not entirely - just avoid any items on the TODO (if any) that are big-ish new features as opposed to fixing bugs or completing currently open (and incomplete) features. > > > > I'm not criticizing how these things are designed or saying they are > > "bad" or extra features. I am just saying that as it stands, they need > > a good amount of work and have the tendency to grow. We should say > > that we want to make them do a, b, and c, and freeze anything else. > > i agree - the wizard i know i only want certain functionality - it's even > modular in and of itself, so we only put the modules in we need. i even have a > proposed list of modules we need to do - it's not long. it's in comments in > the > wizard code. most are simple. i'd be happy to drop some (xrender vs software > test and just use software anyway), drop default ibar apps (just ship with a > default set anyway - but make that a separate file for the list so it can be > customised per distribution), drop the keybindings question and default > wallpaper and theme q's - most of the rest are really trivial question pages. > it just needs momentum and examples. the fm has more work - but not a lot > more. > it's so close i don't think it should be all dropped. it's been on the todo > forever. after that we have done all major todo items left - the rest are > minor > things, cleanups, fixing gaps in complete functionality etc. > Sounds good. > > > > So I guess the next move is to *try* and organize this mess and come > > up with a rough schedule for things. I know we dont usually do this > > kind of thing, but I firmly believe that if we dont set a schedule, > > nothing is ever going to be done anytime soon. > > we can set a schedule - and i will bet we will slip. if we set > milestones/tasks > and just do those - then we can get it done at a pace that allows that. if you > want a schedule from me - i will currently put in 0 hours per week for the > next > 2 months as an allocation - why? i'm moving countries and who knows what time > i > will have. in essence those milestones are IN the TODO. i'm removing fm todo > items i think can be dropped right now. i've dropped some other items. see cvs > commit. > Noted. I guess that after your last commit to the TODO, we can grab that file and split it up into milestones. I agree that although it would be nice to time things (set a schedule), it would also be hard since we have very (VERY) few people who can work on E17 on a daily basis giving in solid hours every (other) day. What I want us to try to get to is a point where we can associate milestones with release candidates of some sort, and a final release for the last milestone. When we have something like that going we'll not only feel like we're getting somewhere, but we can have snapshots / announcements on the ML and let people feel like we're approaching a final release. So at this point, the next task is to create those milestones, associate them with release candidates, split up the TODO items between them, and just hack hack hack at them. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On Thu, 1 Nov 2007 08:46:05 -0400 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled: > > actually no - it was meant to be BOTH a file selector back-end AND a simple > > filemanager. there is no point making 2 of them separate. they do the same > > thing. list files. > > Granted, but if the file manager functionality is going to take a lot > of time to complete we should just put it on hold and work on the bugs > in the TODO. it shouldn't take a tonne of time to complete. though from what you say you are suggesting a freeze to fix bugs - not "finish the TODO" ? > > it is really just these 2 big ones with smaller cleanups that need doing - > > tho default theme cleanup is not a small task BTW - i'm commenting the .edc > > heavily. > > I'm not criticizing how these things are designed or saying they are > "bad" or extra features. I am just saying that as it stands, they need > a good amount of work and have the tendency to grow. We should say > that we want to make them do a, b, and c, and freeze anything else. i agree - the wizard i know i only want certain functionality - it's even modular in and of itself, so we only put the modules in we need. i even have a proposed list of modules we need to do - it's not long. it's in comments in the wizard code. most are simple. i'd be happy to drop some (xrender vs software test and just use software anyway), drop default ibar apps (just ship with a default set anyway - but make that a separate file for the list so it can be customised per distribution), drop the keybindings question and default wallpaper and theme q's - most of the rest are really trivial question pages. it just needs momentum and examples. the fm has more work - but not a lot more. it's so close i don't think it should be all dropped. it's been on the todo forever. after that we have done all major todo items left - the rest are minor things, cleanups, fixing gaps in complete functionality etc. > > the problem is the pace. there are lots of TODO items - most not being > > done. in doing efm and wizard - i am trying to knock of some of the big fat > > items and get them started/going/ to a state of relative health. i agree we > > need to knuckle down on those. the wizard core *i think) is done. its' a > > matter of pages to do the setup. we can make it simple - but we do need it. > > we have enough problems with users asking about empty/blank app menus and > > other things that we need to fix in code on setup (i.e. - find all the xdg > > menus and ask user which one they want etc.). > > So I guess the next move is to *try* and organize this mess and come > up with a rough schedule for things. I know we dont usually do this > kind of thing, but I firmly believe that if we dont set a schedule, > nothing is ever going to be done anytime soon. we can set a schedule - and i will bet we will slip. if we set milestones/tasks and just do those - then we can get it done at a pace that allows that. if you want a schedule from me - i will currently put in 0 hours per week for the next 2 months as an allocation - why? i'm moving countries and who knows what time i will have. in essence those milestones are IN the TODO. i'm removing fm todo items i think can be dropped right now. i've dropped some other items. see cvs commit. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 1 Nov 2007 09:07:23 +0100 Andreas Volz <[EMAIL PROTECTED]> wrote: > Interesting information. I'll think about if it worth again to write > feature requests or bug reports for E17 in the future. If nobody reads > it, I could save this work. :-( > > I've CVS write permission, but I think you'll not that happy if I > insert my requests direct into TODO, not? :-) > > So a system like bugzilla is really needed. I don't understand your > problem. You get an email from bugzilla with the content of the new > post. So no need to use a web browser. And if you like to change > something, then click on the link and it opens in the web browser. You > could close it one minute later after posting your comment. > > As natural there're everytime two groups of people. That one requesting > the bugs and that one fixing the bugs. Both are important and needed! > In my experience "external" testers are more effective that if the > developer tests his own code. The testers also spend many time in > writing bug reports, create gdb traces and so on. Don't forget this > work! > > regards > Andreas I'm not a dev, just user/little contributor, so this is my user's point of view, mainly related to bugzilla/TODO file. Imho, both "tools" must coexists, a TODO file comes from main author and the target audience is end users, and bugzilla's entry (bug, improvement, whatever) comes from users to devs. As user, i read the TODO file, i see what the app/lib can do, what it can't do and what are the features that's needed to have. If i've coding capabilities i can contribute, removing lines from TODO file. Having coding capabilities, i'm also interested to Bugzilla's entries: this is the hard thing that i've found. I've found a bug, or i've an enhancement request (for both of them, usually i attach a patch, or at least a backtrace): 0) i've to choose a product; 1) i've to choose the people involved; 2)i've to wrote a description and attach files (patch or bt). Steps 0 and 1 are what i don't like in bugzilla system: not all E17 products are available (0), and when i set CC entries i see (i think) all people registered to bugzilla (1). Example: usually i'm involved with Etk, so now i know that i've to CC to codewarrior,lok,leviathan,moom and morlenxus, but there's other people that can take a look to my patch and apply it if it's right. Note that's not easy to do (imho). Dunno if it's a bugzilla limitation, but it would be best if each user can choose which E17 product are involved to; in this way we have two improvements: 0) filling entries is easy and more "accurate" 1) users that aren't main devs, and usually not CCed, can receive a bug notification and help to close it. I'm not an bugzilla expert, but seems to me that Group feature can help us. Finish, when new product is available, all registered users have to receive a mail notification, in order to choose to add new product to theirs "product observation" lists. My 2 cents, and sorry for my english. Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFHKvL4leGEL56NNP4RAh2OAKDxlzWkw9KfH7mswKDLBPjad6fVWgCffaD9 LgcbRcWZMy87CYaryMYnUIE= =n0mX -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On 11/1/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Wed, 31 Oct 2007 20:09:17 -0400 "Hisham Mardam Bey" > <[EMAIL PROTECTED]> babbled: > > > Hello gang, > > > > I'm sure some of you have (passively) read some of the discussions > > that are occurring on #edevelop from time to time regarding the > > direction this project is taking. I am mainly talking about E17, the > > window manager, and not the entire EFL. > > > > The main discussion was centered about how we're developing E17 and > > where its going. We now have two places where we keep TODO items and > > bugs, the TODO file in apps/e, and bugzilla. The way things are going, > > we have several "open" features in E17 that are partially done, some > > major, some minor. Among those features are EFM, and the First Time > > Run Wizard (FTRW). > > i think i did warn people that if this is moved to bugzilla i am certain i > will > probably not read it - having a web browser up consuming half my screen and a > web interface to trawl through painfully just to check what people have filed > is > a sure way to make me avoid it. bugzilla is painful. compared to the compact > simplicity of a TODO file in CVS - it's an abomination (from a developers > point > of view). a lot of you may just love the web, and web ui's, and sit and drool > over your gmail web page etc. etc. - but i do not. i find it royally painful. > so as i said - the result is me not reading the bug reports/feature requests. > > > EFM was supposed to be a simple file selector, it then grew into a > > actually no - it was meant to be BOTH a file selector back-end AND a simple > filemanager. there is no point making 2 of them separate. they do the same > thing. list files. Granted, but if the file manager functionality is going to take a lot of time to complete we should just put it on hold and work on the bugs in the TODO. > > file manager, it then started getting custom directory and window > > configuration abilities, and then grew so big it needed its own > > config has been there from day 0 so it can look like a list (used int he file > selector) or icons (desktop bg/fwin views). config is there as simple twiddle > knobs for icon size and more. > > > process. As it stands, none of its features are 100% complete and > > no - the process was there to split file IO out ot a slave so the WM doesn't > hang doing file IO to slow file systems (eg AFS, a CF/SD card plugged in via a > USB 1 card reader etc.). i actually did this because of slowness in the file > selector - not the file manager. it has a bonus of making the file manager > better too. > > > almost without bugs, except the file selector. The file selector is a > > core part of E17 (for obvious reasons), but the file manager is really > > not. I would classify it as a nice to have feature, along with desktop > > icons, but its nothing major that can prevent a release from > > happening. > > there's a bunch of things to finish off with the fm - but it's not a huge > amount of work to finish ti to simple usability. it's almost there. just the > actual file operations need fixing to work properly in all cases and report > errors properly. that's about all that's really left to do here (other than > initial setup of Desktop so u have some links to places like your homedir). i > wanted to add links to the ~/.e/e/themes, backgrounds etc. dirs for trivial > DND > of downloaded items etc. the FM allows that and it's ALMOST there. > > > The FTRW is a useful feature to have that has also been started and > > the wizard core is pretty much done - i paused to go fix the default theme ans > i frankly was disgusted with the look of the wizard and couldn't continue > until > i fixed things. i wanted to get that settled and come back. i want to get the > first few pages done that demonstrate how to do most things - then the rest > can > be filled in as needed. what pages are to be done is listed in the wizard - > but > we can make it more minimal to save time. > > > has not seen completion yet. It was always on the TODO, but it sprung > > out of no where at a certain point in time during the EFM development > > cycle. Although its a nice and very useful feature, and I think it > > would be a good idea to have it available when we have a release, its > > taken development time from EFM and other incomplete features in E, > > and is currently not finished. Yet another incomplete and relatively > > big feature. > > it is really just these 2 big ones with smaller cleanups that need doing - tho > default theme cleanup is not a small task BTW - i'm commenting the .edc > heavily. > I'm not criticizing how these things are designed or saying they are "bad" or extra features. I am just saying that as it stands, they need a good amount of work and have the tendency to grow. We should say that we want to make them do a, b, and c, and freeze anything else. > > Some other items in the TODO are considered medium sized tasks, and > > t
Re: [E-devel] E17's Direction and Development
Am Wed, 31 Oct 2007 20:25:58 -0400 schrieb Christopher Michael: > Hisham Mardam Bey wrote: > > Hello gang, > > > > I'm sure some of you have (passively) read some of the discussions > > that are occurring on #edevelop from time to time regarding the > > direction this project is taking. I am mainly talking about E17, the > > window manager, and not the entire EFL. > > > > The main discussion was centered about how we're developing E17 and > > where its going. We now have two places where we keep TODO items and > > bugs, the TODO file in apps/e, and bugzilla. > > Well, imo, this is just silly to have things in two places. From what > I have noticed so far, not too many people are actually using the > bugzilla for e17. Users appear to be entering bugs there, but noone > appears to be paying much attention to it. I do what I can > there...fixing things, sorting invalid bugs vs legit ones, but alas I > am only one person with a set amount of time available and would > rather not be spending it mucking with bugzilla. > The way things are going, Interesting information. I'll think about if it worth again to write feature requests or bug reports for E17 in the future. If nobody reads it, I could save this work. :-( I've CVS write permission, but I think you'll not that happy if I insert my requests direct into TODO, not? :-) So a system like bugzilla is really needed. I don't understand your problem. You get an email from bugzilla with the content of the new post. So no need to use a web browser. And if you like to change something, then click on the link and it opens in the web browser. You could close it one minute later after posting your comment. As natural there're everytime two groups of people. That one requesting the bugs and that one fixing the bugs. Both are important and needed! In my experience "external" testers are more effective that if the developer tests his own code. The testers also spend many time in writing bug reports, create gdb traces and so on. Don't forget this work! regards Andreas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On Wed, 31 Oct 2007, Hisham Mardam Bey wrote: > > So the main question I have for everyone is, what now? We're writing > code, time is passing, and we're not closing (or barely closing) any > of the items on the TODO. New features that are not always planned > make their way every now and then, and we're never substantially > closer to a release or a release candidate. What do you folks propose > we do to handle this problem? Should we freeze the addition of new > items to E17 (similar to the freeze done a while back) and concentrate > on closing all the TODO items and the bugs? Whatever decision we make, > we need to do something about the way E17 is being developed, and the > pace at which it is being developed at. imho, a freeze would be efficient and necessary. If we decide to do a freeze, when does it strat ? When the new theme is in ? Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On Wed, 31 Oct 2007 20:09:17 -0400 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled: > Hello gang, > > I'm sure some of you have (passively) read some of the discussions > that are occurring on #edevelop from time to time regarding the > direction this project is taking. I am mainly talking about E17, the > window manager, and not the entire EFL. > > The main discussion was centered about how we're developing E17 and > where its going. We now have two places where we keep TODO items and > bugs, the TODO file in apps/e, and bugzilla. The way things are going, > we have several "open" features in E17 that are partially done, some > major, some minor. Among those features are EFM, and the First Time > Run Wizard (FTRW). i think i did warn people that if this is moved to bugzilla i am certain i will probably not read it - having a web browser up consuming half my screen and a web interface to trawl through painfully just to check what people have filed is a sure way to make me avoid it. bugzilla is painful. compared to the compact simplicity of a TODO file in CVS - it's an abomination (from a developers point of view). a lot of you may just love the web, and web ui's, and sit and drool over your gmail web page etc. etc. - but i do not. i find it royally painful. so as i said - the result is me not reading the bug reports/feature requests. > EFM was supposed to be a simple file selector, it then grew into a actually no - it was meant to be BOTH a file selector back-end AND a simple filemanager. there is no point making 2 of them separate. they do the same thing. list files. > file manager, it then started getting custom directory and window > configuration abilities, and then grew so big it needed its own config has been there from day 0 so it can look like a list (used int he file selector) or icons (desktop bg/fwin views). config is there as simple twiddle knobs for icon size and more. > process. As it stands, none of its features are 100% complete and no - the process was there to split file IO out ot a slave so the WM doesn't hang doing file IO to slow file systems (eg AFS, a CF/SD card plugged in via a USB 1 card reader etc.). i actually did this because of slowness in the file selector - not the file manager. it has a bonus of making the file manager better too. > almost without bugs, except the file selector. The file selector is a > core part of E17 (for obvious reasons), but the file manager is really > not. I would classify it as a nice to have feature, along with desktop > icons, but its nothing major that can prevent a release from > happening. there's a bunch of things to finish off with the fm - but it's not a huge amount of work to finish ti to simple usability. it's almost there. just the actual file operations need fixing to work properly in all cases and report errors properly. that's about all that's really left to do here (other than initial setup of Desktop so u have some links to places like your homedir). i wanted to add links to the ~/.e/e/themes, backgrounds etc. dirs for trivial DND of downloaded items etc. the FM allows that and it's ALMOST there. > The FTRW is a useful feature to have that has also been started and the wizard core is pretty much done - i paused to go fix the default theme ans i frankly was disgusted with the look of the wizard and couldn't continue until i fixed things. i wanted to get that settled and come back. i want to get the first few pages done that demonstrate how to do most things - then the rest can be filled in as needed. what pages are to be done is listed in the wizard - but we can make it more minimal to save time. > has not seen completion yet. It was always on the TODO, but it sprung > out of no where at a certain point in time during the EFM development > cycle. Although its a nice and very useful feature, and I think it > would be a good idea to have it available when we have a release, its > taken development time from EFM and other incomplete features in E, > and is currently not finished. Yet another incomplete and relatively > big feature. it is really just these 2 big ones with smaller cleanups that need doing - tho default theme cleanup is not a small task BTW - i'm commenting the .edc heavily. > Some other items in the TODO are considered medium sized tasks, and > the majority can be considered small tasks. I don't know about the > state of things in bugzilla, but we can assume the same as with the > TODO. lots of small tasks too - that will sink a lot of time. a lot of these can just be done in parallel anyway. > So the main question I have for everyone is, what now? We're writing > code, time is passing, and we're not closing (or barely closing) any > of the items on the TODO. New features that are not always planned > make their way every now and then, and we're never substantially > closer to a release or a release candidate. What do you folks propose > we do to handle this problem? Should we freeze the addition of new >
Re: [E-devel] E17's Direction and Development
I agree on EFM. Considering it is a module, and can be plugged in, it shouldnt be too integral to a release. Get the base release out then let people start getting used to the API's and how e17 works and looks then that could possibly generate more contributors and more modules. Theres plenty of opportunity on other programs aswell in terms of making modular. A modular text editor for instance would be a favorite, and making ephoto (or some sort of image viewer) a module would be another worthy addition. But thats all the future and right now, the basic core should be a priority IMHO. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On 10/31/2007 19:25, Christopher Michael wrote: > Hisham Mardam Bey wrote: >> Hello gang, >> >> I'm sure some of you have (passively) read some of the discussions >> that are occurring on #edevelop from time to time regarding the >> direction this project is taking. I am mainly talking about E17, the >> window manager, and not the entire EFL. >> >> The main discussion was centered about how we're developing E17 and >> where its going. We now have two places where we keep TODO items and >> bugs, the TODO file in apps/e, and bugzilla. > > Well, imo, this is just silly to have things in two places. Agreed. two places will never work. I've no real preference either way (though bugzilla or somesuch allows the *community* to enter bugs), as long as whatever is decided is adhered to (and works). > From what I > have noticed so far, not too many people are actually using the bugzilla > for e17. Users appear to be entering bugs there, but noone appears to be > paying much attention to it. I do what I can there...fixing things, > sorting invalid bugs vs legit ones, but alas I am only one person with a > set amount of time available and would rather not be spending it mucking > with bugzilla. > The way things are going, >> we have several "open" features in E17 that are partially done, some >> major, some minor. Among those features are EFM, and the First Time >> Run Wizard (FTRW). >> >> EFM was supposed to be a simple file selector, it then grew into a >> file manager, it then started getting custom directory and window >> configuration abilities, and then grew so big it needed its own >> process. As it stands, none of its features are 100% complete and >> almost without bugs, except the file selector. The file selector is a >> core part of E17 (for obvious reasons), but the file manager is really >> not. I would classify it as a nice to have feature, along with desktop >> icons, but its nothing major that can prevent a release from >> happening. >> > I would tend to agree here. Granted, having a native filemanager for e17 > would be nice, but given E's modular nature this could easily come later. Agreed again. A filemanager is not a *necessity*, and can be plugged in later. Although E17 is frequently referred to as a "Desktop Shell", imo lightweight should be one of its primary goals. And if that is the case... the filemanager should be removable if so desired by a user. >> The FTRW is a useful feature to have that has also been started and >> has not seen completion yet. It was always on the TODO, but it sprung >> out of no where at a certain point in time during the EFM development >> cycle. Although its a nice and very useful feature, and I think it >> would be a good idea to have it available when we have a release, its >> taken development time from EFM and other incomplete features in E, >> and is currently not finished. Yet another incomplete and relatively >> big feature. > Again, I tend to agree with this. A "nice to have" & potentially "neat" > thing for first time users. >> Some other items in the TODO are considered medium sized tasks, and >> the majority can be considered small tasks. I don't know about the >> state of things in bugzilla, but we can assume the same as with the >> TODO. > Fairly accurate. Bugzilla may have one or two other "issues" that are > not on TODO list, but again, it really is just a dup of TODO. >> So the main question I have for everyone is, what now? We're writing >> code, time is passing, and we're not closing (or barely closing) any >> of the items on the TODO. New features that are not always planned >> make their way every now and then, and we're never substantially >> closer to a release or a release candidate. What do you folks propose >> we do to handle this problem? Should we freeze the addition of new >> items to E17 (similar to the freeze done a while back) and concentrate >> on closing all the TODO items and the bugs? > Personally, I am suprised this *hasn't* happened yet :) Imho, a hard freeze is the only way it will get done in any *reasonable* amount of time. Sooo much gets done, yet only a small percentage of it is towards the TODO. It will take a mandate, imo. While all the work is good work, and certainly needed. Its not moving us any closer to the goal (if that is measured by the TODO). > Whatever decision we make, >> we need to do something about the way E17 is being developed, and the >> pace at which it is being developed at. >> > Indeed. Anyone know of a way to cat /more/time >> /devs ?? :) > > dh > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-de
Re: [E-devel] E17's Direction and Development
Hisham Mardam Bey wrote: > Hello gang, > > I'm sure some of you have (passively) read some of the discussions > that are occurring on #edevelop from time to time regarding the > direction this project is taking. I am mainly talking about E17, the > window manager, and not the entire EFL. > > The main discussion was centered about how we're developing E17 and > where its going. We now have two places where we keep TODO items and > bugs, the TODO file in apps/e, and bugzilla. Well, imo, this is just silly to have things in two places. From what I have noticed so far, not too many people are actually using the bugzilla for e17. Users appear to be entering bugs there, but noone appears to be paying much attention to it. I do what I can there...fixing things, sorting invalid bugs vs legit ones, but alas I am only one person with a set amount of time available and would rather not be spending it mucking with bugzilla. The way things are going, > we have several "open" features in E17 that are partially done, some > major, some minor. Among those features are EFM, and the First Time > Run Wizard (FTRW). > > EFM was supposed to be a simple file selector, it then grew into a > file manager, it then started getting custom directory and window > configuration abilities, and then grew so big it needed its own > process. As it stands, none of its features are 100% complete and > almost without bugs, except the file selector. The file selector is a > core part of E17 (for obvious reasons), but the file manager is really > not. I would classify it as a nice to have feature, along with desktop > icons, but its nothing major that can prevent a release from > happening. > I would tend to agree here. Granted, having a native filemanager for e17 would be nice, but given E's modular nature this could easily come later. > The FTRW is a useful feature to have that has also been started and > has not seen completion yet. It was always on the TODO, but it sprung > out of no where at a certain point in time during the EFM development > cycle. Although its a nice and very useful feature, and I think it > would be a good idea to have it available when we have a release, its > taken development time from EFM and other incomplete features in E, > and is currently not finished. Yet another incomplete and relatively > big feature. Again, I tend to agree with this. A "nice to have" & potentially "neat" thing for first time users. > > Some other items in the TODO are considered medium sized tasks, and > the majority can be considered small tasks. I don't know about the > state of things in bugzilla, but we can assume the same as with the > TODO. Fairly accurate. Bugzilla may have one or two other "issues" that are not on TODO list, but again, it really is just a dup of TODO. > > So the main question I have for everyone is, what now? We're writing > code, time is passing, and we're not closing (or barely closing) any > of the items on the TODO. New features that are not always planned > make their way every now and then, and we're never substantially > closer to a release or a release candidate. What do you folks propose > we do to handle this problem? Should we freeze the addition of new > items to E17 (similar to the freeze done a while back) and concentrate > on closing all the TODO items and the bugs? Personally, I am suprised this *hasn't* happened yet :) Whatever decision we make, > we need to do something about the way E17 is being developed, and the > pace at which it is being developed at. > Indeed. Anyone know of a way to cat /more/time >> /devs ?? :) dh - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E17's Direction and Development
Hello gang, I'm sure some of you have (passively) read some of the discussions that are occurring on #edevelop from time to time regarding the direction this project is taking. I am mainly talking about E17, the window manager, and not the entire EFL. The main discussion was centered about how we're developing E17 and where its going. We now have two places where we keep TODO items and bugs, the TODO file in apps/e, and bugzilla. The way things are going, we have several "open" features in E17 that are partially done, some major, some minor. Among those features are EFM, and the First Time Run Wizard (FTRW). EFM was supposed to be a simple file selector, it then grew into a file manager, it then started getting custom directory and window configuration abilities, and then grew so big it needed its own process. As it stands, none of its features are 100% complete and almost without bugs, except the file selector. The file selector is a core part of E17 (for obvious reasons), but the file manager is really not. I would classify it as a nice to have feature, along with desktop icons, but its nothing major that can prevent a release from happening. The FTRW is a useful feature to have that has also been started and has not seen completion yet. It was always on the TODO, but it sprung out of no where at a certain point in time during the EFM development cycle. Although its a nice and very useful feature, and I think it would be a good idea to have it available when we have a release, its taken development time from EFM and other incomplete features in E, and is currently not finished. Yet another incomplete and relatively big feature. Some other items in the TODO are considered medium sized tasks, and the majority can be considered small tasks. I don't know about the state of things in bugzilla, but we can assume the same as with the TODO. So the main question I have for everyone is, what now? We're writing code, time is passing, and we're not closing (or barely closing) any of the items on the TODO. New features that are not always planned make their way every now and then, and we're never substantially closer to a release or a release candidate. What do you folks propose we do to handle this problem? Should we freeze the addition of new items to E17 (similar to the freeze done a while back) and concentrate on closing all the TODO items and the bugs? Whatever decision we make, we need to do something about the way E17 is being developed, and the pace at which it is being developed at. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
