[Nix-dev] An interview to the fossil creator about fossil

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/08/2010 04:34 PM, Evgeny Egorochkin wrote:
>>> If this is it, then it's not terribly impressive:
>>> http://www.ericsink.com/entries/veracity_early.html
>>
>> Let's be honest - neither it is terribly complete. Their field-based
>> merge seems quite extensible, though.
> 
> To be honest, I didn't really look into but because many items on the linked 
> pages triggered my bullshit detector such as:
> 
>  * Apache License Version 2.0 and care towards ogranizations which may 
> hesitate using standalone GPL apps

Well, Fossil claim the same about paranoids forbidding standalone GPL
apps. I easily believe these claims. Maybe MS and Sony do not deserve
any sympathy, but there are many way less evil companies who are just
misguided enough to have the same policies.

>  * Cross-Platform C -- again because some org might "hesitate" to use g++ ?

Because g++2 and g++4 are different platforms.

>  * Enterprise everywhere

Not exactly that. He says about the things enterprises (and generally
change-avoiders with a problem not solved by current tools) would
definitely want.. Actually, I wait what comes out of the project because
I need what is promised (and already visible) in Veracity for our
1.5-developer project with mere hundreds of thousands of records to process.

> Alternatively, this may be a bunch of excuses to heavily commercialize it... 

Which they don't even deny, if you read the announcement. They try to
build open core which and sell
MSVS/MSSQL/enterprise-whatever/ultra-fine-grained-permissions
integration (and commercial support?) to companies.

What is their "core" border is a more interesting question. Their
roadmap says that (most probably) MSVS integration will be commercial,
while Eclipse integration will be open-source.

> this may end up nasty or just fine who knows, since only gpl-like licenses 

Well, it looks like they have some design of the entire system in mind.
It seems to be different enough to either flop or quickly gain enough
support to be self-sustaining. Given that SourceGear founded Abiword,
I'd say "lawsuit scenario" - the only actually nasty one - is quite
unlikely.

> force companies to not discriminate users(eg a bugfix  or a new version 
> available to one customer is legally availale to everyone else).

Oh? You can do discrimination in many ways just fine with GPL-released
code. Especially if you hold copyrights (or broad enough licenses).

GPL only helps to ensure non-discrimination by new companies coming to
the project, not by founders.

>> Frankly, looking at our JIRA usage (it offers a lot; do we use it
>> much?), I start doubting your claims. Maybe tags are enough for us.
> 
> It seems to be due to the workflow:
>  * everyone works in their private branches and commits only stuff that works
>  * issues that pop up are mostly minor and are fixed by responsible people in a 
> matter of hours

Look up the Nix* JIRA. There are also many seemingly-major issues where
nobody suggested what is the best solution (and there are several ways
to try and solve it)...

> Essentially, this means that our bug tracker is memory+IRC+ML. If we suddenly 
> discover this is doesn't scale(very likely) bug tracker will come handy.

Yes. But I predict it will still be an ML with "reaction-tracker". Which
scales relatively well...

>>> Basically it's all about devising a storage format that's dvcs-friendly
>>> and making a web interface for it...
>>
>> There is no such thing as a format that is dvcs-friendly, because things
>> that can be automated with issue tracking merge are not expressible in
>> the DVCS terms. I don't know, when merging two forks of the same issue,
>> severity can be assumed to be maximum of two branches.
> 
> Not at all: someone files a high-priority bug, you fork, someone changes the 
> priority in master to low, you merge

It is not a merge situation, it is inherited-vs-edited where edited wins
every time.

> But you do have a point that it would be advantageous to have structured data 
> and different merge strategies for different data types and file types...

It looks like only veracity currently has an official plan how to handle
that.. Even BugsEverywhere doesn't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMXrzCAAoJEE6tnN0aWvw3IRMIAI7QLvFv005k1Kp7mxD0HLq9
X6lIUvbws+icVsXjorkjdoo6M0Pvce9TXUa6NXad2Mtw88fawUGyaedWZiTk6iab
7oYX6/ztrFNZqBGVOP+qI1rH4caOwLCRgGvBxYNGJeGWy94iOw6J+mhbaWZaqYqK
zu+GewCrdUBpXKOqlHxuh35HlfbXcUV/nv4nPA9SC5lrt8dhkgXXYleSJ4NkYNw1
sGtTC3cTUp/ox4MbQiIupd4sn52Zlxqna7kssyQ3aIbDYH/MM+npj6G/qFiqxyJk
iwkruRDPiWXAiAF39yUnGS4FkMQZiVqEpflB9PAU2Fi/LnMYs3Ae5a9bYHc6Lvk=
=HLGu
-----END PGP SIGNATURE-----