A fork of MC

Pavel Roskin proski at gnu.org
Tue Oct 4 02:07:56 UTC 2005


Hello, Pavel!

On Mon, 2005-10-03 at 15:46 +0300, Pavel Tsekov wrote:
> Hello,
> 
> Recent events showed me that there is no reason for me to hang around
> anymore. Obviously I've managed to piss everyone involved in the
> development of MC despite the fact that I was trying only to help
> improve MC.

Reviewing your posting history I see that you were mostly trying to help
those who don't appreciate it.  I know how frustrating and exhausting it
can be.  If you don't like the result, don't do it.  Ignore "time sinks"
and concentrate on interesting stuff.

>  All my efforts to help with the development i.e.  by reviewing
> and coding patches, debugging, etc are in vain. As such I decided to move
> forward and create a fork of the project. In any case I'll be supporting
> and maintaining the Cygwin package of MC as I did before.

Forks are rarely justified, and I don't think we have a case that
justifies a true fork.

On the other hand, I understand you very well.  Sometimes it's just
important to be in control of all code, to forget about mailing lists
with all their annoyances, when one can "code away" without thinking how
to justify some trivial or not so trivial changes.

I do some work on Linux kernel, and I can tell from my experience that
the new version control system git (plus cogito) makes a huge difference
compared to CVS (I haven't used BitKeeper).  I can disconnect from the
network, yet the repository stays with me.  I can see the history of the
changes.  I can commit changes to the repository.   The repository
records all changes as atomic commits, and cg-log actually makes sense
unlike "cvs log".  And gitk is even better because it shows the history
as a tree.

I know that my patches won't be lost if they are good.  I can make
series of patches and send them together.  Every patch will have a
comment extracted from the repository, and they will be applied with my
comments.  I send patches not to Linus, but to the subsystem maintainer,
who puts them to a specialized repository, where everybody can access
and test my changes.

Patches get merged in both directions.  If I ever want to fork Linux, I
can merge further Linus' changes just as easily as he can merge mine.
The only problem is publishing the repository.

Pavel, I really don't want your code to be lost for mc.  I also don't
want my future code added to mc to be lost for your project, should it
be more successful.  CVS is bad at merging and doesn't give you control
when you need it.

I suggest that before we even attempt any forks we move to a version
control system that will make it easy to keep code easy to merge.
Otherwise, there will be a huge duplication of efforts and very painful
merges.

I cannot find any free git hosting, but we could consider other
alternatives.  Maybe we could use Subversion on berlios.de.  Subversion
works with svk, which is a distributed version control system.  Or maybe
we could persuade some host to give us git or Mercurial hosting.  After
all, mc is a known project.

-- 
Regards,
Pavel Roskin




More information about the mc mailing list