Re: arch 2.0 survey followup

On 2006.04.30 13:55, Talli Somekh wrote:
> 
> * Windows is critical. I have inside information that one of the  
> biggest software companies in the world evaluated GNU Arch but  
> rejected it in favor of Perforce because windows was not supported.  
> This was before the Great Schism when everything went Python.

(snorts out of nose)  Sorry, I find that difficult to believe without  
the name of the company.  (Looking *very* quickly over Perforce's web  
page, it looks like ClearCase without dynamic views.)

I will agree that if Tom wants to use Arch 2.0 to feed his family,  
then Windows support is critical.

I won't agree that Windows support is critical for GNU software.


> 
> * A GUI is critical. A thought that Tom and I discussed previously  
> was to build a GUI using a web framework like Ruby on Rails that  
> has very good ajax functionality so that a rich GUI can be built  
> that is cross platform and can be run either in a client server  
> enviro or as a desktop app. Designing the system with thoughts  
> about a GUI now using a light framework atop of the system would be  
> a big win, particularly when one of the potential users is a  
> manager (see scenario above).

Umm, sure, if that's what you think.

 From my experience in a rather large software development company,  
my managers don't really care to use a version control system.  They  
are more interested in the integration of a version control system  
and a software defect reporting/tracking system.  They want to be  
able to...

1) Track who changed what.

2) Associate certain versions of files with a release of a software  
product.

3) Associate certain changes with certain bug fixes.

4) Apply the changes associated with certain bug fixes to older and  
newer versions of the product from where the bug was reported.

5) Provide some control over the submission of changes so that  
designers do not submit without architect approval of the changes  
during normal product development.

6) Provide some control over the submission of changes so that  
designers cannot submit code without managerial approval during the  
testing phase of product development.


Managers *don't* use version control themselves; the presence or  
absence of a GUI really doesn't matter to them.  They want to manage  
their software development and that normally require control over the  
process.  They would find a GUI to manipulate those controls to be  
useful.


It has also been my experience that any system relying upon a GUI to  
get anything done is going to suck ass, unless the things being done  
are rather simple.  Version control can have complex moments.

Of course, if you believe that Windows support is critical you would  
(by necessity) believe that a GUI is critical.