I'll come in again...

 
Folks -

I feel like I've been thoroughly misunderstood in the recent discussion
about using a distributed version control system. Let me try to make my
point as clearly as possible:

First of all I don't *care* whether to use a "distributed" VCS or not.
Is that clear? I really don't. What I care about for a version control
system is how easy it is to use and how well it integrates with the
system I use.

Having been clear on the initial point, my concern in this discussion is
about *why* people seem to be excited about using an DVCS. What I'm
hearing is "great, now we can fork" instead of "great, this will make it
easier to contribute".

There is a difference between a "branch" and a "fork". A "branch" is
something where you (usually temporarily) diverge from the main line in
order to make the original product better. A "fork" is a (usually
permanent) divergence from the main line WITHOUT the intention to make
the original product better. For example, Cog is a branch, Pharo is a fork.

Branches are *great*. Branches allow us to explore directions without
destabilizing the main development. Forks are *terrible*. Forks split
communities, force duplication of efforts, and split mindshare that
would better be spent on making the system better for everyone.

As a consequence, when I hear people being excited about the ability to
"fork" I am starting to ask myself what we can do to avoid the need for
forks. Forks don't just happen - there are events that lead up to it and
I am trying to understand if there's something we can do to alleviate
the perceived need for forking.

I'm not trying to tell you that you *must* host your private experiments
on Squeak.org - I am asking to find out what kind of frustration exist
in our current development process, and what we can do to address them.

Cheers,
   - Andreas

On Jun 27, 2010, at 9:02 PM, Andreas Raab wrote:

> Folks -
>
> I feel like I've been thoroughly misunderstood in the recent discussion about using a distributed version control system. Let me try to make my point as clearly as possible:
>
> First of all I don't *care* whether to use a "distributed" VCS or not. Is that clear? I really don't. What I care about for a version control system is how easy it is to use and how well it integrates with the system I use.
>
> Having been clear on the initial point, my concern in this discussion is about *why* people seem to be excited about using an DVCS. What I'm hearing is "great, now we can fork" instead of "great, this will make it easier to contribute".
>
> There is a difference between a "branch" and a "fork". A "branch" is something where you (usually temporarily) diverge from the main line in order to make the original product better. A "fork" is a (usually permanent) divergence from the main line WITHOUT the intention to make the original product better. For example, Cog is a branch, Pharo is a fork.

a fork as croquet, Tweak and Etoy were (I recall myself harvesting Etoy changes in 3.9 without real support),
so just one more :)
For the record we knew that. Now this was the only way to move and as one of the writer of most of Squeak book and related material this was never an easy decision.

> Branches are *great*. Branches allow us to explore directions without destabilizing the main development. Forks are *terrible*. Forks split communities, force duplication of efforts, and split mindshare that would better be spent on making the system better for everyone.
>
> As a consequence, when I hear people being excited about the ability to "fork" I am starting to ask myself what we can do to avoid the need for forks. Forks don't just happen - there are events that lead up to it and I am trying to understand if there's something we can do to alleviate the perceived need for forking.
>
> I'm not trying to tell you that you *must* host your private experiments on Squeak.org - I am asking to find out what kind of frustration exist in our current development process, and what we can do to address them.
>
> Cheers,
>  - Andreas

On 27 June 2010 22:02, Andreas Raab <[hidden email]> wrote:
Say, i want to build & maintain my custom-built VM with minor tweaks.
Out of my mind: change the icon, splash image, initial window size,
build using custom set of plugins and things like that.
It is fine, when i only need these things in my corner, but when it goes to
share these things, i have a problem: i can't meaningfully share it,
without dubious sets of steps and instructions how to do it.
Does these tweaks constituting a full-blown fork? I don't think so.
Do a custom and/or highly experimental VMs constituting a new fork? I
don't think so.
It is the same as 'my custom 4.1-based image', which i want to share
with people.
So, what is wrong with that? And what harm it could do to the community?

As you said, fork is a divergence from the mainstream.
But you missing one important detail: it is always a political decision, not a
technical one.
For forking, it really doesn't matters what tools you use(d). Because
when you deciding to fork,
this is a least thing you care about, obviously, because since you
forked, you are free to choose
any other tools you might wanna use, tools that different from those
which used by mainstream.

