Re: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)

[Samuel A. Falvo II]

On Wednesday 03 December 2003 08:55 am, Tom Lord wrote:
> It seems to me that the larger community and the vendors are in a kind
> of symbiotic relationship these days.  And everyone knows that,

Unless you're a customer of Microsoft.  Read their EULA sometime for 
Windows XP, and you'll realize that they're raping the customer royally.  
It's a pity, because Microsoft is digging their own grave doing this: 
they wouldn't have to resort to glorified shareware in order to support 
their sales if they'd just stop raping their customers.

> And also don't get me wrong about business use of arch.  If forced to

This leads me to question what the business use of arch could be.  Right 
now, the CVS and SVN management models are perfect fits for businesses 
looking to use some kind of source code management tool.  Traditionally, 
corporations prefer hierarchy.  Their is the CEO, and under him, the 
CTO, COO, et. al.  Under those, you have your senior level managers, and 
under them middle managers, then division managers, then ... ad nauseum, 
until you reach `the shop floor.'

It follows that businesses expect this same kind of support from their 
source code management software.  What appeals to many businesses is 
that CVS and SVN have a *single* repository, which *one* person is 
*responsible* for maintaining.  If something ever happens to that 
repository, that one poor soul is in for it by management.  E.g., 
hierarchy leads naturally to paper trails, even if the paper is virtual, 
and paper leads naturally to chains of command and responsibility.

arch encourages a development model which is antithetical to the way most 
businesses work, I think.  Support for star-merging greatly reduces the 
political influence of the "repository maintainer," as people in the 
development group can star-merge directly from each other, completely 
circumventing the repository maintainer.  Then, when the repository 
maintainer needs to perform an integration, there may be a module that 
(s)he doesn't want star-merged with something that (s)he does want, 
which can lead to increased integration times, and woe is he, additional 
work to weed out the changes (s)he doesn't want.

You know and I know that this is a bogus excuse.  But managers don't know 
this, and *won't* know this.  They'll quite often have nothing to do 
with the idea of thinking about things differently[1].

> All I know is that there should be more work on the libc-alternative,
> libhackerlab.  GNU libc is _so_ 1980s :-b

I'd be willing to assist if I weren't involved in my own project at the 
moment.  Unless you want me to contribute my text editor's object model 
(based on, but not exactly, GTK's object model) and persistence engine.  
:)  I'm still developing those, though, so it's not ready yet for public 
consumption.

If you're interested in the progress of qm (my text editor), you can 
fetch its sources here:

  address@hidden
    http://www.falvotech.com/{archives}/qm-2003

Note that I'm playing with literate programming with qm, partly for the 
learning experience, and because I personally feel that many open source 
projects lack important 'internal documentation' or hacker's guides.  
This tends to lead groups of developers to form cliques.  I wish to 
avoid this situation at all costs, as I feel it ultimately hinders open 
source's progress and acceptance.  Consequently, to build what little I 
have, you need nuweb, some kind of LaTeX with BibTeX support (I 
currently use teTeX as supplied by the Slackware 9 distribution), and, 
to actually run the unit tests, my CUT 2.3 tool.  (Trust me; it will all 
be much more worth it once I get into the meat of the program.  Right 
now, I'm coding all the boilerplate to make the real essance of the 
editor a reality.)

Note that I do work (I *really* need to find alternative sources of 
income; In-N-Out Burgers just isn't cutting it for me) and go to school 
(Physics degree), so progress on qm is rather slow at the moment.

--
Samuel A. Falvo II

[1] In fact, many managers positively refuse to use anything other than 
CVS, since it has per-file operation, rather than per-tree.  This means 
that even SVN is at a huge disadvantage compared to CVS.  I find this 
bizarre, since CVS lacks the facility to revert a file to a version 
prior in its history, while SVN has it easily available.  I had a 
conversation recently with a friend of mine, and after trying tla, he 
said, "It's very cool, but it lacks SVN's ability to easily revert a 
[single] file to an older revision."  That was his one, deciding factor 
in favor of using SVN for his projects instead of tla.  Personally, I 
admit that this feature would be nice to have, but is not a high 
priority item for my immediate needs.