envolution-devel

Antw: [Envolution-devel] postWrap

[Stefan K. <Ste...@ga...>]

@luca:
[...] We are going to use postwrap, and guess what, we'll need to convert =
it to Oracle.
How do we usually proceed with modules not developed by the envo community?=
 [...]

This is a fundamental problem. Because if we want to distribute 3rd-party-m=
odules including some changes for eNvo, it is not easy to hold them =
up-to-date, if there are some updates and fixes published by module-owner. =
We have to implement them manually into the modified files. Or we use =
these modules as is (based on xxx, version 123) and develop it in future =
under eNvo without the support of the owner.

[...] Do we try to get the approval of the author? can we ask him to =
accept and include the modifiers on the source so that it colud be =
preserved for future releases and bug fix? [...]

This would be the better way. But it is neccessary to share all work. This =
is a two-way development:
Owner -> eNvo, eNvo -> owner
Possible that not all changes would be shared.

[...] Can we try to pull these developers in the envo community? [...]

And this would be the best way. But not every developer want to work only =
for one community. They have some different interests, ideas, etc. to =
distribute their work.
But if he want to develop his modules also for eNvo, it would be possible, =
that he can update his changes on our CVS. So we can share all automaticall=
y.

Try it.... ;)

WindMeUp

Re: Antw: [Envolution-devel] postWrap

[TiMax - E. <web...@en...>]

yes 
is not easy to manage that ....  and i agree with Stefan

But why postwrap ?  try to test also StaticsDocs  is not same=
 thing but sometimes is better 

TiMax

On Wed, 04 Jun 2003 16:07:01 +0200, Stefan Koehler wrote:
>  @luca:
>  [...] We are going to use postwrap, and guess what, we'll need=
 to convert it to Oracle.
>  How do we usually proceed with modules not developed by the=
 envo community? [...]
>
>  This is a fundamental problem. Because if we want to=
 distribute 3rd-party-modules including some 
changes for eNvo, it is not easy to hold them up-to-date, if=
 there are some updates and fixes published by 
module-owner. We have to implement them manually into the=
 modified files. Or we use these modules as is 
(based on xxx, version 123) and develop it in future under eNvo=
 without the support of the owner.
>
>  [...] Do we try to get the approval of the author? can we ask=
 him to accept and include the modifiers on the 
source so that it colud be preserved for future releases and bug=
 fix? [...]
>
>  This would be the better way. But it is neccessary to share=
 all work. This is a two-way development:
>  Owner -> eNvo, eNvo -> owner
>  Possible that not all changes would be shared.
>
>  [...] Can we try to pull these developers in the envo=
 community? [...]
>
>  And this would be the best way. But not every developer want=
 to work only for one community. They have 
some different interests, ideas, etc. to distribute their work.
>  But if he want to develop his modules also for eNvo, it would=
 be possible, that he can update his changes 
on our CVS. So we can share all automatically.
>
>  Try it.... ;)
>
>  WindMeUp
>
>
>  -------------------------------------------------------
>  This SF.net email is sponsored by:  Etnus, makers of=
 TotalView, The best
>  thread debugger on the planet. Designed with thread debugging=
 features
>  you've never dreamed of, try TotalView 6 free at=
 www.etnus.com.
>  _______________________________________________
>  Envolution-devel mailing list
>  Env...@li...
>  https://lists.sourceforge.net/lists/listinfo/envolution-devel