On Mon, Mar 24, 2008 at 09:35:20AM -0700, Garrett D'Amore wrote: > > contents of your file system! The socket method is provided only for > > expert users with specific needs; everyone else should use the remote > > shell (ssh) method. > I presume that if there is a server here, it is not enabled by default? > Can you confirm, does this project adhere to the Secure By Default rule? > > If there is a server, how is it administered, if at all?
This is important. > >4.3 Limitations: > > There are a few limitations in current version of Unison [2]: > > > >4.3.1 In the interests of speed, the update detection algorithm may > >(depending > >on which OS architecture that you run Unison on) actually use an > >approximation. > > This point has me concerned. What are the failure modes here? Will > Unison incorrectly detect clobber a file? Will it *fail* to copy a file > that has actually changed and should be updated? Heuristics here make > me queasy, especially for a system that is intended for possible use in > maintaining backups. > > How will users have this information? This is less important. The i-team can't be expected to fix shortcomings of Unison. > >4.3.4 Unison does not understand hard links. > > That's pretty unfortunate. [...] Same comment. > >4.3.5 Renaming directories that containing "ignore"d files may result > >in loss > >of data. > > That's a potentially bad failing. Unintended loss of data is never a > good failure mode. > > It seems (to me at least) that this tool can easily be used in ways > which are potentially destructive. (How destructive depends on the > answers to the above questions.) While I understand that such a tool > can be useful, it has some pretty significant caveats. Same comment. The ARC should want to make sure that Unison's shortcomings are properly documented. The ARC can't expect i-teams to fix the FOSS they are integrating -- only the how it is integrated. My point: we can't pick nits with the FOSS that the i-team can't be expected to fix -- that only slows us all down, and it wastes everyone's time. Ensuring flaws are documented, bugs filed, ... -> sure. Fixing FOSS code -> no. > >4.5.2 Exported Interfaces > > +------------------------------------------------------------------+ > > | NAME | PROPOSED | DESCRIPTION | > > | | STABILITY LABEL | | > > +-----------------------+-----------------+------------------------+ > > | SUNWunison | Uncommitted | Unison package | > > |-----------------------+-----------------+------------------------| > > | /usr/bin/unison | Committed | Unison executable | > > |-----------------------+-----------------+------------------------| > > | ~/.unison/default.prf | Uncommitted | Unison default profile | > > +------------------------------------------------------------------+ > > I probably shouldn't repeat this, but I am again concerned about > Committed for an application that seems to have a somewhat limited > audience and may itself no longer be actively developed or maintained. > (See http://www.cis.upenn.edu/~bcpierce/unison/status.html for that > status information.) This is all the more so given the above > limitations, which it now seems are unlikely to be resolved given the > development status. I agree. Make it Obsolete, make it Uncommitted or Volatile and add a note explaining what changes might be coming, if any. > The more I think about it, the more I'd like to see ARC have some > oversight about how things like this are delivered -- this seems ideally > suited for an external repo -- readily accessible to users that want it, > but not installed by default. Why shouldn't they be installed by default? Noone types "unison" in their shells by accident. Flawed apps can still be popular. The ARC should not be a judge of popularity, much less should it try to keep out popular FOSS on the theory that doing so protects the users. > Certainly, the value of the "stability" of the path name of an > executable seems significantly reduced without some idea of how and > whether it will be delivered by default. But that's only true if one grants your point about not installing things like Unison by default, and even then, if the stability covers things like a program's CLI, or an API, then it has value even when not installed by default. Nico --
