Hi On Thu, May 5, 2011 at 3:06 PM, Benjamin Fleischer <[email protected]> wrote: > 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). > Did you do any development on this project in the past? No, I did not. Everything I want is to use macfuse for my tool (https://github.com/anatol/tup). During its porting to macosx I spotted a few incompatibilities with upstream libfuse. One one of them is a bug in the macfuse-libfuse (SIGCHLD handling) that I am going to fix. 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. The best of all is to setup a new official repo, send my patches there and make sure that it eventually reach macports. > But most > importantly you did not really tell the rest of us what you plan to do > besides importing all the patches floating around and see where it leads. > - 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 tried to contact Amit about transferring the googlecode project ownership to someone else, but he did not respond. So I think we have to live with it. Or maybe we can file some kind of dispute at code.google.com? > 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). > - 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/ > BTW is there anybody who has access to 10.7 and > is willing to contribute? > - 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. > 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. 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'll try to look at the "macfuse_buildtool.sh -t dist" issue though. Tuxera sources are broken for me (osx 10.6). > Getting the update mechanism to work is not just about fixing the PrefPane > (there are some bugs regarding signing and verifying a signature > nonetheless). For the whole update process to work there need to be a RSA > key pair to authenticate updates and some persistent webspace. > - The private key should not be publicly known for obvious reasons. So > uploading it to the repository would be a bad idea :-) Who should possess > the key? The project lead. > - I figure you plan to use a github-page (as I did) since Tomas' domain > macfuse.org points to github. Is this correct? Yes. > 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. What I am still 100% sure that we need to forget macfuse @ googlecode.com. It is dead. But macfuse community should move forward and setup the new official project home. Macfuse is too important to let it die! -- 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.
