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
