I'll be contacting Erik to see what involvement he wants to have. We're mostly interesting in making sure there a good steward for the project longer term. And since we have a very vested interest in the continued success of the project and the development of a community who can help maintain it, we registered the MacFUSE account with the intent of doing just this. Apologies for the back and forth over ownership, GitHub got a bit confused.
Regarding 10.4 support, I'm all for dropping it. I'd also be in favor of dropping PPC support, as it has been a very long time since Apple shipped new PPC machines. It is true there are a reasonable number of folk out there still running them, but in terms of continued forward development I think it might make sense to consider whether or not PPC support is more of a hinderance for anyone doing dev & testing. -Jeff On May 6, 3: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 > >> athttp://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. > >> Seehttp://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.
