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
