<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Damian,</span></div><div><br><span></span></div><div><span>I created patches for oi-sfe to update SFEfuse to fuse 2.8.6. This supercedes the original fuse sources from the OpenSolaris (OSOL) website project.</span></div><div><span><br></span></div><div><span>Still, the original OSOLfuse 2.7.1 lives in the oi-SFE repo for now to use and test.</span></div><div><br></div><div>Once the official stable releases of the distros are out (like Solaris 11 and oi_*), I'll refine things a bit more.</div><div><br></div><div>~ Ken Mays</div><div><br></div><div><br></div><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Bayard
G. Bell <buffer.g.overflow@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> OpenIndiana Developer mailing list <oi-dev@openindiana.org><br><b><span style="font-weight: bold;">Sent:</span></b> Friday, November 4, 2011 2:41 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [oi-dev] Fuse and NTFS-3g<br></font><br>
On Thu, 2011-11-03 at 09:58 +0100, Damian Wojsław wrote:<br>> Hi<br>> <br>> I would like to work on inclusion of fuse and ntfs-3g into main <br>> openindiana package repo and also maintain packages if they get <br>> included. Is OI interested?<br><br>Two points: this project is now hosted at <a target="_blank" href="http://opensolaris.org">opensolaris.org</a>, so please<br>consider forking it somewhere like bitbucket (it requires both Studio<br>Express and gcc, so I'm not sure if we'll need a fork for that<br>reason--however way you cut it, nothing on opensolaris.org is getting<br>care and feeding in the open, so I don't see why you wouldn't re-host it<br>at this point). I also take Gordon's point about the stability of<br>something like a semi-orphaned kernel module for which we don't have<br>upstream issue tracking (forking gets this out in the open). Whether we<br>flag this by repo or other metadata (and there are other
cases where we<br>ought to consider this, such as transitioning off of legacy libraries),<br>we should have some way of marking caveat emptor.<br><br><br>_______________________________________________<br>oi-dev mailing list<br><a ymailto="mailto:oi-dev@openindiana.org" href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>http://openindiana.org/mailman/listinfo/oi-dev<br><br><br></div></div></div></body></html>