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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