My proposal to switch to DVCS was to make VM contribution process easier.
Easier to share developer's artifacts for review and evaluation.
Easier to track contributions and easier to integrate them to mainstream.

If results of some experiments, for some reason are not folded to mainstream,
then there are only one good reason for it: they are not accepted by
community because either
not very good or userful one.
And if looking from this point, what sense to fork then, since nobody
will use it anyways?

But completely different case, when some artifacts are not integrated,
because of technical issues
related to VM build & distribution process or they are lost and forgotten,
or there are simply not enough time for core developers to review them.
This is not acceptable, because it discourages developers from
contributing to VM and creates an
atmosphere of closed cult of high priests, which the only one who can
decide what to do and when.

> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.

 
Em 27-06-2010 16:02, Andreas Raab escreveu: terrible is when forked communities keep frictioning. I put things like
a divorce: when it happens friendly it's ok but litigious is usually nasty.

In the case of smalltalk and more particularly of squeak I am sorry and
bitter about the forks because community is just too small to allow a
friendly divorce. What is meant here?

First: there's just not enough people to ensure each fork will go ahead.
Most work is done in personal basis, without any kind of corporate
support (even academic) and results are not flourishing in terms of
commercial products, PhDs or even relevant papers. Fact is that even in
squeak.org we can't find a relevant list of recent papers. Much is
implementation of infrastructure that may turn out to have commercial
value (like seaside) but where are (really significant) commercial
results? Why seaside (for instance) didn't catch up like, let's say,
zope & people are still usually unaware even about its existence? IMOH
one of reasons is that efforts are very fractionated and potential
investors are averse of the kind of dispute that arouse inside community.

Second: the forks didn't happen due to extreme different visions related
to architecture or other key technical issues... in fact, most of
discrepancy originated in fields that could not be further from
scientific or technical development. Thus, science and technology didn't
profit from the split and key pending issues (like concurrency, etc)
stay open.

Third: as result of (1) and (2) above, it's not easy to get bucks ($$$)
for research & development either for squeak or any of the forks. Ok...
perhaps one or other of the parts receive some funding for some period
of time but if no papers/PhD/products or media coverage show up money
will just go away and what will stay is a bad name...

IMHO, all "forks" should be branches. It would allow people to keep
cooperating in a friendly way. It would allow people to concentrate in
experiments, science and industry and let "administrative tasks" for a
small committee instead of having "administrative committees" managing
tiny split communities. In Portuguese we say: too many chiefs for so few
Indians ("muitos caciques para poucos índios").
CdAB

On 2010-06-27, at 12:02 PM, Andreas Raab wrote:

> Having been clear on the initial point, my concern in this discussion is about *why* people seem to be excited about using an DVCS. What I'm hearing is "great, now we can fork" instead of "great, this will make it easier to contribute".

I think it's just a matter of terminology. Github has a "fork" button which lets you make a copy of somebody else's public project and set up a separate repository for your own work. Later you can contribute your changes upstream with the "merge" button. This was a really big deal in the Github community, because it made branching into a one-click operation.

So I wouldn't worry about it. After all, people have always been able to fork the VM. What's been missing, and what a DVCS provides, is a way to merge again after you've done so.

Colin

 
Maybe some external input would help here:

http://www.joelonsoftware.com/items/2010/03/17.html
http://redmonk.com/sogrady/2010/04/01/github/
http://utsl.gen.nz/talks/git-svn/intro.html

"Distributed version control software is not incompatible with communal, centralized development. In practice, most projects that use distributed software still have one central repository that everyone syncs and submits to. They're not using the distributed software to split development off into isolated forks; they're using it precisely to allow work to be shared more easily without such hard boundaries between established developers and new contributors."
It's hard to explain the benefits, but perhaps I can show drawbacks. Monticello is a DVCS (albeit the simplest one imaginable and desperately needing better tool support). What would it Squeak development be like if we had no choice but to sync to the one SqueakSource rather then our own local package caches and network repositories? How would this change the ease of making contributions, trying complex experiments, managing the repository, working offline, etc.

Cheers,
  -- John



--
John Dougan
[hidden email]