[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] arch 2.0 survey followup
From: |
Mark Flacy |
Subject: |
Re: [Gnu-arch-users] arch 2.0 survey followup |
Date: |
Mon, 01 May 2006 01:53:16 -0500 |
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.