Hi On Fri, May 6, 2011 at 12:53 PM, Benjamin Fleischer <[email protected]> wrote: > Am 06.05.2011 um 15:23 schrieb Anatol Pomozov: > > There a several questions that need to be answered before this happens. > > Correct me if I am wrong but from what I can see you started posting to this > > mailing list about three weeks ago and now you want to be the new project > > head. > > No, I do not want. Tomas Carnecky is the owner of the > > macfuse.github.com. And I am just a developer in this github > > organization. I help him to setup the new home for macfuse and > > consolidate patches (specifically macports patches). > > I am the most vocal supporter of the "new home" idea - so it makes you > > think that I want to be the leader. But I do not want. I want to be > > just a macfuse library user. > > I do not care about my status at macfuse.github.com. I'll happily > > remove myself from the list of the developers if there will be someone > > else who want to take care of the new home (and who will be able to > > review my patches). > > Sorry I got that wrong. Since you have been the most vocal supporter and the > only member of the new organization/repository at github I thought you were > in it for the long run and wanted to be a "new Amit". > > But where to send my patch? macfuse at googlecode is dead. Should > > I send it to macports/tuxera/your repo? Or maybe I should patch > > macfuse locally and ship it with my product? None of them is a good > > idea. > > I absolutely agree. There needs to be an official place to put the code. > > The best of all is to setup a new official repo, send my patches there > > and make sure that it eventually reach macports. > > But there need to be some committed developers and a consensus where the > project is headed. > > - What about the name MacFUSE. I guess having two "official" MacFUSE > > projects will lead to problems or at least confusion. > > Having a dead official project + an alive official project is *much* > > better that having a dead official project and a dozen of incompatible > > forks. > > I think we all agree on the dozen forks part. Forks are great as long as > there is an official source tree. > > If you just use > > MacPorts everything might be fine but if you google it there will always be > > two "official" projects. What if Amit decides to pick up development again > > or pass it to someone else (I don't think so, but who knows)? Amit seems to > > have started a commercial counterpart to MacFUSE called NuFS (Have a look > > at http://iohead.com). Using the name MacFUSE won't work unless the original > > google code project points to the new project page or "disappears". I don't > > see that happening at the moment (conflict of interests). What do you > > think? > > In addition to that I'm not sure if adopting the name MacFUSE could lead to > > legal troubles. I have no legal degree or something like that so correct me > > if I'm wrong but MacFUSE belongs to Google. Amit has been an Google > > employee. > > See http://code.google.com/p/macfuse/source/browse/trunk/COPYING.txt > > The sourcecode is BSD - it is ok to fork it. Macfuse is not a > > trademark and is not registered neither to Google nor to Amit. So the > > name is Public Domain - everyone can use it. (But of course it is > > better to have a lawyer opinion here). > > It might be a bad idea because the community could scatter even further but > if the new MacFUSE successor project had a different name there would be no > legal problems but most importantly there would not be two official projects > titled MacFUSE.
I do not care that much about the name. What I really care is working code without bugs. Although your point is valid. > The preferable solution would definitely be to add a link to > the googlecode page pointing to the new project home and continue using the > name MacFUSE. > > - What Mac OS X versions should be supported? I would suggest dropping > > support for 10.4 and 10.5. The existing MacFUSE versions 2.0.3 and beta > > 2.1.5 run just fine on 10.4 and 10.5. That will make development a lot > > smoother in the end. Supporting 10.6 (Intel) and later 10.7 should be > > sufficient for new releases. > > I haven't thought about it. I am in favor of removing the old releases > > support - this reduces the development and testing efforts. From other > > side ~25% of all macosx users still use version 10.5 and lower. > > http://update.omnigroup.com/ > > Everyone on 10.4 and 10.5 could keep using the old MacFUSE versions. There > is no need for 64 bit or Snow Leopard support. But I see the point Alex made > that it is easier to compile a filesystem (that supports 10.5 or even 10.4) > only once against one library instead of distributing different versions > depending on the version of Mac OS X somebody is using. This by the way is > exactly what MacFUSE does, distributing different versions depending on the > version of Mac OS X bundled together in one huge installer package. > > - Who decides which code makes it into the "official" tree? In other words > > who will have write access to the repository and who will be in charge? > > I would prefer that Erik be the tech lead of the new repo. And taking > > into account the situation with the old macfuse project I would love > > to see at least several developers with write permissions in the > > macfuse organization. > > I don't remember anyone asking Erik directly so: Erik would you be willing > to take this job? Be the project lead of a new MacFUSE project? I am joining you here. Erik, would you like? And sorry for the my tone at the beginning of the thread. I am not as bad as you might think. > > In the end just collecting patches won't do the job. > > I started where you are now (code-wise) and am happy that I got the whole > > thing (macfuse_buildtool.sh -t dist) working after investing many hours and > > now you ask me to fork your code base . Depending on the versions of Mac OS > > you plan to support this will be a lot of work (since I dropped everything > > but 10.6 and use the 10.6 SDK instead of 10.5 as Erik's/your code does). > > From where I stand, it would be far easier if you just forked my repository > > :-) I'm not willing to put that much effort into patching up everything > > again just to use your code base as a starting point if the future of your > > project fork is this vague. > > Do you see the problem here? The problem is that personal ambitions > > are bigger than the project needs. > > That's exactly why I posted some open questions, I feel we need to discuss > first. > > Everyone thinks that his fork is > > the only-true-macfuse and it should be the starting point of the > > official repo. You cannot satisfy everyone here. > > I absolutely do not feel that my fork is the "only-true-macfuse" fork to put > it with your words. I just said that I don't want to invest much time in > porting that stuff over to Tomas' (or now ExpanDrive's, I guess) macfuse > repository at github if its future is this vague. BTW I find it kind of > disturbing that the ownership of the organization seems to change without > even being discussed in this group. Yeah, I am worried as well, especially taking into account that they owned macfuse.github.com for a half of year and did not do anything ("git svn clone && git push" takes just a few minutes). > And for what it's worth I have not seen any other MacFUSE fork that uses > Erik's great locking code, builds from bottom to top (target dist) and gives > you a working PrefPane/update mechanism. Erik did a great job, but he > focused solely on the fusefs kext (to implement support for 64 bit kernels). > The result is a "core" package that works really well, but for the end user > there is no easy way to update it or to get rid of it if he/she decides to > (if you are not using MacPorts). If you don't know you way around Terminal > or the depth of your Library directory you would not even know it is there. > If you install a different application also relying on MacFUSE it will most > likely "update" it. Most users will never know what hit them and why some of > their applications are no longer working as expected. At least in my opinion > a working update mechanism is vital. All parts of the project are important (such as Obj-C/sshfs/...) Macfuse needs more contributors who is responsible in its own area, plans features, reviews patches. This is a standard practice for large opensource projects. > I would suspect there are more questions that need to be answered if working > > together as a community on a new project fork should have a change of > > success. And of course we would need at least some dedicated developer for > > this to work. > > I would love to see you and all other developers working on > > macfuse.github.com. I can ask Tomas to transfer commit permissions to > > you or Erik if you think it is blocking you. > > That will now be ExpanDrive's call, I guess. -- You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/macfuse?hl=en.
