Re: [Freedos-kernel] kernel sources - peer review
Hello Arkady, just an example why I will NOT peer review anything: just comparing old and new FLOPPY.ASM: about every 2'nd line has changed - with no useful purpose. sometimes - if nothing else was changed - 2 lines were simply switched. empty lines inserted or removed. trivial comment changes. ... just to find out if you did something useful or harmful would require significant work. tom --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel sources - peer review
For example, I was send here many small patches for dsk.c. Where was your reaction? Void. :( Some time ago diff for, say, config.c was small, but changes are accumulated over time, whereas you was not interested in this process earlier. Now you blame me in this? there was no one (willing) to commit your changes. No discussion possible until the changes are located into the sourcecode. Luckily Lucho now provides your sources, which should make things easier. people don't have time to daily review your patches. Send them once a month, or put all patches also in a zip-archive for download. 3 big DIFFs is better than 60 daily small patches (like your disk.c part 1 to 6 or so). hopefully now everyone quits complaining. Arkady, you are welcome to send a small set of patches once a week or so, and hopefully then people will review. Daily is too much. It's just like Eric, he also asks me almost daily to do things (experiments), and I don't always have time. Then I tend to forget things, instead of "oh, I still need to do that". daily is a bit too much, I hope you can agree on that. Not to limit you in your work, but it's like an ongoing avalanche of small patches..hard to keep up with. good luck, and I'll compile. I assume all your changes are from now on against the sources Lucho posted on his site? Bernd --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel sources - peer review
Hi! 6-Июл-2004 18:51 [EMAIL PROTECTED] (tom ehlert) wrote to Bernd Blaauw <[EMAIL PROTECTED]>: te> it's simply that to much has changed; far beond the necesary amount. te> example: te> config.b : te> removed all comments, ? There was and is a lot of comments! te> build.bat te>changed MSCL8 to MSC te>changed TC2 to TC Yes. Becuase TC3 is not "TC", but "TCPP" family. te>changed comments :- to :: This is because comments should be differ from commented statements. Tom, changed batches was (re)published in this group many times. Difference of current batch files with previous is that command line in compiler now noticeably reduced, duplicated code in tc/bc makefiles now reused (through including common makefile), some issues with MSVC is fixed (for example, NMAKE/Borland MAKE/WMAKE are very different and there was hard to make makefiles, which are acceptable for all of them). Also: __O\_/_\_/O__ - all MAKEFILEs now look similar. - "production" target replaced by "all" to eliminate warning from NMAKE. - DEVICE\MAKEFILE: device.lib now created directly in ..\lib directory without intermediate copy. - added SYS\TURBOC.CFG and UTILS\TURBOC.CFG; most options for compilers moved from command line to consequent KERNEL\*.CFG. - SYS\MAKEFILE, UTILS\MAKEFILE: reused implicit rules from MKFILES\GENERIC.MAK. _ O/~\ /~\O etc. te>etc. te> etc... te> not only that it was MSCL8 for some reason (because it's the MSC V8 te> compiler), this also makes MANY changes without any useful purpose. There _are_ "useful purposes". Most of them I publish earlier, when many times (re)publish batch files. For example, BC5 renamed to BC, because this name used for all BC++ (3, 4, 5), not only for BC5, and thus mislead. te> but when reviewing changes, I'd have to review ALL changes and see te> if there any new bugs introduced, and thats simply impossible due to te> the sheer amount. For example, I was send here many small patches for dsk.c. Where was your reaction? Void. :( Some time ago diff for, say, config.c was small, but changes are accumulated over time, whereas you was not interested in this process earlier. Now you blame me in this? --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel sources - peer review
Bernd Blaauw schreef: tom thanks for your email, Bernd hmm..Tom's reply-to points to mailinglist. Not sure this was a public email, but nevermind, I don't take sides on subjects I don't know enough about. Bernd --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel sources - peer review
tom ehlert schreef: Hello Bernd, be prepared to defend yourself against Tom's and Lucho's comments. I believe it's called "peer review". in theory - yes. in praxis - here are the reasons why you won't see a peer review by me I started a new branch of the kernel, I'll not use any arkady kernel for production good luck, Tom, with your kernel branch. People can see your arguments for doing this very clearly. I hope you occasionally publicize some patches. Hmm..you use it for DriveSnapshot, which you distribute, so you would even HAVE TO publicize your branch source code. I first thought you could keep your own work on the kernel for your own use (and perhaps sometimes publish a patch), but it's not private use. anyway, I guess you will continue your improvements based on the CVS kernel or 2035. strange that you are even continuing working on the FreeDOS kernel, as you sometimes told that the kernel was good enough for your use, just like Emm386 was good enough for your use already when VCPI wasn't implemented. I'll run my own kernel, as I simply trust it more; I've put enough time to make it as stable as it is now. Should it break, it's my fault, noone else to blame; betting on a russian horse is too risky for me. LOL! anyway, config.c is something that I can understand a bit, and which shows most changes to me. you might want to have a look at Arkady's config.c and see if you can use anything from it for your own kernel. All other changes to files is something I don't understand/comprehend, so I'm not saying anything about that. btw, I doubt that even Bart would want to validate the correctness of Arkady's version. I'm still planning on creating that DriveSnapshot bootcd with ReactOS live-cd and FreeDOS and Isolinux. (just an experiment, and I can test stability of ReactOS a bit that way) ReactOS people forgot to visibly put the cd bootsector file on the cd..annoying! anyway, MKISOFS allows remastering the live-cd properly. tom thanks for your email, Bernd --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel sources - peer review
Hello Bernd, > be prepared to defend yourself against Tom's and Lucho's comments. I > believe it's called "peer review". in theory - yes. in praxis - here are the reasons why you won't see a peer review by me I started a new branch of the kernel, I'll not use any arkady kernel for production it's simply that to much has changed; far beond the necesary amount. example: config.b : removed all comments, build.bat changed MSCL8 to MSC changed TC2 to TC changed comments :- to :: etc. etc... not only that it was MSCL8 for some reason (because it's the MSC V8 compiler), this also makes MANY changes without any useful purpose. but when reviewing changes, I'd have to review ALL changes and see if there any new bugs introduced, and thats simply impossible due to the sheer amount. there are people, that can add significant to a project, but change only relevant parts, and leave the rest intact (cheers to michael); other's are simple unable to do so even if told 100 times. I'll run my own kernel, as I simply trust it more; I've put enough time to make it as stable as it is now. Should it break, it's my fault, noone else to blame; betting on a russian horse is too risky for me. tom --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
