On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui <kakar...@kakaroto.homelinux.net> said:
> On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler > <ras...@rasterman.com>wrote: > > > On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui > > <kakar...@kakaroto.homelinux.net> said: > > > > i'm already working on taskbar. i've fixed horizontal sizing issues > > already. i > > need to fix theme up. t_unix has pending patches for xrandr multi-screen i > > have > > yet to look at - if someone wants a release them why not review those > > patches > > and try them out while i'm busy? otherwise this just takes longer. we > > can't set > > dates because so many people agree to do shit and then DONT DO IT.. in the > > end... i do most of it. look at: > > > > Ok that's cool, just let me know and I can stress test and report bugs on > taskbar or any other module. I also need the multiscreen stuff, right now I > have a script that uses xrandr, so I got the setup ready and I can test it > for you. > As for dates, yes, set a date, and if someone doesn't do shit, then too > bad, the missing features will be missing features, it shouldn't mean a > delay of another year. no - i'm not setting a date. i set a task list. > > http://trac.enlightenment.org/e/wiki/Release > > > > of the list left the following could be dropped: > > > > * connman module ui improvement > > * config modules for missing e config vars > > > > the rest are not droppable. of the droppable ones the connman ui is more > > droppable. but thats MOOT right now as these are not the last 2 things > > left. > > > > We went through the list with Cedric and Gustavo, and this is the list with > comments : > - Fix EFM to be completely reliable/functional > --> That's not a feature, those are bugs, and if they are not fixed by > the time RC1 is fixed then it's not an issue to fix them between RC1 and > final release. > - Redo resolution settings module > --> It is important, and I need it myself *but* people can live without > it. Those who can't will just have to endure it or wait for the next > release. > Anyways, if this work has already been started (or not hard > enough), then IF it can be done for RC1 then it can be included, otherwise > too bad. > - Randr config module/integration > --> I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. > - Keymap config > --> Same as the resolution module, while it is necessary, people can live > without it, otherwise, they'll endure it or wait. If it can be done by the > time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. > - Get a default theme 100% ready to ship > --> This is a no brainer, that extra polishing (what exactly is missing > anyways?) can be done from RC1 to final. > - Connman module ui needs to be improved > --> I don't use it so not much to say about it, I use nm-applet with the > systray module. But I guess it's the same as above, while it's needed, it's > not something that will break the release. > - Add config modules for all missing E config vars > --> Same as above. > > > > > > if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! > > > > with those done then we can absolutely do an alpha (though it must wait > > until > > after efl 1.1 which is now due in about 3 weeks). > > > Why not do the alpha (or RC1, it's the same thing, different naming) at the > same time as efl 1.1 release? That's what we discussed and I think it's a > good idea. This also sets a date for people to get their patches in before > the alpha release. hell no - not at the same time. we have enough work to do on efl1.1 - why does it matter that they are at the same time? other than a sudden desire to release from a whole bunch of people not working on the release? > > mind u - this debate has come up several times in the past, every 6-12 mo > > or > > so. and u know what happens? NOTHING. the people who all want it don't DO > > anything. i give a list of things to do (a rough hand-wavy one) and then > > they > > proceed to do nothing. i have learned lessons over the 16 years of doing > > things. 99% of people like to spout opinions and tell you what you should > > do. 1% > > actually get off their butts and make things happen at all. 0.01% of them > > ACTUALLY have the fortitude to stick it out long enough to get things DONE. > > > Yes, I'm pretty sure it's an old debate.. now I wonder why there still was > no release.. maybe it's because "it wasn't stable and noone did anything" > or maybe it's because rasterman vetoed everything, decided to get pissed > and scare off everyone. The purpose of this thread (and probably all the i always set a todo list - normally broad with room to wiggle, and people just barely or didn't work on it. what i'm tried of is the rudeness of wanting to tell those doing something what to do , when to do it and how to do it and then not actually be doing things. that's just plain rude. don't expect me to feel all love and happiness because of it. > previous discussions) is to get a point across, the release is needed, and > most people think that there is no point in delaying it, but if you're too > stubborn on that, maybe that's the reason no release was ever made, not > about people not contributing (which btw, seeing how you sometimes answer > aggressively, it might actually have scared away contributors). check history before you speculate on it. there has always been a todo list - it has fluctuated over time but broadly has had all the same content. reality is that it isn't released because people were not helping to make it happen. let's just deal with the most recent stuff - the release wiki page. i suggest u check its history in trac. e17 release is awaiting that. yes - i veto the release until that is done. so hold all your arguments EXCEPT about the todo list itself. that means either do stuff or convince me to nuke it from the list. > > to everyone debating e17 release - get off your butts and do the todo > > list. if > > you actually DID this... it'd have been done long ago. > > > Still missing the point, the TODO list is not the blocker, it seems to be > you and your decision. The release can be made now, the TODO list is > irrelevant. thats a load of horse dung. the TODO list is the list of things to do FOR a release. thus very simply - the release is blocked by the todo list. i'm sorry - i'm not in the school of thought that thinks u just crank out a release every N weeks/months just because a date rolls around. > I tried to compromise, I tried to come up with a solution that would make > everyone happy but you simply ignored it. I didn't write a long email to > explain things just to have 99% of it ignored. the todo list already is a compromise. now the goal is to throw it out entirely (pretty much). that's not a compromise. nowhere near it. > Assign a release manager, set specific dates for feature freezes (which > would come with a release candidate) and specific dates for releases. Do an > alpha at the same time as the efl 1.1 (NO MATTER WHAT) and get that out of > the door, it's in 3 weeks? then you got 3 weeks to do these little new > features you want ('you' being anyone who wants to contribute of course), i'm 100% busy and solid with efl for these 3 weeks - so hell no. > and you said youself it's a matter of weeks, so prove it. If it can't be > done in the next 3 weeks, then it will never be done. Then after that, you > got 1 month to iron out any bugs reported and make the whole (including the > new, somewhat buggy, features added right before the alpha release) thing > more stable, then release 1 month later! If there are still pending bugs by > that time, then too bad, you missed the window, next release will have > those bugs fixed. an e17 alpha comes out __AFTER__ efl 1.1 is out. date is not set yet. > > fyi - that todo list was decided because those items were deemed TO be > > critical enough to stall a release. even YOU are crying out for multimon > > config! you don't even give a consistent stance. > > > > Yes, they WERE deemed critical, now I think what is actually critical is to > have a release, it's time to revisit with the current situation what is > actually deemed critical. I gave my opinion above about them. i disagree. > As for my consistency, no, I am consistent, while yes, I do want and need > multi monitor support, like I said, if it can't make it then too bad! I > prefer to see a release, to see exposure and to see the 90% of users who > may not need multimon support be happy to use E17, and the remaining 10% > also happy but somewhat annoyed and impatient to get the next release that > fixes their use cases. disagree. the reasons for needing this hasn't changed. let me be very plain here. if the people insisting on a release in "1 month" (or whatever - given some short timeframe) regardless of features, todo list or quality are precisely the people NOT helping with the release. it's all armchair experts not pitching in. if you had been, if you did, the todo list would be long done by now and we'd have a release. if you help with the release then we will get what u want - a release in a short timeframe. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
