RE: [Gnu-arch-users] Re: may I pick your brains?

[Parker, Ron]

> From: Miles Bader [mailto:address@hidden

>   o Easy distributed development, especially `distributed 
> branching' --
>     you can make a branch off of _someone else's_ archive, even you
>     only have read access, and doing so is very cheap.  Merging back
>     and forth is easy once you've done this.

I won't try to explain my flow of consciousness, but the above point
eventually triggered the following response.  I am also certain that almost
anyone could express it more eloquently.

If the target for the web site is marketing to non-technical corporate
types, I know that if I brought up "distributed development" and
"distributed branching" as bullet points one of the concerns brought up by
the networking group would be, how can "we" be sure all of "our" code is
backed up in case of disaster?  "If developers can archive there code where
every 'they' want, how can we be sure its backed up?"  (Too many corporate
environments cover bad processes by a crushing fiat of policy.)  But if I
phrase it in terms of "sandboxing" or "easy integration of discrete
features", I could avoid setting off those proximity alarms.  

"Sandboxing" seems to be a somewhat popular term that does little more than
describe the empowering of individual developers to work on fixes or new
development without stepping on each others toes.  (We understand that this
is something we all do with any SCM/CM tool.)  But, it does grab a hold of a
term that managers may already know from other source code tools and
certainly from the VM world.  The advantage that arch holds in this case is
one that is expressed by my next point.

"Easy integration of discrete features."  In our environment, we often have
an initial list of features for a given software release.  This list is most
definitely subject to scope reduction or change as the release date
approaches and unforeseen business issues push other items to the top.  If
various features are developed on separate branches, then it is easier to
cherry-pick only completed the features for a release and to defer others.
In our environment, nothing frustrates a developer more than having to pull
his or her changes from a release and loosing the ability to easily get them
back in at a later date.  (Such is life with SourceSafe[sic].  There is
nothing safe about it and it makes even CVS or RCS look good, but it does
have a GUI that even an idiot can understand.)  Speaking of deferring a
feature leads to the next point.

"Never lose development when having to defer a feature."  Since features can
so easily be developed independently it is easy to "place one on the shelf"
and grab it off again at a later date.

This may all seem absurd or irrelevant in the world of free software
development, but it makes far too much sense sitting in the ominous shadow
of corporate fear.