Joerg, Joerg Schilling píše v po 03. 05. 2010 v 15:34 +0200: > Milan Jurik <milan.ju...@sun.com> wrote: > > > > I am sorry but these so called "requirements" cannot be discussed as they > > > are a > > > step backwards. What James asked me to do is not based on technical > > > requirements > > > but just rather burocratic. > > > > > > > Yes, they can be seen as burocratic. But ON gate source code is > > "maintained" by hundreds of developers for more than 20 years. If > > everybody will use own C style I would give up my job as sustanining > > engineer because the code would be unreadable (and it is faaar from > > perfect these days). Every project has own set of "requirements", in > > case of ON gate it is (not only) "C style" set nearly 20 years ago. > > I am not requesting an own style, I do however don't like to be forced to > something that is inferior to what I use already since years and I cannot > take "requirements" for serious of the mayority of the code from the party > setting up the requirements is far away from the requirements. > > You may be able to agree with me on better thandards than the ones I currently > use but you will not succeed to let me agree on inferior standards. >
Well, I do not consider ANSI C and other requirements sent by James Carlson as "inferior". Which is the basic of our disagreement probably. You can consider ON gate "C style" as not ideal but it is based on years of experience of many contributors. > > > What is the benefit to have portable code in ON gate if it will bring a > > lot of new header files, new framework, new ifdefs (not your case but > > You already include a similar framework (the AST code). Similar to what > has been formerly said for AST, I tell you that I am not going to give up > portability just for a single platform. > I heard several complains about that AST code was included to ON gate. I heard the reasons from the responsible team. For now there is not real benefit for it, maybe there will be some in future. But the framework was included to keep large portion of source code in sync with upstream. What you are proposing it is to include your large own framework and some files where upstream of these files are not changed so frequently as it is in case of AST tools. It is not comparable. > > others are doing that)? ON gate will be bigger, compilation slower, > > maintainance larger. All for "system level code" and those part not > > If you would familiar with my code, you would know that this is not true. > The converse is true: from making/keeping code portable, the quality of the > code increases in a significant way. > I participated on design for portability of one large and complex tools years ago. I agree it is beneficial to maintain it in many cases. But not in this case. Maintaining "multiplatfrom" implementation of strnlen() is not useful at all. Sorry. And these days I do not see "K&R C" and maintaining own set of header files with system definitions as good for multiplatform support. Nor short names of variables. Sorry. > > significant for ON gate would consume the space only. Your proposed > > fixes are significant but they have small size. Why should ON gate > > accept such code changes? There are examples of code not following the > > "C style" in ON gate and believe me, if I need to touch such code, I am > > not happy man (and not only I). > > It is obvious that you did never look at my code before. If you did, you > would > know that I did put significant effort in the code that I already made > portable > (sh, diff, sccs). This is because the code before has been in an extremely > bad > condition. > > > > If you are interested in a collaboration, you could get a lot of > > > interesting > > > things from me as I did e.g. take old code from Sun and did rewrite it in > > > order to make it portable and in order to convert it to modern code that > > > e.g. > > > provides prototypes for _all_ functions. I am sure that if you are > > > interested > > > in the future of Solaris, you will be interested in using my enhanced > > > code. > > > All my code is also correctly working when compiled for 64 bits, Sun's > > > majority > > > of the code is definitely missbehaving if compiled for 64 bits. > > > > > > > Which would be very good to have, of course. > > This is what I have been told several times already. Are you going to make it > happen? > > > > I am willing to provide enhanced code for "sh", "diff" and "sccs" > > > interested? > > > > > > > Well, there is interest in it I believe. But in the style of code and > > the framework of ON gate. I understand you do not want to maintain two > > different code bases. Well, find somebody who is willing to take your > > proposed changes and rewrite them to be ideal parts of ON gate and push > > them through the process. Hopefully there is some member of OSol > > community willing to do that. > > If you like to benefit from enhanced code, you cannot request me to go back > to > the quality of the code in the ON gate. It would be wise to accept code with > better quality. > > I am trying to start a collaboration with (formerly) Sun now Orcale since a > long time. It is up to you to benefit from my offer. > No, I am not ready to spend my own time to port your code to ON gate. I could sponsor some of these contributions if somebody is willing to do such thing (like sign SCA or how it is called today, including you, of course, write PSARC if needed, prepare "hg export" based on current ON gate, do the testing). Even sponsorship of it would take significant portion of my time and I am not paid by the company for porting your stuff to ON gate. > Jörg > Best regards, Milan _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
