search

suffuse / go-suffuse

go client for suffuse
Other
6 stars 1 forks source link

Pull in updates to travis code #23

Open paulp opened 9 years ago

paulp commented 9 years ago

I opened a pull request at bazil/fuse which includes the results of lots and lots and lots of fiddling in the "travis casino". One of the more useful things is having the test suite work even for forks - any multi-package go project which is forked and run on travis will fail unless there is intervention to fix the package paths.

Anyway, once that's stabilized/merged let's pull into here too.

paulp commented 9 years ago

90% of my pull requests to other projects are summarily dismissed so I shouldn't be surprised that this one fell into the 90%. I shouldn't be, but my capacity for surprise is apparently unquenchable.

I forked bazil to suffuse/fuse where I merged the travis-ci integration. I'd been accumulating reasons to fork it anyway so this pull request was as much a means of discovering whether forking could be avoided as it was of getting test integration. In the long run there's no way to avoid suffuse being in control of the interface all the way to the kernel. For that matter it's unlikely we can avoid either forking or becoming heavily involved in osxfuse, libfuse, and the linux kernel. But we'll worry about lower layers when they've become the progress bottleneck.

There is another fork of bazil which merits a close look - it has diverged far enough that there's no reconciliation possible, but the non-bazil fork looks a lot more sensible to me. It's jacobsa/fuse.

paulp commented 9 years ago

I just assigned you to solicit any comments.

EECOLOR commented 9 years ago

It seems jacobsa/bazilfus is his actual fork and the jacobsa/fuse is a wrapper around that (I like his readme though). I don't mind forking, but we should watch out for the following graph at this stage:

Oopsie

Our first priority as I see it should be to exploring the landscape and provide good (and working) demo material. Go seems to do a fine job at that but you mentioned it will not be the language in which the server will be implemented.

I might have an unclear picture of your vision, if it will be go client --> scala server --> go fuse driver then it might be worth it. If we end up not using Go to talk with fuse / kernel / ... the investment might not be worth it.

At the moment it seems our focus should be on a clean (as far as possible) implementation of go-suffuse to explore and demo.

Anyway, your vision needs to be a bit more clear to me before I can say anything that makes sense regarding the forks.

paulp commented 9 years ago

That graph is my whole sad life. Half the reason I keep you around is to prevent that graph. So I'm with you 100%. I will expand on why I propose it (not this second) and you can tell me how things look after that.

dwijnand commented 9 years ago

That's an awesome graph..

On Thu, 9 Jul 2015 at 23:21 Paul Phillips notifications@github.com wrote:

That graph is my whole sad life. Half the reason I keep you around is to prevent that graph. So I'm with you 100%. I will expand on why I propose it (not this second) and you can tell me how things look after that.

— Reply to this email directly or view it on GitHub https://github.com/suffuse/go-suffuse/issues/23#issuecomment-120164323.