[Info-vax] Where to locate software

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 13-Jun-16 9:41 AM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Where to locate software
> 
> On 2016-06-13 13:02:02 +0000, Kerry Main said:
> 
> >>
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> >> lawrencedo99--- via Info-vax
> >> Sent: 12-Jun-16 8:50 PM
> >> To: info-vax at info-vax.com
> >> Cc: lawrencedo99 at gmail.com
> >> Subject: Re: [New Info-vax] Where to locate software
> >>
> >> On Monday, June 13, 2016 at 8:30:04 AM UTC+12, Kerry Main wrote:
> >>> Q - perhaps I am really old school, but should not VCS systems have
> the
> >>> capability to prevent code from being updated (read-only) when it is
> >>> checked out for update by someone else i.e. similar to document
> mgmt.
> >>> strategies?
> >>
> >> After many years of experience with this in the real world, it was
> >> discovered to a be a very, very bad idea.
> >>
> >
> > Can you share some of these experiences and what the challenges
> were?
> >
> > I can see using VCS systems like Git when you have to deal with
> > external code updates like the VSI folks, but when you have a closed
> > system that uses mostly custom code, I just do not see the logic.
> 
> Trivial replication, distributed access from client systems.   In the
> case of Stark, the canonical source server somewhere, and local copies
> on various clients doing local development and testing, trivially
> synchronized with updates.  When you're done, push the changes to the
> repositories, and get the build and test bots — those are part of newer
> tooling, and not something typically found on OpenVMS — these are
> somewhat akin to "database triggers" with a relational database, but
> that perform automatic source formatting on checkin, and code
> integration and testing at checkin — and made available to the rest of
> the team.   Having to haul files around even inside an organization —
> check out the files, haul them somewhere, get the environment set up,
> then keep that environment updated as files are changed by other
> developers — is both more work and more fodder for introducing errors
> and regressions.    A DVCS also means you can be developing locally,
> even when the main source server is offline or inaccessible for some
> reason.   

Again - in today's world, why should the dev environment be offline?
It’s a prod environment in its own right.  Why do DVCS's only ever have
A single server as the primary source server? In today's world that is so
old school ..

> Subversion and DECset CMS assume you're all working on the
> same cluster, and that the pool is always accessible.

Of course, Dev is a Prod environment just like the real Prod environment.
Just because past environments treated Dev as a lower class priority does 
not mean that is the way Dev should be treated.

> Seriously.  Go use the tools.   You're the CIO.   That means you're
> making technical decisions for the infrastructure, and that means you
> get to use and learn about new tools.
> 

It's not about a unwillingness to use new tools. It's about not wanting to
use outdated practices of the distributed world when the reasons for
a distributed world (unreliable or unavailable networks, single back end 
server being down) have changed in the future much more centralized 
world.

> > Certainly willing to have my eyes opened for the right reasons, but
> > notjust to become politically correct in the developer world.
> 
> You seem to fight against change.   That's laudable — when it's done
> for the right reasons.  But unfamiliarity with tools or — worse —
> picking the wrong tools, or resisting better tools, is a serious
> problem for any organization.   These decisions and the fallout from
> these situations you've certainly experienced while working with
> enterprise organizations, too.   Senior folks that pick the tools in
> isolation and based on {some mandate, something heard at the
> executive
> golf game, whatever} and leave the staff to deal with the fallout from
> that decision.  Learn the tools, do your due diligence, ask your own
> folks questions, test the tools yourself or get folks you trust to test
> the tools.  Don't get stuck on what was, and completely miss what will
> be.    In this case, your phrasing and your whole approach certainly
> implies you've already made your decision here, too.   Without having
> any personal experience with the tools.   Please.   Don't be that
> manager.
> 

I am doing the due diligence, but the more I understand what is really
happening below the covers, the more I realize how much hype there
really is in the industry.  

https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ 

That is not to say a DVCS is not the right solution for someone else, but 
I need to address the requirements (those things that get in the way of 
"cool" technology) stated in an earlier post in this thread and right now 
there is no DVCS that meets these requirements. 

Anyway, this has gotten OT to this thread.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com