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. 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? >> 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. 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. >> 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. Regards, Benjamin -- 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.
