Re: [Gnu-arch-users] the way forward

[Thomas Lord]

Ah.... three fact-based issues, at last.  Thank you Pierce.


> 1. The lead developer didn't have time to keep it going due to  
> personal issues.

No, that's not right.   The bandwidth demands of incoming patches
spiked but the quality of those incoming patches remained flat at
a disappointingly low level.

I rather loudly sketched out a technical infrastructure and political
structure that could absorb that bandwidth while preserving a continuity
of design thinking.   I proposed a good method for letting the most 
skilled members of the community cooperate to handle this incoming 
stream.

Canonical implemented about "70%" of that infrastructure in-house,
discarding all notion of distributed review and entirely excluding
me from its implementation and operation.

Subsequently, Canonical aggressively courted the volunteer community
and left me facing a very high bandwidth of changes from them, many
of very poor quality.   They, most often represented by Robert,
regularly went in directions that I specifically recommended against,
often because I perceived that there were long-term difficulties with
those directions.   That they have now abandoned this code base confirms
that they were motivated exclusively by short-term concerns.


> 2. The lead developer wouldn't relinquish control of integration,  
> and ended up insulting the person doing the integration work. Said  
> person quit.

I did relinquish control of integration briefly and the results were
of an unacceptably low quality.

> 3. The lead developer decided to rewrite the project from  
> scratch, so the main line stagnated.

I rewrote the storage management component and, in the process,
simplified and cleaned up the code base, improved performance,
removed the need for revision libraries, improved integrity checking
infrastructure, and liberalized the namespace.   I improved 
"librification", eliminated the weird filenames that are such
a controversy, freed users from *having* to worry about "tagging"
(though those wanting the best merging ability later would want to
continue that).   I did all of this in ways that preserved the
excellently simple mirroring capabilities of arch (and that may be
usefully compared to git).

How you arrive at the conclusion that those are reasons to complain
I've yet to see.

Meanwhile, baz encouraged bloat both internally and in dependent systems
and user habits which would make migration to the better storage
component much harder.

-t