[Savannah-hackers] Re: Fighting BitKeeper: There is no such thing as a Free Lunch

[Mathieu Roy]

Shlomi Fish <address@hidden> said:

> At the moment the situation in the free software world is that two
> alternatives with public hosting exist:
> 
> 1. CVS - old, reliable but a pain to work with. Fully Free.
> 
> 2. BitKeeper - very good, and a joy to work with. Distributed under a very
> restrictive license.
> 
> Subversion is an alternative that is somewhere in between. It is much
> better than CVS, a joy to work with too, and aims to be as feature-rich as
> BitKeeper one day. However, it has no public hosting and so has very few
> users.
> 
> Now, open source developers cannot chose it because they cannot host their
> projects at a centralized place. So, they must either use CVS or
> BitKeeper. Some are not very idealistic and use BitKeeper because of its
> superiority despite its restrictions. I know of someone who is much more
> idealistic than I am who told me he will continue to use BitKeeper to keep
> track of the Linux kernel development, because he does not see himself
> contributing to Subversion, Arch, Aegis or its likes in the future. This
> was very alarming to me.
> 
> Now, obviously the Subversion people wanted to rely on cutting-edge
> technology so they used Berkeley DB 4.0, and Apache 2.0. This might be a
> problem, but in order to make sure it can compete with BitKeeper we need
> to overcome it. You need to make some effort in raising a Subversion
> server, if you want people to ditch BitKeeper for good (and for the
> Subversion development to accelerate - more users = more development[1])
> 
> If you OTOH reject Subversion because it is not straightforward to install
> on your Debian Stable (%-)) systems, then it will take much longer time
> for it to develop, and meanwhile innocent developers will be lured into
> the BitKeeper and bkbits.net service (which are excellent except for the
> bad licensing).
> 
> Note that Aegis and Arch do not give a sufficient answer to CVS, BitKeeper
> or Subversion. Arch has a relatively hard process and is very slow. Aegis
> is very professional, but it is more of an SCM than a revision control
> system, and many people don't want to be bothered by its unique process.
> (they just want to check in, check out, merge, branch, etc). Installing
> them as well won't be a bad idea, but only Subversion would be suitable
> for the masses.
> 
> I am willing to give any help I can in setting up Subversion, Apache 2.0
> and the other stuff there. They can easily be installed on a separate
> directory, and I believe can also run as a non-root user. They will occupy
> a different port than usual:  8080 and 8081 for mod_ssl. Thus, they should
> pose a minimal implication on the security of the server. Subversion can
> be updated by checking out the latest version from its own repository
> (bootstrapping a new version based on the already installed old one), and
> Apache 2.0 has a CVS server that we can update from. I think DB 4.0 is
> very stable.

I'm not convinced at all by your demonstration. Do you seriously
propose to use a CVS-version of apache? 

I see here no strong arguments ("I think DB 4.0 is very stable",
"Aegis and Arch do not give a sufficient answer to CVS").

People that can really argue on the Apache stability are for instance
the apache debian maintainers.

There two reason to refuse your proposal:
        - short time: this software is not considered as not been 
          accepted in stable cat by the distribution we use
        - long time: we will not recompile from the source softwares
          each time a security hole is found - and so, we should not 
          install from sources at all.

If Subversion rely on software unstable, so Subversion is not
stable. And so we should not spend time to propose it until it begins
to rely on software we already can use and that are known to be
stable. We currently have only the time to make sure the current
installation works. We're open to new service hosting, but in the new
subversion, it does not only means installing a new service but
installing concurrent version of the same softwares. That complicates
and really creates extra work.

Also, I'm not agree about what you said about CVS and BitKeeper.
CVS is not "a pain to work with". Note that Linus T. havent ever used
it on the Linux project (if I'm not mistaking). 
But CVS means concurrent development, and Linux is not developped in
that way. 
Also, Bitkeeper is not "Distributed under a very restrictive license"
but is a proprietary software. It means that currently its license is
very restrictive but in the future it can be worth.
Currently, you cannot use free as beer BitKeeper version and being
employed by RedHat or being a Debian maintainer. But in the future,
thoses restrictions can apply to the free version too. 

So, Imho, there're not "two alternatives" for the "free software
world".

I'm not agree when you said that in fact, we should accept your
proposal "if [we] want people to ditch BitKeeper for good". Usage of
BitKeeper is made only by a few and they should be aware of what it
means - and assume their choices, as political as they are, despite
the technical pseudo-matters. 
No one is innocent. There are no "innocent developers [...] lured into
the BitKeeper and bkbits.net service". Each person must assume the way
he acts. And choosing a to use non-free service depends completely on
oneself. When free software began, no free software was better than
the proprietaries alternatives; but people start using it. Using the
better software technically is not innocent. 

Installing Subversion on savannah.gnu.org shouldn't be done unless it's not
completely experimental and only once it only creates the extra work
for the software in itself, not extra work on the whole server with
different apache running etc (despite the fact one can install thoses
software, others will have to maintain it in the long time).

I'll try to take a look seriously on aegis and arch.

Regards,

-- 
Mathieu Roy
 
 << Profile  << http://savannah.gnu.org/users/yeupou <<
 >> Homepage >> http://yeupou.coleumes.org           >>
 << GPG Key  << http://stock.coleumes.org/gpg        <<