Re: Hello
The Wiki says that there is a project to collect information and complete the web documentation. So my original intent was to bring the web site documentation up to the same level as the help feature and perhaps create a PDF so it can be easily downloaded. Are there any specific persons associated with this effort so I can coordinate with them? I also have some questions that need clarification that might also be included in the Help so that every user will also have the information. For example. The Help says that only EXT2 file systems can be usewd with Undelete, but this page http://www.trembath.co.za/mctutorial.html#anchor14 indicates that EXT3 is also supported for this. That makes sense, because EXT2 and 3 are identical except for the addition of the journal. However, that is not mentioned in the Help. Also, what about EXT4? My understanding (limited) of EXT4 is that it retains many architectural components of EXT2/3 but that there are some differences. So is Undelete supported on EXT4? I don't expect to be able to research these questions quickly. I still have to read the sources and see what I can find. I am using MC 4.8.12, which is the version provided by Fedora. SO that is only a couple minor releases behind the most current according to the Wiki. Thanks! On 05/16/2015 02:13 PM, Yury V. Zaytsev wrote: On Sat, 2015-05-16 at 13:43 -0400, David Both wrote: Is there someone - anyone - here who has been working on documentation? I just want to coordinate and make sure I do not interfere with work others are doing. What kind of work do you have in mind more specifically? The primary source of documentation for mc are the man pages, from which the files used in the internal help system are generated. You'll find everything in the doc directory. Usually, whenever a new feature is implemented, the documentation is updated accordingly, so basically anyone who's been working on new features has been also working on the documentation to a certain extent. -- * David P. Both, RHCE Millennium Technology Consulting LLC Raleigh, NC, USA 919-389-8678 db...@millennium-technology.com www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
Hi David, On Mon, 2015-05-18 at 08:15 -0400, David Both wrote: The Wiki says that there is a project to collect information and complete the web documentation. At some point, the idea was to use the (back then newly created) wiki as the documentation project to collect everything that shouldn't go into the manpages. Unfortunately, things haven't gone as planned for a number of reasons: 1) There was not enough people with long-term commitment to do the work, so in the end some adhoc documentation has been created, but it's not properly maintained, poorly structured, and often obsolete 2) Trac wiki sucks as the system to keep documentation; in my personal opinion, we could do *much* better if we created a Github-style wiki, where the documentation is hierarchically structured using the file system and stored in Markdown files. First, it is then version controlled in a useful way, and second, besides using the Github interface, one could come up with some scripting e.g. using pandoc to generate PDFs, etc. as you suggested. 3) Finally, the files can be in some way fitted into a translation system like Transifex or Pootle. You will see that the manpages are already connected to Transifex. We can't do it with the Trac wiki. So my original intent was to bring the web site documentation up to the same level as the help feature and perhaps create a PDF so it can be easily downloaded. I don't believe that this is worth it. I think that the primary source of documentation should be the manpage, and work on the manpage from which the online help system is generated is the most worthwhile investment of time. I do agree though, that not everything should go into the manpage, but for this kind of documentation, I think that Trac wiki has proven itself to be a bad choice (see above regarding my personal opinion on the subject). Are there any specific persons associated with this effort so I can coordinate with them? Sadly, there aren't. I also have some questions that need clarification that might also be included in the Help so that every user will also have the information. Feel free to ask on the list (better one thread per question); hopefully someone will help you to find the answers. For example. The Help says that only EXT2 file systems can be usewd with Undelete, but this page http://www.trembath.co.za/mctutorial.html#anchor14 indicates that EXT3 is also supported for this. That makes sense, because EXT2 and 3 are identical except for the addition of the journal. However, that is not mentioned in the Help. Also, what about EXT4? My understanding (limited) of EXT4 is that it retains many architectural components of EXT2/3 but that there are some differences. So is Undelete supported on EXT4? I'm not sure. The undelete functionality is provided by e2fslibs-dev and it hasn't been tested for a very long time, at least not that I know of anyone who did if for ext3/4. I think that ext3/4 might be supported if you turn off the journal (so, basically, downgrade to ext2), but I'm not sure how useful that is. Sorry, you'll have to investigate to find the answer. This is all I can say, even though it's not very helpful... -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
That information is actually very helpful. I will proceed on the basis that the primary documentation is the MAN page and that information will move into the help file. I have done some very basic testing and research for undelete. I find no mention anywhere except that many moons ago I found a statement that there were no safe methods for undeleting files from EXT filesystems. On 05/18/2015 04:29 PM, Yury V. Zaytsev wrote: Hi David, On Mon, 2015-05-18 at 08:15 -0400, David Both wrote: The Wiki says that there is a project to collect information and complete the web documentation. At some point, the idea was to use the (back then newly created) wiki as the documentation project to collect everything that shouldn't go into the manpages. Unfortunately, things haven't gone as planned for a number of reasons: 1) There was not enough people with long-term commitment to do the work, so in the end some adhoc documentation has been created, but it's not properly maintained, poorly structured, and often obsolete 2) Trac wiki sucks as the system to keep documentation; in my personal opinion, we could do *much* better if we created a Github-style wiki, where the documentation is hierarchically structured using the file system and stored in Markdown files. First, it is then version controlled in a useful way, and second, besides using the Github interface, one could come up with some scripting e.g. using pandoc to generate PDFs, etc. as you suggested. 3) Finally, the files can be in some way fitted into a translation system like Transifex or Pootle. You will see that the manpages are already connected to Transifex. We can't do it with the Trac wiki. So my original intent was to bring the web site documentation up to the same level as the help feature and perhaps create a PDF so it can be easily downloaded. I don't believe that this is worth it. I think that the primary source of documentation should be the manpage, and work on the manpage from which the online help system is generated is the most worthwhile investment of time. I do agree though, that not everything should go into the manpage, but for this kind of documentation, I think that Trac wiki has proven itself to be a bad choice (see above regarding my personal opinion on the subject). Are there any specific persons associated with this effort so I can coordinate with them? Sadly, there aren't. I also have some questions that need clarification that might also be included in the Help so that every user will also have the information. Feel free to ask on the list (better one thread per question); hopefully someone will help you to find the answers. For example. The Help says that only EXT2 file systems can be usewd with Undelete, but this page http://www.trembath.co.za/mctutorial.html#anchor14 indicates that EXT3 is also supported for this. That makes sense, because EXT2 and 3 are identical except for the addition of the journal. However, that is not mentioned in the Help. Also, what about EXT4? My understanding (limited) of EXT4 is that it retains many architectural components of EXT2/3 but that there are some differences. So is Undelete supported on EXT4? I'm not sure. The undelete functionality is provided by e2fslibs-dev and it hasn't been tested for a very long time, at least not that I know of anyone who did if for ext3/4. I think that ext3/4 might be supported if you turn off the journal (so, basically, downgrade to ext2), but I'm not sure how useful that is. Sorry, you'll have to investigate to find the answer. This is all I can say, even though it's not very helpful... -- * David P. Both, RHCE Millennium Technology Consulting LLC Raleigh, NC, USA 919-389-8678 db...@millennium-technology.com www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
On Mon, 18 May 2015 17:18:22 -0400 David Both wrote: That information is actually very helpful. I will proceed on the basis that the primary documentation is the MAN page and that information will move into the help file. Current man page is very big. We have an old idea to split it in to independent files: 1) the man page itself which contains description of command line options and probably some other info, and 2) the content of built-in help. I would be great if you try to implement that. Thanks! -- Andrew ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
On Sat, 2015-05-16 at 13:43 -0400, David Both wrote: Is there someone - anyone - here who has been working on documentation? I just want to coordinate and make sure I do not interfere with work others are doing. First task :-) : https://github.com/MidnightCommander/mc/pull/26#issuecomment-102785091 -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
On Sat, 2015-05-16 at 13:43 -0400, David Both wrote: Is there someone - anyone - here who has been working on documentation? I just want to coordinate and make sure I do not interfere with work others are doing. What kind of work do you have in mind more specifically? The primary source of documentation for mc are the man pages, from which the files used in the internal help system are generated. You'll find everything in the doc directory. Usually, whenever a new feature is implemented, the documentation is updated accordingly, so basically anyone who's been working on new features has been also working on the documentation to a certain extent. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
Hi, On Sat, 2015-05-16 at 08:01 -0400, David Both wrote: Is this the right place for documentation contributors? If not, is there another list I did not see? Yes, this is the right place for discussing mc development. No, there aren't other lists concerned with mc development. Is there someone in charge of the documentation and what is their contact information? There is nobody who is specifically in charge for documentation. The current development process is explained on the website. Basically, you have to prepare your patchset and submit it via Trac. If you feel that it's been awhile and nobody has still looked into it, you might get some luck posting on the list and requesting a review. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello
Thanks, Yury. Is there someone - anyone - here who has been working on documentation? I just want to coordinate and make sure I do not interfere with work others are doing. On 05/16/2015 11:57 AM, Yury V. Zaytsev wrote: Hi, On Sat, 2015-05-16 at 08:01 -0400, David Both wrote: Is this the right place for documentation contributors? If not, is there another list I did not see? Yes, this is the right place for discussing mc development. No, there aren't other lists concerned with mc development. Is there someone in charge of the documentation and what is their contact information? There is nobody who is specifically in charge for documentation. The current development process is explained on the website. Basically, you have to prepare your patchset and submit it via Trac. If you feel that it's been awhile and nobody has still looked into it, you might get some luck posting on the list and requesting a review. -- * David P. Both, RHCE Millennium Technology Consulting LLC Raleigh, NC, USA 919-389-8678 db...@millennium-technology.com www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
I removed Egmond from Uhulinux, he doesn't work anymore for uhulinux according a mail I recived right after sending my previous one. * having a own repository where we have different branches for every distribution and one branch for a pure patchset. Then we can start to put all patches into the corresponding branch (e.g. I would put my ones into the debian branch). After that we can discuss every patch (there will be some different approaches of patch the same thing). and merge it into the main one. After we are done with every patch (of course except the ones which are distribution specific) we have a patchset for the CVS from upstream and can start to rediff them for the distributions needs. E.g. one distribution is using 4.6.2-pre1 and not a cvs snapshot then were will be a little work to rediff it, but this shoudl be quite easy. This guarantees that everybody uses the same patchset, that if there is a fix in one distribution for a error, this will be afterwards in every distribution. OK, that could work. Yes, I hope so. This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I've got a comment on a blogpost from another Debian Developer. This site he mentioned on my Discussion page is worth to have a look on. http://www.der-winnie.de/posts/collab-maint_between_distributions__63__/discussion/ But I think that we should made this discussion visible for upstream. What about moving it to mc-devel? Yes, indeed. I've cc'ed it. Is everybody here subscribed to this list? If yes we can use this list for a first start to discuss everything. Greetings Winnie -- .''`. Patrick Winnertz [EMAIL PROTECTED] : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote: This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I can set up a git mirror on http://repo.or.cz/ and keep it updated from the cron script. I'm doing it for another project already. The greatest thing about git (especially when used with StGIT frontend) is that is allows working on several patches at once. Complete switching to git would be great, but it would need getting rid of changelogs and relying on the commit messages for the history. That's something only the maintainers can decide. But just having a git mirror would help those who cannot stand working in CVS after trying git or another modern version control system. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
On Friday 07 March 2008 19:55:10 Pavel Roskin wrote: On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote: This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I can set up a git mirror on http://repo.or.cz/ and keep it updated from the cron script. I'm doing it for another project already. This would rock.. Please do. Thanks in advance Greetings Winnie -- .''`. Patrick Winnertz [EMAIL PROTECTED] : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
On Fri, 2008-03-07 at 21:50 +0100, Patrick Winnertz wrote: On Friday 07 March 2008 19:55:10 Pavel Roskin wrote: On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote: This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I can set up a git mirror on http://repo.or.cz/ and keep it updated from the cron script. I'm doing it for another project already. This would rock.. Please do. It took me some time to make a list of all committers. I never expected it to be so long - 105 committers! I could not recover names of davidsa, gertd and martin because they never committed any ChangeLog entries. The final (hopefully) import is in progress. I hope it will complete overnight. The project patch is http://repo.or.cz/w/mc.git If something is wrong, please let me know. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
