Re: Further Midnight Commander development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: I propose to establish two branches: stable and current (in git, of course). Stable branch will contain all founded patches (Fedora, Debian/Ubuntu, Gentoo,...), new ideas and features. The stable branch will provide the solutions that were tested in the current tree. The stable branch will lag behind in development, but will be secure and stable (for example, good for RHEL/CentOS, SLES, etc). This scheme would not hinder the development of mc, and at the same time will allow a stable release. ACK. The stable branch should be what goes into public release. Everyone who's not actively developing on mc (even those who make small, eventually distro-specific fixes) should exclusively base on that. Yes. On the other hand current is what's been finished and tested by the subsystem devs. So everyone who likes to develop on mc can use it for testing. Yes. Stable policy: * get in fixes fast and do minor releases for them frequently (so that distros don't have to maintain their own fixes) Absolutly yes. Maintainers of distros should not include any patches of security in packages that are based on the stable branch. If any patch of security or stability is included into package (not in repro) - our work is a bad. * be very careful about adding new features * breaks should be prevented as much as possible * Patches of security and stability can be transferred from the current branch to the stable branch Current policy: * get in everything that's tested/discussed by the devs for further testing * prepare approved patches for getting into stable. * Each patch, which will be transported in stable branch, will be discussed in the mailing list... or at the forum if it will ever created Subprojects (eg. translation, vfs, ...) should have their own trees and submit patches (either against stable or current) to the list for further discussion. Now for the role play: * we need some people resposible for the stable and the current tree, who have full write access - they have to decide (on discussion in the list) what patches to get in and take care of the tree wont be broken * bug wranglers should be the ones who look over new bugs, eventually give some first-aid, fixup naming and bounce them to the right people First of all we need to change the attitude towards visitors. Not all visitors to the professionals in the programming. Not everything could be properly explain what they want. We must be more open and friendly. Then the project will evolve. Because it's not a project (and people) for the developers - the project (and developers) for people who enjoy mc. IMHO :) * suggested sub-projects: - core it CONTROLLER? - vfs - vfs (mcvfs-fs, mcvfs-smb, mcvfs-ssh, mcvfs-ftp, mcvfs-dav, mcvfs-... ) it's MODELs - locale - build-/release engineering - mcslang - it VIEW(s?) - mcglib? - it part of LIB? - mcgettext (may be part of locale) - it VIEW(s?) As for the Russian issue: we devs should really agree on one well-spoken language, English. Those who're not yet capable of speaking English, could be proxied by others. That speaking of *development* - end user support is an different issue. Between developers one language: English (because Esperanto don't all know... ;) BTW, It would be a good idea that the world learned Esperanto in schools... IMHO :) ). Maybe we all should start learning Interlac ;-O :) *1: I'm currently in the process of reviewing Gentoo's patches and sending them to the list. It's good. All existing patches are to gather in one place. BTW, look, please, http://www.midnight-commander.org I think that this URL will be the main location for bugreports... hmm, should I upload all patches to trac ? Is there a more convenient way to do that, instead of all via web ? Gmm.. answer: 'yes'. Via trac-xmlrpc plugin (don't nkow, Patrick Winnertz was add this plugin or no) and via using xml-rpc applications (eclipse-mylyn, for example). But if via web you will be uncomfortable, just send patches in maililing list. I will transfer your patches in trac. WBR, Slavaz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklWK7QACgkQb3oGR6aVLpo5CgCfSc53npEOJcoAvWYrCw+meEn/ DEsAnRNe4jumsCL9CNKvTjbbi6EVcrTs =/ZL/ -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
* Slava Zanko slavaza...@gmail.com schrieb: Hi, Absolutly yes. Maintainers of distros should not include any patches of security in packages that are based on the stable branch. If any patch of security or stability is included into package (not in repro) - our work is a bad. Glad you understood it :) The folks of many, many other still refuse to - that's why I founded the OSS-QM project (http://oss-qm.metux.de/) years ago, to have a stable overlay virtually any distro can base on (I especially needed it for my embedded projects). * be very careful about adding new features * breaks should be prevented as much as possible * Patches of security and stability can be transferred from the current branch to the stable branch ACK. Of course, if we have trivial patches with very high urgence, we *could* skip that path sometimes, but that should be *really* rare. Current policy: * get in everything that's tested/discussed by the devs for further testing * prepare approved patches for getting into stable. * Each patch, which will be transported in stable branch, will be discussed in the mailing list... or at the forum if it will ever created Actually, I don't like web-forums. Too inconvenient - you always have to visit (and log into) some webapp to see what's happening. Please let's stay in this maillist and eventually connect trac with it. (would be great if patch uploading could be done via a mail robot) First of all we need to change the attitude towards visitors. Not all visitors to the professionals in the programming. Not everything could be properly explain what they want. We must be more open and friendly. Then the project will evolve. ACK. That's the job of the user support team. Actually I'd like to see more non-coders in the support team, because they have the user's view, not the coder's. * suggested sub-projects: - core it CONTROLLER? - vfs - vfs (mcvfs-fs, mcvfs-smb, mcvfs-ssh, mcvfs-ftp, mcvfs-dav, mcvfs-... ) it's MODELs - locale - build-/release engineering - mcslang - it VIEW(s?) - mcglib? - it part of LIB? - mcgettext (may be part of locale) - it VIEW(s?) huh, I'm not sure whether mvc fits in here. Well, if we say everything's a file and the model is the vfs (including things like search results represented as filesystem), we could make some steps in this direction :) hmm, should I upload all patches to trac ? Is there a more convenient way to do that, instead of all via web ? Gmm.. answer: 'yes'. Via trac-xmlrpc plugin (don't nkow, Patrick Winnertz was add this plugin or no) and via using xml-rpc applications (eclipse-mylyn, for example). But if via web you will be uncomfortable, just send patches in maililing list. I will transfer your patches in trac. Okay. I've sent out all gentoo patches so far, they're not too many. But for the future it would be cool to have the upload process done automatically - with a local command line would be even better. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
HAVE_MMAP still necessary ?
Hi folks, I really wonder whether the mmap() stuff is still needed at all. It doesnt seem to be really used anywhere. Should we drop it ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
* Enrico Weigelt weig...@metux.de schrieb: Hi folks, I really wonder whether the mmap() stuff is still needed at all. It doesnt seem to be really used anywhere. Ups, didn't look hard enough (just scanned the vfs subdir) ;-O Okay, there're mainly two mmap()-using places: a) cmd.c: compare_files() - it uses the mmap() call directly (w/o going over mcvfs), and it seems to work on local files only. wouldn't it make sense to let it run via mcvfs ? b) view.c: it tries to mmap() in the file, obviously to let the kernel do all the loading. BUT: do we *really* want mmap() here, or just some get me that file into memory()-call (same in cmd.c) ? In case we just want to have an faster way for loading files into memory (in case it's supported), I suggest some new vfs operation for that, let's call it loadFile() - it returns some FILE_DATA structure, containing size, buffer ptr and a callback vector for free'ing. Everyone who wants the whole file (or large blocks) just uses this call instead of ugly #ifdef's, and it's up to vfs to decide what to do behind the scenes. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Website trouble
Hi, the server for http://www.midnight-commander.org/ seems to be running out of memory. Trac detected an internal error: MemoryError: ... Trac detected an internal error: OSError: [Errno 12] Cannot allocate memory ... cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
