subject:"specialpurpose in R13.07 demo"

Re: specialpurpose in R13.07 demo

2014-10-28 Thread Jacques Le Roux

Le 24/10/2014 16:14, Ron Wheeler a écrit :

On 24/10/2014 3:58 AM, Jacques Le Roux wrote:

Le 24/10/2014 00:02, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a
component in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

Your idea of disabling some specialpurpose component can't be applied in R13.07
demo until we decide which component should be disabled in trunk.
In the meantime we should keep the current state (ie all specialpurpose
components present in trunk should be available in R13.07 demo)

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

If they are not in the 13.07.01 release it creates a bit of a mismatch between
the demo and what you actually get.
Otherwise I would have no problem.

It's also Jacopo's opinion, I don't know if it's for the same reason.
My proposed alternative is to keep only the ones which will be enabled in the trunk and explain somewhere (on the site main page?) why we do that
and how to do the same using svn external or direct check out from trunk.
The idea is it's a bit didactic on how to use the specialpurpose components in future releases. Except if we change our POV and keep the enabled
ones in releases in future, which could be even simpler...

Is there an architectural overview describing the relationship between the core
functionality and the supported components?

The best we have is this
https://cwiki.apache.org/confluence/display/OFBTECH/Component+and+Component+Set+Dependencies

Is there a difference between available and enabled that would be clear to
a new user?

Available in releases would be the components enabled in trunk.

I don't understand the technical details but I gather that there is a potential
for conflict between the components.
Has there been any guidelines about how to describe the conflict issue to a system administrator so that modules are installed in the right
sequence to end up with a working system?

See above, this might need update

Has there been any discussion about how developers should construct components so that their potential for interference is reduced and is done in a
consistent way.

There are many in MLs history. By and large, there can be dependencies between components of the same levels. You can't build an ERP, where things are
integrated, else.
Then, the bottom level being framework, then applications, then specialpurpose and finally hot-deploy, there should not be dependencies from a lower
level component to a higher level one.

Are there hooks that allow administrators to configure sets of components to work the way that they should or to allow developers of components to
write components that interact with the core functionality in a safe way?

One of the most important and interesting thing in OFBiz is the possibility for a functional component (ie the framework level does not count here) to
override things done at a lower level. This is how hot-deploy works. You can override things from applications level in hot-deploy. I say things
because it concerns most artefacts.

For example, a way to allow a system administrator to chose between 2 data entry screens depending on what data needs to be collected( if you enable
component B, then you need to use order-entry screen B rather than the core screen and if you do, the core order processing will still work where
it does not require or track the extra data that screen B collects .

This is certainly doable but would need some code glue, ie it's not available
OOTB.
Also I'm not sure that the component concept is well adapated here, since you speak about screen. The component is not an artefact in the sense of
OFBiz, rather a container.

https://demo-trunk-ofbiz.apache.org/webtools/control/ViewComponents
https://demo-trunk-ofbiz.apache.org/webtools/control/ArtifactInfo (be patient
this takes much resources)

Jacques

Ron

I guess at some point the disabled specialpurpose components in trunk will end
in Attic.

Jacques

Ron

It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries
whatever warranty that the project offers in terms

Re: specialpurpose in R13.07 demo

2014-10-24 Thread Jacques Le Roux

Le 24/10/2014 00:02, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a
component in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

If they are not in the 13.07.01 release it creates a bit of a mismatch between
the demo and what you actually get.
Otherwise I would have no problem.

It's also Jacopo's opinion, I don't know if it's for the same reason.
My proposed alternative is to keep only the ones which will be enabled in the trunk and explain somewhere (on the site main page?) why we do that and
how to do the same using svn external or direct check out from trunk.
The idea is it's a bit didactic on how to use the specialpurpose components in future releases. Except if we change our POV and keep the enabled ones
in releases in future, which could be even simpler...

I guess at some point the disabled specialpurpose components in trunk will end
in Attic.

Jacques

Ron

It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries
whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that
includesnightly build and unstable in the name and comes with no warranty and a warning about using it at your own risk.

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it
was better to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
demo data.

If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they
require and can support to be sure that the trunk still works but this should not be the public demo or even be called a demo.

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

Jacques

Does anyone have an opinion about the gap between 13.07.01 and what the main SI
companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it would be
possible to use the official Release as the actual release?

I hope it's more clear

Jacques

Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-24 Thread Jacopo Cappellato

On Oct 24, 2014, at 9:58 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 I guess at some point the disabled specialpurpose components in trunk will 
 end in Attic.

