Re: development model

> Just a sidenote because you didn't mention it: You realize that this is a "heavy"
> process? Ie. one which will tie a lot of development resources?

	That is the full process it does not need to be the actual process for all
changes.  Namely steps can be skipped and will be for most things.

> In the past, I've found that processes which create less overhead work better
> in OSS projects because people want to develop (ie. fix problems) instead of
> doing management work (filling out forms, applying to be allowed to do some
> work, etc).

	99% of the process is automated so very little work is needed by the
developer all the work falls on the project admin (namely me).

> You might want to look at the SCons development process for an example of
> a light-weight but still powerful process. Basically, they just ask that
> every change is accomanied with a test.

	SCons was developed using aegis (http://aegis.sourceforge.net/cgi-bin/aegis.cgi)
and you see scons people on the aegis mailing list all the time.

> There is no need to create change requests because any change must pass
> all (and the new) test and usually, you don't need to review code manually
> because the tests make sure that the quality of the code always improves
> and, honestly, if you are a little bit careful who can change your codebase,
> then you will never have to worry that some punk tried to corrupt the
> project (and even if one invested the time to screw things up deliberately,
> there is still Aegis.

	Change requests are techinically not needed but once we are in
production I suspect most changes will be done due to a user request not
an internal need.  It is not about some punk screwing stuff up it is about
making stuff internally consistent.

> Or to put it bluntly: If you feel that you need to check on your developers,
> then you don't trust them, then you *fear* them. And fear is something which
> cannot drive a project to success.

	I do not even trust my self to do stuff correctly every time.  The reason
for a review is to catch potential bugs before they get deeply embedded.  Remember
the model aegis uses is a strong guerntee that the baseline *ALWAYS* "works" no matter
what.  This is a very powerful concept in that for the most part users can trust that
anything that makes it through the whole process is 1) needed, 2) well thought out for
both the long and short term, and 3) they can trust it to work the first time and every time,
think mission critical here.

> I'd also opt to use SCons instead of Cook (I find the syntax of Cook confusing)
> but I don't know if you did an evaluation and how much advanced options you will
> need to build Pragmatic.

	Cook allows you to output a script to do the build even if you do not
have cook installed (there are some limits here in that any super-dynamic parts
of the cookbook are hard coded in the script like figuring out which libs to build
for which platform).  Also I really do not like the idea of requiring the developer/maintainer
of the build system to learn a new language just to modify the system.  As to syntax
it is not all that confusing see the tutorial.

> PS: Can we change Pragmatic to P? I find that the word "Pragmatic" is very hard
> to type because it uses keys which are spread all over the keyboard.

	I usually refer to it as prag in my head p just sounds a little obscene.

	--Aryeh

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/