At my compnay my development process is a little unique, we have about 6
programmers, but I churn out legendary amounts of code. Working to
communicate actively on applications I'm currently developing would just
slow the total time from thought to finish down, so I design the app, code
it, nail all of the bugs that I can see, then pass it on for bug testing,
maintence and feature creep.

Such a development process may be helpful to mandrake. If the
responsibilities of coding/designing are seperated from testing and
maintence things seem to flow pretty smooth. In other words cooker
continues to develop as cooker at all times, then when mandrake feels that
they've got alot of cool stuff in cooker that needs to be released upon the
world they take a snapshot of cooker then debug that tree. While the
snapshotted cooker is being debugged and polished for release (a 1-2 month
process) Pixel and his clan are free to move development forward without
having to worry about a bunch of whiney people on a list. (Myself included
of course)

-David Talbot

At 06:47 PM 6/2/00 +1000, you wrote:
>Civileme wrote:
>> 
>> And I am not one who believes that the very process by which we develop
>> software is a sacred cow.  Some people can give you a flow chart of the
>> process.  Others will ask, "What's a flow chart?"  And some good software
>> comes out of both.  The process Mandrake uses has a number of elements
>> different from the classic "right" way to do things, and some people are
>> critical for that reason.  I am content to provide feedback on the results
>> and let them discover what works best for their development model.  It
>> appears that you are doing the same in your own way, but you want to work
>> more with the system rather than upon it.
>
>Part of an excellent post, Civileme.
>
>I am in agreement with you.   The problem I see is that Mandrakesoft
>uses a unique development process, which may well turn out to have
>higher merit than the classic one, but names the user-involvement
>testing phase of that process using the traditional and well-defined
>name "beta test" when their process patently does not conform even
>remotely to that definition.
>
>That is easily fixed by calling it something else, and publishing
>their expectations and rules for that part of their process.  
>Silence --> classic.
>
>-- 
>
>Regards,
>
>Ron. [AU] - sent by Mandrake Linux.


Reply via email to