Not necessarily: a disabled component could be a specialized version (e.g. for 
a specific industry or for a specific payment processor) of some of the 
application components and could be actively maintained; in this case it would 
make sense to disable it by default (because by default OFBiz should be as 
generic as possible) but still keep it in the trunk (and possibly in some 
releases, e.g. ofbiz-specialpurpose-13.07.03.zip).

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-24 Thread Ron Wheeler


On 24/10/2014 3:58 AM, Jacques Le Roux wrote:


Le 24/10/2014 00:02, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:


Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
jacques.le.r...@les7arts.com wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand 
the meaning of it.


Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.


Actually the specialpurpose components are in the R13.07 demos 
because they can be there. But they are not maintained in the R13.07 
branch (but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between releases 
and the trunk and demos in OFBiz.


Would you prefer to not have the specialpurpose components in R13.07 
demo?


If they are not in the 13.07.01 release it creates a bit of a 
mismatch between the demo and what you actually get.

Otherwise I would have no problem.


It's also Jacopo's opinion, I don't know  if it's for the same reason.
My proposed alternative is to keep only the ones which will be enabled 
in the trunk and explain somewhere (on the site main page?) why we do 
that and how to do the same using svn external or direct check out 
from trunk.
The idea is it's a bit didactic on how to use the specialpurpose 
components in future releases. Except if we change our POV and keep 
the enabled ones in releases in future, which could be even simpler...




Is there an architectural overview describing the relationship between 
the core functionality and the supported components?
Is there a difference between available and enabled that would be 
clear to a new user?


I don't understand the technical details but I gather that there is a 
potential for conflict between the components.
Has there been any guidelines about how to describe the conflict issue 
to a system administrator so that modules are installed in the right 
sequence to end up with a working system?
Has there been any discussion about how developers should construct 
components so that their potential for interference is reduced and is 
done in a consistent way.
Are there hooks that allow administrators to configure sets of 
components to work the way that they should or to allow developers of 
components to write components that interact with the core functionality 
in a safe way? For example, a way to allow a system administrator to 
chose between 2 data entry screens depending on what data needs to be 
collected( if you enable component B, then you need to use order-entry 
screen B rather than the core screen and if you do, the core order 
processing will still work where it does not require or track the extra 
data that screen B collects .



Ron

I guess at some point the disabled specialpurpose components in trunk 
will end in Attic.


Jacques



Ron



It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download 
and carries whatever warranty that the project offers in terms of 
testing and rapidity of bug fixes and the trunk is usually called 
something that includesnightly build and unstable in the name 
and comes with no warranty and a warning about using it at your own 
risk.


Demos should be of the latest release and should be stable and have 
a fixed functionality that can be documented in the wiki and 
marketing pages.


They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, 
because I thought it was better to have the specialpurpose 
components available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up 
since it should not require any technical skills to keep working 
and fed with demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as 
they require and can support  to be sure that the trunk still works 
but this should not be the public demo or even be called a demo.


It's also, there are no official mention of the trunk demo, it's 
only a developers thing.




Of course, this only works if a release is actually a Release and 
the team stands behind it and uses it when establishing new customers.


We have no customers, only users

Jacques



Does anyone have an opinion about the gap between 13.07.01 and what 
the main SI companies

Re: specialpurpose in R13.07 demo

2014-10-24 Thread Ron Wheeler


On 24/10/2014 6:52 AM, Jacopo Cappellato wrote:

On Oct 24, 2014, at 9:58 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


I guess at some point the disabled specialpurpose components in trunk will end 
in Attic.

Not necessarily: a disabled component could be a specialized version (e.g. for 
a specific industry or for a specific payment processor) of some of the 
application components and could be actively maintained; in this case it would 
make sense to disable it by default (because by default OFBiz should be as 
generic as possible) but still keep it in the trunk (and possibly in some 
releases, e.g. ofbiz-specialpurpose-13.07.03.zip).

Jacopo



This is another area where sub-projects would help.
The software would be maintained in its own repo and would be supported 
by an identifiable team that actually cared about it and would be 
responsible for building the community to support that function.
There would be someone (or some people) able to say if it was going to 
be ported to the latest release and bugs backported to previous releases.
If that sub-project died, it would be clear and everyone would know that 
it was not going to be available as part of future OFBiz releases unless 
some group took charge of the sub-project and did the work.


This structure would help everyone and increase the transparency around 
the management of components.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacques Le Roux


Le 30/09/2014 08:47, Jacopo Cappellato a écrit :

Also, since (by design) the specialpurpose components there could be 
incompatible components (i.e. specialpurpose/a causes side effects in 
specialpurpose/b), or alternative components (i.e. specialpurpose/a is a 
different implementation of the same features of specialpurpose/b) or 
components that override some of the screens published by the applications 
(i.e. specialpurpose/a replaces applications/a screen with a custom version), 
we should, by default, disable (most of) them and provide a README file with 
the information on how to enable them selectively.


I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component in 
demos, moreover demos are shared.

So before this effort is accomplished it's better to run the R13.07 demo 
completed with the specialpurpose components also present in trunk demo.
Then we would put as external in R13.07 (and sequel releases) only the not (by 
default) disabled components in trunk, a bit convoluted though :/

A moment I even thought about Attic for some unmaintained components 
(ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO cares?

BTW I just noticed that we missed to adapt the ecommerce component in R13.07 
for the missing ebaystore and googlecheckout components.
I guess it's only about checking in trunk HEAD code for these components presence and hidding their buttons when they would otherwise show. This 
should be backported in R13.07 of course.


Jacques



Jacopo

On Sep 30, 2014, at 8:38 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


in my opinion it is better to run the demo on the exact copy of the release 
branch.

Jacopo

On May 30, 2014, at 2:28 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


Hi,

For the R13.07 demo I think we should set an external property from trunk into 
specialpurpose for some (those which make sense) components.

I created this svn external property:

specialpurpose/assetmaint/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/assetmaint
specialpurpose/birt/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
specialpurpose/cmssite/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/cmssite
specialpurpose/ebay/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/ebay
specialpurpose/ebaystore/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/ebaystore
specialpurpose/example/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/example
specialpurpose/exampleext/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/exampleext
specialpurpose/googlecheckout/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/googlecheckout
specialpurpose/lucene/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/lucene
specialpurpose/myportal/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/myportal
specialpurpose/projectmgr/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr
specialpurpose/scrum/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/scrum
specialpurpose/webpos/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/webpos

What do you think?

Jacques

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacopo Cappellato


On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 I agree about the idea, but this applies only to releases or checked out 
 code. Because there are no ways for users to enable/disable a component in 
 demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of 
it.

Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacques Le Roux



Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


I agree about the idea, but this applies only to releases or checked out code. 
Because there are no ways for users to enable/disable a component in demos, 
moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of 
it.


Your idea of disabling some specialpurpose component can't be applied in R13.07 
demo until we decide which component should be disabled in trunk.
In the meantime we should keep the current state (ie all specialpurpose 
components present in trunk should be available in R13.07 demo)

I hope it's more clear

Jacques



Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Ron Wheeler


On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
jacques.le.r...@les7arts.com wrote:


I agree about the idea, but this applies only to releases or checked 
out code. Because there are no ways for users to enable/disable a 
component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand the 
meaning of it.


Your idea of disabling some specialpurpose component can't be applied 
in R13.07 demo until we decide which component should be disabled in 
trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.
As you can guess, I am troubled about the relation between releases and 
the trunk and demos in OFBiz.
It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download and 
carries whatever warranty that the project offers in terms of testing 
and rapidity of bug fixes and the trunk is usually called something that 
includesnightly build and unstable in the name and comes with no 
warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a 
fixed functionality that can be documented in the wiki and marketing pages.
It could be maintained by the documentation team once it is set up since 
it should not require any technical skills to keep working and fed with 
demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as they 
require and can support  to be sure that the trunk still works but this 
should not be the public demo or even be called a demo.


Of course, this only works if a release is actually a Release and the 
team stands behind it and uses it when establishing new customers.


Does anyone have an opinion about the gap between 13.07.01 and what the 
main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacques Le Roux

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component
in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it was
better to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
demo data.

If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they require
and can support to be sure that the trunk still works but this should not be the public demo or even be called a demo.

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Ron Wheeler


On 23/10/2014 11:33 AM, Jacques Le Roux wrote:


Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
jacques.le.r...@les7arts.com wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand the 
meaning of it.


Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.


Actually the specialpurpose components are in the R13.07 demos because 
they can be there. But they are not maintained in the R13.07 branch 
(but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between releases 
and the trunk and demos in OFBiz.


Would you prefer to not have the specialpurpose components in R13.07 
demo?


It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download 
and carries whatever warranty that the project offers in terms of 
testing and rapidity of bug fixes and the trunk is usually called 
something that includesnightly build and unstable in the name and 
comes with no warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a 
fixed functionality that can be documented in the wiki and marketing 
pages.


They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, because 
I thought it was better to have the specialpurpose components 
available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up 
since it should not require any technical skills to keep working and 
fed with demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as 
they require and can support  to be sure that the trunk still works 
but this should not be the public demo or even be called a demo.


It's also, there are no official mention of the trunk demo, it's only 
a developers thing.




Of course, this only works if a release is actually a Release and the 
team stands behind it and uses it when establishing new customers.


We have no customers, only users


The PMC members have the customers to whom I was referring.



Jacques



Does anyone have an opinion about the gap between 13.07.01 and what 
the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo











--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Pierre @GMail

Is it a good thing to not regard the ofbiz user as a customer?

Regards, 

Pierre

Sent from my iPhone

 On 23 okt. 2014, at 17:33, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 
 Le 23/10/2014 17:11, Ron Wheeler a écrit :
 On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
 
 Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
 On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 I agree about the idea, but this applies only to releases or checked out 
 code. Because there are no ways for users to enable/disable a component 
 in demos, moreover demos are shared.
 Could you please explain the above sentence? I don't understand the 
 meaning of it.
 
 Your idea of disabling some specialpurpose component can't be applied in 
 R13.07 demo until we decide which component should be disabled in trunk.
 In the meantime we should keep the current state (ie all specialpurpose 
 components present in trunk should be available in R13.07 demo)
 
 If they are in the demo they should be in the release.
 
 Actually the specialpurpose components are in the R13.07 demos because they 
 can be there. But they are not maintained in the R13.07 branch (but 
 ecommerce) only in trunk.
 
 As you can guess, I am troubled about the relation between releases and the 
 trunk and demos in OFBiz.
 
 Would you prefer to not have the specialpurpose components in R13.07 demo?
 
 It is a bit odd and certainly goes against most product release strategies 
 wherein the current release is the recommended download and carries whatever 
 warranty that the project offers in terms of testing and rapidity of bug 
 fixes and the trunk is usually called something that includesnightly build 
 and unstable in the name and comes with no warranty and a warning about 
 using it at your own risk.
 
 Demos should be of the latest release and should be stable and have a fixed 
 functionality that can be documented in the wiki and marketing pages.
 
 They are, just that they use the branch instead of the packaged releases.  
 For R13.07 (current stable) there is an exception, because I thought it was 
 better to have the specialpurpose components available. This is what Jacopo 
 contests
 
 It could be maintained by the documentation team once it is set up since it 
 should not require any technical skills to keep working and fed with demo 
 data.
 
 
 If the developers need a test site based on the nightly build, they should 
 be free to set up as many combinations of configurations as they require and 
 can support  to be sure that the trunk still works but this should not be 
 the public demo or even be called a demo.
 
 It's also, there are no official mention of the trunk demo, it's only a 
 developers thing.
 
 
 Of course, this only works if a release is actually a Release and the team 
 stands behind it and uses it when establishing new customers.
 
 We have no customers, only users
 
 Jacques
 
 
 Does anyone have an opinion about the gap between 13.07.01 and what the main 
 SI companies are getting from using the trunk instead.
 Would a monthly release pattern reduce this gap to a point where it would be 
 possible to use the official Release as the actual release?
 
 
 I hope it's more clear
 
 Jacques
 
 
 Thanks,
 
 Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Pierre @GMail

The others participating in this project ( with and without customers are of no 
importance?

Regards,

Pierre

Sent from my iPhone

 On 23 okt. 2014, at 18:04, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 On 23/10/2014 11:33 AM, Jacques Le Roux wrote:
 
 Le 23/10/2014 17:11, Ron Wheeler a écrit :
 On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
 
 Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
 On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 I agree about the idea, but this applies only to releases or checked out 
 code. Because there are no ways for users to enable/disable a component 
 in demos, moreover demos are shared.
 Could you please explain the above sentence? I don't understand the 
 meaning of it.
 
 Your idea of disabling some specialpurpose component can't be applied in 
 R13.07 demo until we decide which component should be disabled in trunk.
 In the meantime we should keep the current state (ie all specialpurpose 
 components present in trunk should be available in R13.07 demo)
 
 If they are in the demo they should be in the release.
 
 Actually the specialpurpose components are in the R13.07 demos because they 
 can be there. But they are not maintained in the R13.07 branch (but 
 ecommerce) only in trunk.
 
 As you can guess, I am troubled about the relation between releases and the 
 trunk and demos in OFBiz.
 
 Would you prefer to not have the specialpurpose components in R13.07 demo?
 
 It is a bit odd and certainly goes against most product release strategies 
 wherein the current release is the recommended download and carries 
 whatever warranty that the project offers in terms of testing and rapidity 
 of bug fixes and the trunk is usually called something that 
 includesnightly build and unstable in the name and comes with no 
 warranty and a warning about using it at your own risk.
 
 Demos should be of the latest release and should be stable and have a fixed 
 functionality that can be documented in the wiki and marketing pages.
 
 They are, just that they use the branch instead of the packaged releases.  
 For R13.07 (current stable) there is an exception, because I thought it was 
 better to have the specialpurpose components available. This is what Jacopo 
 contests
 
 It could be maintained by the documentation team once it is set up since it 
 should not require any technical skills to keep working and fed with demo 
 data.
 
 
 If the developers need a test site based on the nightly build, they should 
 be free to set up as many combinations of configurations as they require 
 and can support  to be sure that the trunk still works but this should not 
 be the public demo or even be called a demo.
 
 It's also, there are no official mention of the trunk demo, it's only a 
 developers thing.
 
 
 Of course, this only works if a release is actually a Release and the team 
 stands behind it and uses it when establishing new customers.
 
 We have no customers, only users
 
 The PMC members have the customers to whom I was referring.
 
 
 Jacques
 
 
 Does anyone have an opinion about the gap between 13.07.01 and what the 
 main SI companies are getting from using the trunk instead.
 Would a monthly release pattern reduce this gap to a point where it would 
 be possible to use the official Release as the actual release?
 
 
 I hope it's more clear
 
 Jacques
 
 
 Thanks,
 
 Jacopo
 
 
 -- 
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacques Le Roux

Le 23/10/2014 18:04, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a
component in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
demo data.

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

The PMC members have the customers to whom I was referring.

Please don't mix things. With We above I spoke on behalf of the OFBiz dev
team (ie the committers).
To state it clearly the Apache OFBiz project has no customers but only users
You owe something to a customer, it's your client.
The Apache OFBiz project does not owe anything to its users. You can speak around that, but it's a fact, only volunteers work is donated to this
project. Nobody is paid directly by the ASF or the OFBiz project.

I thought this was quite obvious for everyone (including Pierre which is
questioning in 2 other emails)

Now as you said indeed PMC members have customers. But that's another totally
unrelated thing to me.

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Ron Wheeler

I was referring to real customers that are paying OFBiz contributors
like you, real money to get them set up using OFBiz.

On 23/10/2014 12:30 PM, Pierre @GMail wrote:

Is it a good thing to not regard the ofbiz user as a customer?

Regards,

Pierre

Sent from my iPhone

On 23 okt. 2014, at 17:33, Jacques Le Roux jacques.le.r...@les7arts.com wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

I agree about the idea, but this applies only to releases or checked out code.
Because there are no ways for users to enable/disable a component in demos,
moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can
be there. But they are not maintained in the R13.07 branch (but ecommerce) only
in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

It is a bit odd and certainly goes against most product release strategies wherein the current
release is the recommended download and carries whatever warranty that the project offers in terms
of testing and rapidity of bug fixes and the trunk is usually called something that
includesnightly build and unstable in the name and comes with no warranty
and a warning about using it at your own risk.

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For
R13.07 (current stable) there is an exception, because I thought it was better
to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it
should not require any technical skills to keep working and fed with demo data.

If the developers need a test site based on the nightly build, they should be free to set
up as many combinations of configurations as they require and can support to be sure
that the trunk still works but this should not be the public demo or even be called a
demo.

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Ron Wheeler

I don't think that I was implying that in the point that I was trying to
make.

It is my theory that the way that this project deals with the releases
and the trunk is directly related to the fact that most of the people
involved have customers for whom they fork the OFBiz system and deliver
a forked version to which they apply patches and improvements when they
get applied to the trunk rather than using the official release as a
base for their deliverables.

This may appear to work but I think that it hurts the project and
probably has a negative effect on the overall profitability of the OFBiz
market served by these companies.

Ron

On 23/10/2014 12:33 PM, Pierre @GMail wrote:

The others participating in this project ( with and without customers are of no
importance?

Regards,

Pierre

Sent from my iPhone

On 23 okt. 2014, at 18:04, Ron Wheeler rwhee...@artifact-software.com wrote: