[MPlayer-dev-eng] mp-G2 pre18
D Richard Felker III
dalias at aerifal.cx
Tue May 6 00:28:04 CEST 2003
On Tue, May 06, 2003 at 12:26:23AM +0200, Arpi wrote:
> > > I don't plan to put it into CVS.
> > > Maybe into arch (or bitkeeper, maybe subversion), later, when teh whole
> > > framework and directory/file structure is stabilized.
> > Please use something free (subversion) (or arch?) instead of
> > bitkeeper. It's your code of course, but personally I highly object to
> > using a nonfree version control system.
> I also don't like bk's license, but usability is somehow more important for
> me than silly licenses (as it is/was for old mplayer too)
Well I understand the usability aspect, but from another very
practical perspective, I expect there are several people who want to
be involved in mplayer development but who do not want to depend on
non-free devel tools. Offhand, I would guess myself and some of the
ffmpeg people, but I expect there are others too. Using a system that
alienates developers is not a good usability decision, imho...
After all, we WANT the prople who are serious enough about free
software to reverse engineer and write codecs to get around
proprietary restrictions working on mplayer. We don't want to drive
them away with nonsense like this...
> I also dislike subversion for various reasons, one of them is that it's
> under heavy development, a few months ago it was not even stable enough to
> host itself. Also it still not more than cvs + a few small hacks.
> But I don't know it enough, never used it, so i don't want to do criticism.
> Arch seems to have comparable feature set and stability to bk, but is GPL,
> anyway the source (and the whole project) is somewhat very unusual/strange.
> Some advantages that its author also hate bloated things, including
> the gnu auto* tools :)
> (and he even developed a modular hand-written configure/makefile system)
This is a big plus. :)))))) IMO it'd be cool for mplayer to give some
large-scale exposure to such a project. If the config/make system are
really nice, perhaps we could even use or adapt them for mplayer
itself. (I haven't taken a look yet, just talking off the top of my
More information about the MPlayer-dev-eng