On Thursday, 03 November 2005, at 12:23:19 (+0900), Carsten Haitzler wrote:
> first - check cvs. the coded hasnt been removed. it's > there. lurking. I know; the first thing I said was that it had not yet been removed. :) > the problem is - a lot of these moduels have problems - lots of > them. the problems grow as basically the authors dont' maintain > them. i have module changes in the pipeline that will mean yet more > changes needed and given the history peolpe other than the authors > will fix them to build - but they will still be badly done modules > and grow worse as their code origins divert from main development But there are, in my opinion, too few existing modules to be getting this picky right now. When we get to the point where we have all the basics covered (load, bandwidth, memory, mail check, disk space, analog and digital clocks), if we feel they need to be rewritten and are willing to do so, great. But something is better than nothing. > (welcome to developemnt in cvs where apis are not fixed in > stone!). the aim is to stop the tirade of "why doesnt this work" > about these modules in cvs. the problem is that they need to be > encouraged to be maintained per author separately from cvs. Why? Maintained, yes. Per author, no. Separately from CVS, definitely not. Having it public encourages others to pick up where the original author left off. CVS is first and foremost a collaboration tool. Removing code from CVS stifles collaboration and contribution. Imagine where kwo would be if e16 had been removed from CVS when e17 started. > the code is there for posterity. this was discussed openly on > #edevelop. IRC is not the right venue for making decisions. There were a multitude of people, myself included, who were not involved in the discussion because it was held at a time of day when we weren't active. The mailing list is better because it allows the discussion to be carried on at differing times of day and allows more people to be involved. > as for the authors - the proff is that they dont get maintained - What about the modules that are brand new, like rain? How are you concluding that they're unmaintained? They haven't been in CVS long enough to be unmaintained! > i see no reason to ask nicely about code put in cvs then left up to > others to fix - when they may or may not have time. all the "my > monitor module reports 200% cpu" and not a single (correct) fix. What about all the people like myself who use the monitor module all day, every day, on multiple systems, and have no problems whatsoever? Those who have problems with it don't have to use it; those who don't shouldn't be penalized. > anyway - the long term thing is that we cant go give a cvs account > to every module writer who wants to make one to go put it in an ever > expanding e_modules tree only to commit it then vanish and leave it > up to others to maintain. they should maintain it themselevs on > their own systems and upload tarballs to their own web pages if they > want to release. get-e is providing a place for those without web > space or without enough bandwidth. SourceForge does that too. If they want to maintain it independently, there's nothing stopping them from doing so. But keeping it in our tree gives the rest of us the chance to step up if they disappear. > this is a first step to DISCOURAGE use of the e_modules tree BEFORE > its completely disabled for building and survives only as a dead > code repository. Not everyone agrees that that's the right approach. That's why it needs to be discussed. > you are making a mountain out of a molehill here. I don't see it that way. I'm trying to keep the molehill from becoming a mountain. > no code has been deleted. it hasnt actually even been disabled. I know. And I want it to stay that way. Others do too. > this has split the modules into their own build trees and moved such > development of "3rd party toys" out of cvs. And what we're trying to say is that's not the right approach. Maybe they should go in proto/ instead, or whatever, but removing them from CVS altogether isn't the answer. All that does is stifle development and code sharing. > the moduels might be useful to many people - or fun, but where they > are now, and how they build and are done, is not a good "example" to > set. The examples are the modules that come with E itself. Most people wouldn't see independent modules as examples when E comes pre-packaged with some. Especially if not all of them work. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Whoa. Somebody computer programmers think is anti-social? That I'd like to see." -- Sydney Penny, "Hyperion Bay" ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
