Hi Joseph, My comments are inline, thanks.
Regards, Bill ----- Original Message ----- From: "Joseph Kowalski" <[email protected]> To: "Frank Che" <Frank.Che at Sun.COM> Cc: <PSARC-ext at sun.com>; "yan xue yang" <Xue-Yang.Yan at Sun.COM> Sent: Thursday, April 03, 2008 2:52 AM Subject: Re: PSARC 2008/212 Integrate Unison into Solaris > Frank Che wrote: >> Hi All, >> >> Here is a summary of issues discovered by now, as well as proposals from >> project team on these issues. If I missed any pending issues, please >> point it out. >> >> Also, I'd like to extend the timer of this case to 04/07/2008. >> >> Issue 1: Unison doesn't support ACL or extended file attributes. >> Proposal: add this to the man page. >> >> Issue 2: Could Unison be a Committed interface? >> Proposal: Considering that >> *) There is still active bug fix activity in the community; >> *) The compatibility may be broken between release update in the >> community; >> *) Unison is purely a user level application, the possibility that >> other Sun products rely on it is very low; >> Project team propose to use 'Uncommitted' stability level for >> /usr/bin/unison. >> >> Issue 3: Maintenance and support >> Proposal: project team commit to import community bug fix when >> necessary in the future. >> >> A few other issues, such as >> * how unison will be integrated into the gate? >> * how the socket method work? >> I think they have been answered clearly, so I will not repeat here. >> >> -Frank > As I mentioned at PSARC, I don't believe everything has been answered > clearly (although I hadn't seen this message at the time I expressed > that concern). See the following from 3/25. Clearly this message > answers part of my concern. > > As far as your Issue 3 above, could you say more about who the "project > team" is in the maintenance sense? Is there a persistent group which > will take on this burden? (Maybe this is more of a c-team issue than an > architctural issue.) The "project team" is the person who do the porting job for unison. We will continue to keep track of the update version of unison and try to integrate the new version of unison into solaris. > > Anyway, I didn't see any response to my first bullet (and sub-bullets). > > My second and third bullets seem to have been partially covered, but I'd > like a little more detail. > > My assertion about Unison necessarily being Volatile may not be correct, > depending upon the other answers. > > - thanks, > > - jek3 > > -------------------------------------------------------------------------------------------------- > > Roland Mainz wrote: > > Erm..."devils advocate" question: If Unison is no longer maintained... > > why should it be integrated into (Open)Solaris ? And how do other OSes > > (like Linux) handle the support issue (e.g. no upstream where they can > > send the bug reports to) ? > > > I see that there has been significant discussion spawned from Roland's > "devil's > advocate" question. I think its a very important question (thanks Ronald!). > However, the resulting thread seems to be a little amorphous. I'd like > to see > concrete answers to... > > 1) For some reason we need to rebuild Unison. How do we (or other > distros based on OpenSolaris) do that? (ie: occum) We don't integrate a binary delivery into the sfwnv, but integrate the source code into sfwnv. The following is the detail how the compilation is done: We'll putback the source code of unison(unison-2.27.57.tar.gz), lablgtk(lablgtk-2.10.1.tar.gz) and ocaml(ocaml-3.09.2.tar.gz) to sfwnv gate. Ocaml is for the CAML compiler, and lablgtk provides the libraries which will be statically linked by unison. Lablgtk and ocaml will be only used during the compilation. Finally, there will be one package SUNWunison generated. And one file unsion(executable) and one file(unison.1) for man page are in the SUNWunison package. > > 1a) Is there any precedent for a binary delivery of an executable? > > 1b) What are the guarantees that this isn't some kind of "trojan horse"? > (Yea, I know its unlikely, but....) Question 1a) and 1b) are based on we are going to integrate a binary delivery, but we are not... > > 2) A reason might need to rebuild Unison, would be the discovery of > a security hole. What do we do? Who fixes it? Would the response > from Sun to be simply remove it (because its not worth the > resources)? > (Other distros can make their own choice.) Unison is no longer under active development as a research project. However, the original developers are all still using Unison daily. It will continue to be maintained and supported for the foreseeable future, and they will occasionally release new versions with bug fixes, small improvements, and contributed patches. We will keep track on unison and try to integrate new version of unsion. As for the socket method in unison, unison is not a daemon program but a hight level user application, it's up to the user to decide whether to choose socket method or not, and this shortcoming has been already documented in the manual. > > 3) Its unlikely, but what if the fix to this mythical security hole > requires an > API/CLI modification. Do we just fork from the accepted interface? > > #2 and #3 seems to make it a requirement that this be Volatile (or > Obsolete Volatile). The answer is same as the answer in question 2. > > I can't assert that I know an obvious answer for the other questions above. > > Is this appropriate for a fast-track? (Because the support issues are > new ground?) > > - jek3 > > > > > > > >
