The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Report: my contribution to the Deity project

Hi,

	I am not sure whether this is the right mailing list for this,
 but AFAIK debian-devel has not been made aware of the recent furor
 over Deity.

	As I mentioned here a week ago, I have been inducted into the
 Deity project. I think that the project at large needs to be better
 informed about the progress of Deity, but I can only speak for
 myself. I intend to make regular progress reports to this forum, or,
 if people think it inappropriate, some other forum which people think
 is better.

	I have, in my first week, reviewed my basic graph theoty, and
 am comfortable with the idea of writing a topological sort for
 package ordering in Deity.

	I have also successfully checked out a read-write version of
 the sources from the CVS server, and have looked at the
 documentation. 

	I have started working on an overview/design document, which
 contains the requirements, a procedural description of the various
 facets of deity, a modular description, and a detailing of the data
 flow routes in the Deity project.

	I am doing this for multiple reasons: I strongly believe any
 project writing non-toy programs derives benefit from a design
 document (DFSG and our policy and packaging manuals do it for
 Debian). I disagree with Frederick Brooks on a number of points, (I
 think his book, in the original edition, is out of date), but I do
 concede that conceptual integrity is important. Or at least that the
 lack of it  has often been disastrous. It helps keep track of details
 which may belost when one is close to the code, and the time spent on
 design docs is often repaid many times over. 

	Also, writing a design doc seems the fastest way to get me
 integrated into the project. 

	manoj	 
 ps. I have meny more (IMHO) compelling reasons to why one should have
 design documents, but I do not think that's relevant here. 
-- 
 "Flextime: Starting a 10+ hour day up to an hour early (on a regular,
 scheduled basis with the approval of an immediate supervisor)." A
 Ferranti International Controls "volunteer"
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .