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. > > 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 - 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. - 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. > > 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 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). > > 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. 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. 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), 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. > > 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. 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. I also want to go to the moon next week, if I can't, too bad, but I won't hang myself either. > > > Hi guys, > > > > I've started this discussion with Gustavo and Cedric back in Prague, and > > haven't had time to check my mails until now (doing it from the airport). > > I will summarize the stuff I've told them and i'm sorry if I'm repeating > > some of the things that were already said in this thread. I will then > answer > > specific stuff I've read. > > > > E17 *needs* a release, there is no doubt about it, and it needs to happen > > sooner rather than later. I believe the only reason it was never > released is > > because "there is no such thing as a complete/perfect software", The way > E17 > > is right now is not much better than 4 years ago. You think people will > > complain "I waited years for this???", no, I think they will complain > "they > > could have released this 4 years ago!". > > As such, since no software is ever complete, it means that a release will > > never happen if you have to follow the whole idea of feature-complete (or > > even 'after this TODO list is done). You actually need to set dates, and > > then *make your features fit in your timeline*. As for "it's not ready", > no, > > it IS ready, it's been ready for the past 4 years (although a bit more > buggy > > back then, but it still kind of is), and if you look at the 'disaster' of > > gnome 3 and kde 4, you'll know that they can completely fuck it up, but > it > > won't matter because 3 months later, they'll have a new release that > fixes > > all the important things (the actually important ones, not the ones that > the > > devs think might be important) and they doubled their user base and > > everybody forgot about the annoyances they originally had! > > You release "now", in the release notes, you make it clear what exactly > is > > missing and promise to get it fixed by next release (with a hardcoded > > deadline for that release) and people will not complain.. at least, most > of > > them won't, for those who will, ignore them, because no matter what, > people > > will complain, God created the earth and life in all things, and yet > people > > complain that He doesn't exist... see my point ? You need to stop being > > scared of offending the very few ingrates out there, and actually do the > > right thing for the majority of grateful users who are depending on you. > > > > As for the release cycle, I suggested someone gets assigned the specific > > role of release manager, his task would be to take care of doing releases > > (and code in between of course), and if a release is not done on time, > it is > > his responsability/fault/whatever. The task of the release manager is to > > make sure that the goals for the next release are reached on time (means > > yelling at others if necessary) or to drop features for the next > release. He > > will take care of maintaining the release schedule wiki page too. The > > release schedule will need to have set goals and dates. Look at the > > gstreamer release schedule wiki page for example, they give you the exact > > dates for the feature freeze and for the release of the next 3 versions. > > This is what is needed here, people must know that they can expect a fix > > soon, and not in another 10 years. And frequent releases definitely > gives a > > lot of exposure to the project, which is needed. > > > > Now about the TODO and "release as-in" (Gustavo) versus "finish these > > features first" (Carsten) philosophies. I looked at the TODO with cedric > a > > couple of days ago, and quite honestly, it was ALL low priority. There is > > nothing in there that absolutely has to be done before any kind of > release > > so they can all be dropped! But I don't necessarily agree with a > "release it > > now as-is" either.. I agree with cedric's view of releasing an alpha > (what I > > call a release-candidate) in a couple of weeks when efl 1.1 get released. > > Get your features in the core from now until then (in 2 weeks, right?) > and > > then the release candidate can be released, at which point a feature > freeze > > of 4 weeks must be set, no more. 4 weeks later, the actual release HAS to > > happen. Between the RC1 and the final, no new features are to be added, > but > > bugfixes can (and should!) get committed. > > So what I'm saying is, you want dual screen support (oh God, please, I > need > > it!!! :D) then do it from now until the 15th of December (does that date > > sound nice?) you want a better taskbar? then get it in right now. You > need > > the keyboard layout thingy, then get started! Then when the RC1 gets > tagged, > > that's it, no more features, and start bugfixing whatever you can find. I > > think this should please both parties, since Carsten himself said that > these > > missing features should only take weeks to implement, right ? So now's > your > > chance to prove it and get it done in the next 2 weeks, because if you > > can't, then trust me, 2 years from now, we'll be having this same > discussion > > in which you'll say it will only take a few more weeks to implement these > > other features that are absolutely necessary for the release. Do a > break; or > > continue; or even a goto; or whatever you need to do, but you need to > stop > > this infinite loop you've been in for the past 10 years (and yes, I know > > that what was written in the past 10 years is huge, but no releases kind > of > > means it was for nothing). > > > > Oh another point I wanted to make was that, now the E community is very > > small (compared to gnome/kde) and the only way for it to expand is to > get a > > release.. again, think of gnome 3 and kde 4 initial releases, they were > > missing tons of stuff and were unstable, but by making the release, they > > were able to get people motivated to actually fix the issues they were > > having. I'm fairly sure that after a release, you will get a lot of new > > contributors and those elusive TODO items that never seem to get fixed > will > > finally have someone working on them. Right now, with no releases, you > have > > no exposure, so no new contributors and not enough resources to actually > do > > the release you seem to want... > > > > Now that's pretty much what we discussed back in Prague I believe. If I > > forgot something, I can always --amend my mail later on (oh yeah, > > POST-release, it might be good to revisit the question of the version > > control system). > > As for the specific questions, I think the release must be > 'englightenment > > 0.17.0' and not 'e17 1.0' . > > As for the taskbar, I've always used 'taskbar' which worked fine for me > but > > was pretty annoying in terms of auto-resize/scroll content, and if it > gets > > too big it would shift the content of the shelf outside the screen. I > just > > tried the 'itask' module now and it seems to be more intelligent, so I've > > now switched to it. Yes if you right click on it, it doesn't give you the > > module's settings, but it adds a sort of small icon at the start that you > > can use to configure the module and serves also the purpose of bringing a > > popup with the available windows (kind of like taskswitcher module). > > I have no opinion on the high level language, python/JS. All I know is > that > > gnome shell is written with JS. > > As to Mike's comment about the release TODO was decided upon and it > > shouldn't be changed. I think you missed the point of this whole > thread... > > nothing is written in stone and this thread has the task of rediscussing > > what that TODO list means and to redecide its content. > > As for the 'rush it', no, I don't think it's being rushed, it's stable > and > > it's pretty much complete, there is no point in delaying it (which might > be > > forever), you can't say it's being rushed after spending the last 10 > years > > planning this moment. Yes, there are missing things, but nothing is (in > my > > opinion) critical enough to block the release. And like I said above, you > > still got 2 weeks to get those missing features in.. if you can't do it > in > > that time, then it will never happen in my opinion. > > > > That's pretty much it from me, I will reply to any new comments (yeay for > > having internet now (== in about 12 hours)!) > > > > KaKaRoTo > > > > On Sat, Oct 29, 2011 at 5:34 AM, Gustavo Sverzut Barbieri < > > barbi...@profusion.mobi> wrote: > > > > > On Sat, Oct 29, 2011 at 3:28 AM, Carsten Haitzler < > ras...@rasterman.com> > > > wrote: > > > > On Sat, 29 Oct 2011 00:51:53 -0400 Christopher Michael < > > > cpmicha...@comcast.net> > > > > said: > > > >> Agreed. But to 'jump the gun' and release early (read: earlier than > > > >> ready) at this stage is just silly. Take a little more time, finish > the > > > >> work properly and have a Good release !! rather than a half-arsed > one. > > > >> Hell, we've hammered on this for more years than I care to > > > >> count...what's a few more months ?? ;) > > > > > > > > thats actually another point - its not months - its weeks. > > > > > > Let's hope so. We've been saying that for years. > > > > > > And old time E community is weird. At some point is "who cares about > > > users?" and at another is "but users will complain". > > > > > > Also, be realistic. While we old time geeks are all about ranting > > > GNOME3 and Unity they are stronger and stronger everyday. Don't let a > > > few whining people disturb your view of the whole picture. They loose > > > few kernel hackers that will happily move to "awesome" or "fluxbox", > > > but get dozen thousand users that will never know what is phoronix and > > > thus will not answer it there. TBH "happy users are quite". > > > > > > > > > -- > > > Gustavo Sverzut Barbieri > > > http://profusion.mobi embedded systems > > > -------------------------------------- > > > MSN: barbi...@gmail.com > > > Skype: gsbarbieri > > > Mobile: +55 (19) 9225-2202 > > > > > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > -- > ------------- 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
