Joerg,

Joerg Schilling píše v po 03. 05. 2010 v 16:55 +0200:
> Milan Jurik <milan.ju...@sun.com> wrote:
> 
> > > 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.
> 
> From your wording, it seems that that you just do not understand me and
> that you simply missunderstand me because you did never look at my code. 
> All my code makes advantages from ANSI C, most of the code in ON however 
> does not make advantage from ANSI C.
> 

strnlen(s, len)
        register const char     *s;
        register size_t         len;

I do not see this as good ANSI C.

> It is up to you top learn that you get a benefit from what I offer. What I 
> offer is based on at least as many years of experiences as the code in ON. 
> My code however has the advantage that I do update _all_ my code every time 
> I see a way to make things better. This is the major flaw in the code in ON.
> A lot of the code in ON has not been touched since more than 10 years and 
> thus 
> does not include the experience you are talking about.
> 

Well, nobody contributed to that code, so it was not touched. There are
many CRs which have priorities before "C style" of old code and new,
"modern" rules of programming.

> 
> > 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.
> 
> I am not going to introduce pitfalls into my code just in order to make a 
> single person happy who did not even look at it.

I commented your code I saw. Truth, I did not look at all of your code.

>   I offer a significant amount 
> of code that is well maintained. The only way to keep a large amount of code 
> in 
> sync with the maintained source is to keep it the way it is maintained.

So, which one source is bigger - ON gate or your code base? If I will
send you some new great code to your code base, but using my own
framework, will you accept it? Or will you spend weeks to convert it to
your? I think you will ask me politely to clean up it and follow your
rules.

>  And 
> please note that while AST replaces nearly everything from libc, my 
> development model is to carefully add code to the existing base of the 
> various 
> OS platforms.
> 

Yes, and for that reason I do not like AST code. And I never understood
why nearly every shell thinks it knows how to create better memory
allocator than the native one. Etc.

> 
> > 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.
> 
> We are not talking about strnlen() here but about a lot of code that I 
> maintain.
> This is code that I have written from scratch and this is also code that 
> Sun/Oracle is no longer willing to maintain and that I now maintain for 
> iterested people. 
> 
> If you don't understand this, you are probably the wrong person to talk to.
> If you just like to take 5 lines of code from me, I recommend you that you 
> take 
> the 5 lines and add you own build framework around it.
> 
> If you like to take more than half a million lines of code, you better don't 
> change it and take it the way it is maintained.
> 

I am not sure that ON gate will benefit from all your lines of code. And
I am not taking someone's code and contribute it somewhere these days.
If you want to contribute, then contribute in way of rules for
contributions. This is basic rule of every software project (open source
or closed source).

> > > 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.
> 
> If you like me to help you with your work after Sun did ignore my offers for 
> 5 years, you would first need do the work to verify interest and to get the 
> needed credibility. 
> 

My work? With very high probability no line in your source code base is
touching the code I am responsible for. I offered my spare time to help
with sponsorship. I did not offer my spare time to help with porting
your code to ON gate.

> Jörg
> 

Best regards,

Milan

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to