OpenEuphoria

Re: Standard Euphoria Library project

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 07, 2005
• 567 views

Christian Cuvier wrote:

> From: "Juergen Luethje"
>
>> Christian Cuvier wrote: <snip>
>>
>>>> The Standard Euphoria Library project on Sourceforge is dead.
>>>> The OpenEuphoria group, which is the one you're referring to, is dead as
>>>> well.
>>>> Its homepage is at oedoc.free.fr actually.
>>>>
>>>
>>>>>> Now I wouldn't want to organize such a thing because I am not an
>>>>>> experienced
>>>>>> developer.  But I would want to contribute ideas, documentation, or
>>>>>> code..
>>>
>>>>
>>>> I was originally the doc manager for OpnEU. I wound up docig sequences
>>>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
>>>> project. Wanna get in?
>>
>>
>> I'd like to join the Standard Euphoria Library project.  
>>
>
> I just checked out on sf: that project doesn't even show up in the
> search results for "Euphoria". It appears to have produced no file at
> all last time I had checked (possibly 1 year ago). I'd pronounce it dead
> and buried.
>
> Otherwise, sourceforge.net/projects/peu hosts the same specs as you'd
> find on my website.

I visited your site <http://oedoc.free.fr/>, looked at the "Original
mission statement for OpenEuphoria" which is linked there, and
downloaded "OEdoc_v1_4.zip". I'm impressd, you guys did a considerable
amount of work!

But I think most of this can't be used for the Standard Euphoria Library
project, because it's a different beast. We need a new "Mission
statement", maybe that's the first thing we should create.

Then maybe we should write down some internal standards, i.e. an
internal naming convention, and a standdard for the way we create the
modules of our library. We could use the text that Derek posted here
recently as guideline.

Just some more thoughts:
- Build one module after the other.
- When one module is finished, release a new version.
- For a new module, first someone writes the specs.
- The specs are discussed in the project group.
- Then one (ore more) person(s) write(s) the code for the module.
- Then at least 2 persons -- and only persons who didn't write the
  code -- check whether the code meets the specification independently
  of each other. One of these "peer reviewers" should be an IT
  professional.
  ( Well, how much of them participate in the project?  )
- The documentation should be written (or at least be "polished") by
  native English speakers.

Regards,
   Juergen