Dan Price wrote: [snip] > That aside, I don't plan to engage in your-patch-vs-my-patch. At a > practical level, our processes are not sufficient to mitigate a dispute > between two competing implementations of the same technology. More > importantly, I support some of the high level goals which Roland's > project is already pursuing, such as the goal of having ksh93 in the > OpenSolaris project.
Are you talking about "OpenSolaris" or "OS/Net" in this case ? =:-) Note that I started this project with the clear goal of integration into OpenSolaris while thinking (and many others thought the same way or still are not aware that there is a difference) about "OS/Net".. I really wouldn't have started the project at all if the only goal would be the "inclusion into SFW". One of the goals was always integration to "OS/Net" and then - step by step - start to replace the old ksh with ksh93 at consumer level and finally migrate /usr/bin/ksh to ksh93 and maybe even /sbin/sh (as a follow-up project). And to make it clear (I wrote this elsewhere, too): We will not make the shared library interfaces public before ksh93s (="ksh", spec="93", version "s") or later, but use it in OS/Net long before that point. IMO that alone justifies an integration into OS/Net - otherwise OS/Net would depend on non-public interfaces which live in a completely different consolidation (and likely under completely different and less strict review/mainataince/etc. scheme). The problem right now is that we "only" add ksh93 to OS/Net without any other dependicies to avoid complexity in the ARC case or causing pain for anyone else (this is why I am very opposed to a "flag day" - if we go and hurt other people with the libcmd thing we could enable all the other more complex changes like the kernel module to support compiled shell code, too. But I am not really happy with that, I usually prefer to avoid turning other people's day into a living hell when there is no compelling reason for that...) which generates lots of attack points for the "ksh93 in SFW" fraction - and any argumentation against it needs to be done with care because the wrong argumentation generates even more debates and questions. I think at some point the SFW discussion needs to stop - I answered more emails about the "ksh93 in SFW" debate in the last two weeks than I wrote or answered any ksh93-related emails in the last three months (!!) and if this kind of load continues I am simply going to croak (note that I am a volunteer and I am not even working for Sun which means I have to work for food elsewhere and my resources (including "free time") are a rare resource). I really really like to return to hacking code somehow... > So I have no interest in trying to take the > project away from him. And finally, I appreciate his efforts to > trailblaze and show how projects run by community members who don't work > for Sun can succeed (and certainly he will provide valuable feedback > about what was broken about the process and what needs to be > streamlined). Well, that's already on my ToDo list to summarise some of the issues we've hit. This starts with simple items that we need a BugZilla (and I am asking specifically for "BugZilla" from bugzilla.org in this case) to organise things (to avoid large amounts of private email traffic which should have been done in a public bugzilla), the problem that Sun still tries to run an OpenSource project like OpenSolaris.org with what I call "company rules", that integration should be done much faster and in smaller pieces (the last item is actually very important since I am not aware of many volunteers who are actually able to wait that long for a putback, almost everyone else I know would have left the project in anger (which is an understatement) long ago) and a couple of Sun-speficic issues which shouldn't be discussed in the public right now. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)