Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On 11/3/05, Michael Jennings [EMAIL PROTECTED] wrote: *snip* 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. I actually totally agree with Michael on all this. If the modules' authors use CVS, we can keep track of the codes: we know what they changed at which point in time and also able to give feedback on what to improve. People watch those CVS commits and sometimes highlight the fishy commits on the devel-list and hint a more appropriate way of doing things. Well this is a nice principle and we can all learn from it. Off CVS, we have *no control* over what's being changed. Of course you could use diff every time but that ain't practical at all, especially when the codes are splitted into many components. Off CVS, the modules stand more chances of blowing up your box because it would be practically a one-man show with no watch dog! I am in favor of letting those modules in the enlightenment SF cvs. Third party modules without peer review is the devil. And as michael mentioned, we could split them and not having them in one big chunk e_modules if there are some concerns about maintainability of some modules. Btw it would be nice that issues like these appear on the e-devel mailing list also so that everybody (and not just developers) can give their opinions. Not everybody hang out on #edevelop all the time. And don't forget that we have different time zones too! :) -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
Il giorno gio, 03/11/2005 alle 02.11 +1300, Dale Anderson ha scritto: Just a quick note to advise the e_modules directory has been removed from cvs. [snip] I'm not actually an e developer (just a wannabe one ^_^ ), but I'd like to give you my point of view about the modules management question. I threw some little (and very embrional) idea in #edevelop a few days ago, talking with raster, and here they are: -1) all ideas are probably very bad and all are only from a theoric point of view; I didn't spent a minute to verify the actual needed work to make them become true. Also, all ideas are only IMHO, IMVHO, and please don't blame me... not too much, at least! :) 0) my english is not so good, so if you don't understand something, let me know, I'll try to explain to my best! 1) modules *should* be in CVS, but in my opinion they should have a separate module tree, i.e. at the proto level, so they could be virtually excluded from the popular e distribution (I've still to understand why the hell users consider CVS as a distribution...) 2) basic and useful modules should remain on the main e source; I'm talking, e.g., about clock, pager, dropshadow, randr... but IMHO all modules that does only gadgeting and are not universally used should go to the separate modules tree (e.g. battery or cpufreq, useful but used only by laptop-users, or snow/flames...) 3) there should be a CVS tree like: modules/ snow/ battery/ monitor/ evolume/ ... That division should keep the various dependencies alone (I don't want ALSA headers if I don't want to compile evolume) and should improve the development (I can play developing my module without fearing to break the others). 4) modules should use a minversioning system along with e_mod APIs, to know that if my system runs with 3.2 e_mod API I will able to run modules with minversion = 3.2 and I will not be able to use modules whose minversion is 2.x, 1.x and so on (in my view the first number is changed when retrocompatibility is broken). 5) it should be nice to have a CPAN-like (or PEAR-like, if you prefer) infrastructure, so the user can open the module manager window, refresh the list of available modules for his e_mod_system version, update, install, uninstall and so on. That could add key features, such as considering a module stable, choosing to compile from CVS or prefer binary distribution (through get-e.org, perhaps), updating config files, and so on. Just my two cents, for now... I know that all that stuff is neither simple and the theme is hot... I only hope that among all that words there's at least one or two that can give an idea, and not to throw fuel over fire... Oh, a last reason not to blame me too much: today is my birthday! :PPP -- Ciro Mattia Gonano Winged.it Master - http://www.winged.it FlyingCircus.it member - http://www.flyingcircus.it GPG Keynumber: DEF86925 --- ICQ#: 52631406 --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On 11/3/05, Ciro Mattia Gonano [EMAIL PROTECTED] wrote: 3) there should be a CVS tree like:modules/snow/battery/monitor/evolume/... I wholeheartedly agree with this, lets either move them to e17/modules or into the misc branch. Having the source on get-e.org does NOT facilitate people being able to update their projects well. The alternative is to see a new SF project for every module, or different projects floating all over the net with no organization. I also very much like the idea of them being split out of the same source tree for dependencies etc. I've tried to do that already with the spec in the current e_modules :)
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
Didier Casse wrote: On 11/3/05, Michael Jennings [EMAIL PROTECTED] wrote: *snip* 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. I actually totally agree with Michael on all this. If the modules' authors use CVS, we can keep track of the codes: we know what they changed at which point in time and also able to give feedback on what to improve. People watch those CVS commits and sometimes highlight the fishy commits on the devel-list and hint a more appropriate way of doing things. Well this is a nice principle and we can all learn from it. Please read my suggestion here: http://marc.theaimsgroup.com/?l=enlightenment-develm=113100021920877w=2 If everyone agrees I can set this up ASAP. -Blake --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On Thu, 3 Nov 2005 11:07:45 -0600 Nathan Ingersoll [EMAIL PROTECTED] wrote: On 11/3/05, Blake Barnett [EMAIL PROTECTED] wrote: Please read my suggestion here: http://marc.theaimsgroup.com/?l=enlightenment-develm=113100021920877w=2 If everyone agrees I can set this up ASAP. I'd prefer if we had them in our repository under proto or a separate modules directory. If that won't fly, then I think your idea would be the way to go. I agree, a separate modules (but not e17/modules) directory, e17/proto if we have to, or cvs at edevelop.org in that order of preference for me. pgpzrq0c41BbI.pgp Description: PGP signature
[E-devel] [ANNOUNCE] e_modules removal from cvs
Hi All Just a quick note to advise the e_modules directory has been removed from cvs. This was due to concern regarding the increasing number of modules being commited, and the likely hood these would be left unmaintained . These are now all updated and available from get-e.org (thanks devilhorns) . Module authors can now contact the get-e team for access to the site to maintain their code and provide updates. Please also note that modules_extra has been removed from the default E module search path and modules need to be installed to , $PREFIX/lib/enlightenment/modules or, ~/.e/e/modules Regards Dale (swishy) Anderson. --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On Thursday, 03 November 2005, at 02:11:12 (+1300), Dale Anderson wrote: Just a quick note to advise the e_modules directory has been removed from cvs. It has not been removed, and it will not be unless and until such a decision is made after discussion on this mailing list amongst the developers. This was due to concern regarding the increasing number of modules being commited, and the likely hood these would be left unmaintained This is just silly. Do you have any idea how many packages we have in CVS that haven't been touched in ages? So what? These are now all updated and available from get-e.org (thanks devilhorns) . They should not need to be downloaded from get-e.org or anywhere else. Module authors can now contact the get-e team for access to the site to maintain their code and provide updates. Ridiculous. It should be up to the module authors whether or not they want to develop in our CVS tree or elsewhere, and whether or not they have abandoned their work or will continue maintaining it. Not once did anyone ask the module authors on this list how they wanted to handle this situation. This was a unilateral decision driven primarily by Hisham, though he apparently got raster's buy-in, and discussed only between the two of them while most of us were asleep. Does anyone else see a problem here? These kinds of decisions being made behind closed doors is not how an Open Source project should be. Nor should people's work be removed from CVS without their input and consent. This list is here for purposes of discussion. So people need to stop acting like such significant decisions can and should be made on IRC and start COMMUNICATING. To that end, I would suggest splitting up the individual modules so that each one builds and installs independently of the others. It's not hard to do; I did it for tclock and calendar already. So why not split the others up and let each module author control his own module rather than feeling like it's just part of a bigger pie? 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) --- Act like you expect to get into the end zone.-- Joe Paterno --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
Please also note that modules_extra has been removed from the default E module search path and modules need to be installed to , $PREFIX/lib/enlightenment/modules or, ~/.e/e/modules Whats the point of removing this from the search path? It causes no issues and allows people to keep their official and unofficial modules in separate directories. And yes, .e/e/modules is there, but what if I have two users? They both have to have a copy, which sucks. I'd say, this directory should stay as it really dosen't cause any issues. dan --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On 11/2/05, Michael Jennings [EMAIL PROTECTED] wrote: Ridiculous.It should be up to the module authors whether or not theywant to develop in our CVS tree or elsewhere, and whether or not theyhave abandoned their work or will continue maintaining it. I have to agree with mej on this. I understand the desire to keep unmaintained code out of the main tree, but I don't think forcing the decision on module authors is the way to go. It also makes collaborative development difficult unless they setup their own CVS repository, and that seems a little ridiculous for a single module. It also seems a bit pre-mature to call these modules unmaintained. They have been updated as API's have changed and while there have not been significant feature changes recently, there is nothing preventing them from being expanded as more widgets features become available in the core. For example, the weather module is probably feature complete until the config dialog/widgets settle out. If we really don't want these modules in the main e17/apps directory, why not move them to proto until they are either accepted into the main e17 modules or deprecated? We've already declared proto as a test playground, so I don't see a reason that people we've already given CVS access to couldn't put their modules in that area for development. We're really talking about two issues, development and distribution. I can't see anyone having a complaint about putting the modules up for distribution on get-e.org, but by officially excluding all extra modules from CVS, they would get far less developer exposure. I know I'm far more likely to fix a problem in a module in CVS than one I can only get a tarball for from get-e.org. I'd imagine some of the packagers would have little motivation to work on them as well. Not once did anyone ask the module authors on this list how theywanted to handle this situation.This was a unilateral decision driven primarily by Hisham, though he apparently got raster's buy-in,and discussed only between the two of them while most of us wereasleep. There was some discussion in #edevelop that I saw, but it was brief and I was given the impression that it would be left up to module authors. Does anyone else see a problem here?These kinds of decisions being made behind closed doors is not how an Open Source project shouldbe.Nor should people's work be removed from CVS without their inputand consent. The consent issue is actually a pretty large one. We've never removed peoples work from CVS without their permission, just take a look at the AUTHORS files in misc. How long has it been since most of them have been seen? Some of them are kept in memory of their authors. So why don't we move the modules to proto, and then use get-e.org as a distribution mechanism? Nathan
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On Wed, 02 Nov 2005 10:46:03 -0500 dan sinclair [EMAIL PROTECTED] babbled: Please also note that modules_extra has been removed from the default E module search path and modules need to be installed to , $PREFIX/lib/enlightenment/modules or, ~/.e/e/modules Whats the point of removing this from the search path? It causes no issues and allows people to keep their official and unofficial modules in separate directories. And yes, .e/e/modules is there, but what if I have two users? They both have to have a copy, which sucks. frankly - it was ADDED as a hack. the original intent was to have a system moduels dir by default and that's it. e shouldnt go looking in dirs not provided by IT by default. a user CAN add a new module dir to the search path - but e shouldnt be poking around in these dirs if they may or may not exist. as for modules in modules_extra - it's just an unclean hack imho. i always have said that and have relented due mostly to laziness. I'd say, this directory should stay as it really dosen't cause any issues. it WILL cause issues soon enough - when we add a module manager code that has to hunt the fs for modules able to be loaded. adding more and more extra module dirs (1 isnt too bad - but where do u stop?) just means more magic divination by such a codebase. if 3rd party moduels get installed int he same tree(s) (there are only 2 ~/.e/e/modules and PREFIX/lib/enlightenment/modules) then its much easier to deal with from a user POV (no need to add another dir) and a code POV. dan --- 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
On Wed, 2 Nov 2005 10:36:23 -0500 Michael Jennings [EMAIL PROTECTED] babbled: On Thursday, 03 November 2005, at 02:11:12 (+1300), Dale Anderson wrote: Just a quick note to advise the e_modules directory has been removed from cvs. It has not been removed, and it will not be unless and until such a decision is made after discussion on this mailing list amongst the developers. This was due to concern regarding the increasing number of modules being commited, and the likely hood these would be left unmaintained This is just silly. Do you have any idea how many packages we have in CVS that haven't been touched in ages? So what? These are now all updated and available from get-e.org (thanks devilhorns) . They should not need to be downloaded from get-e.org or anywhere else. Module authors can now contact the get-e team for access to the site to maintain their code and provide updates. Ridiculous. It should be up to the module authors whether or not they want to develop in our CVS tree or elsewhere, and whether or not they have abandoned their work or will continue maintaining it. Not once did anyone ask the module authors on this list how they wanted to handle this situation. This was a unilateral decision driven primarily by Hisham, though he apparently got raster's buy-in, and discussed only between the two of them while most of us were asleep. Does anyone else see a problem here? These kinds of decisions being made behind closed doors is not how an Open Source project should be. Nor should people's work be removed from CVS without their input and consent. This list is here for purposes of discussion. So people need to stop acting like such significant decisions can and should be made on IRC and start COMMUNICATING. To that end, I would suggest splitting up the individual modules so that each one builds and installs independently of the others. It's not hard to do; I did it for tclock and calendar already. So why not split the others up and let each module author control his own module rather than feeling like it's just part of a bigger pie? first - check cvs. the coded hasnt been removed. it's there. lurking. 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 (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.the code is there for posterity. this was discussed openly on #edevelop. as for the authors - the proff is that they dont get maintained - 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. 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. 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. you are making a mountain out of a molehill here. no code has been deleted. it hasnt actually even been disabled. this has split the modules into their own build trees and moved such development of 3rd party toys out of cvs. 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. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] [ANNOUNCE] e_modules removal from cvs
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
