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.)
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)
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....)
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.)
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).
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
