OFBiz › OFBiz - Dev

specialpurpose in R13.07 demo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Jacques Le Roux

specialpurpose in R13.07 demo

Administrator

Jacopo Cappellato-4

Re: specialpurpose in R13.07 demo

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 <[hidden email]> wrote:

Jacopo Cappellato-4

Re: specialpurpose in R13.07 demo

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.

Jacopo

On Sep 30, 2014, at 8:38 AM, Jacopo Cappellato <[hidden email]> wrote:

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

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 Cappellato-4

Re: specialpurpose in R13.07 demo

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux <[hidden email]> 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

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
> On Oct 23, 2014, at 2:07 PM, Jacques Le Roux <[hidden email]> 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
>

Ron Wheeler

Re: specialpurpose in R13.07 demo

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
>> <[hidden email]> 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
includes"nightly 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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

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 <[hidden email]> 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
> includes"nightly 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
>>>
>>
>
>

Ron Wheeler

Re: specialpurpose in R13.07 demo

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
>>>> <[hidden email]> 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 includes"nightly 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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Pierre Smits

Re: specialpurpose in R13.07 demo

In reply to this post by Jacques Le Roux

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 <[hidden email]> 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 <[hidden email]> 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 includes"nightly 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
>>
>>

Pierre Smits

Re: specialpurpose in R13.07 demo

In reply to this post by Ron Wheeler

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 <[hidden email]> 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 <[hidden email]> 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 includes"nightly 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: [hidden email]
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

In reply to this post by Ron Wheeler

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 <[hidden email]> 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
>>> includes"nightly 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.

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

>
>>
>> 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

Re: specialpurpose in R13.07 demo

In reply to this post by Pierre Smits

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 <[hidden email]> 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 <[hidden email]> 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 includes"nightly 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
>>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Ron Wheeler

Re: specialpurpose in R13.07 demo

In reply to this post by Pierre Smits

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 <[hidden email]> 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 <[hidden email]> 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 includes"nightly 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: [hidden email]
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Ron Wheeler

Re: specialpurpose in R13.07 demo

In reply to this post by Jacques Le Roux

On 23/10/2014 1:00 PM, Jacques Le Roux wrote:

> 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
>>>>>> <[hidden email]> 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 includes"nightly 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.
>
> 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.

Sorry that I was not clear when I talked about "team" having customers.
I was referring to those on the PMC that make their living selling
forked versions of OFBiz to others.
It may not be true for all committers.

Ron

>
> Jacques
>
>>
>>>
>>> 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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

In reply to this post by Ron Wheeler

Le 23/10/2014 19:52, Ron Wheeler a écrit :
> 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.

Actually I believe more and more OFBiz service providers rely on one of the release branches, less and less the trunk HEAD.

But yes, there are also maybe few OFBiz service providers who start with a static packaged releases for a client custom project.
Thought it's far easier to svn update a release branch where bug fixes are "routinely" backported by committers than to muck around with patches to
apply on a static packaged releases or anything else static (static meaning here with no connection with the OFBiz svn repo).

This is actually even true for anybody working from OFBiz.

Jacques

>
> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> includes"nightly 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: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>
>

Ron Wheeler

Re: specialpurpose in R13.07 demo

On 23/10/2014 3:32 PM, Jacques Le Roux wrote:

> Le 23/10/2014 19:52, Ron Wheeler a écrit :
>> 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.
>
> Actually I believe more and more OFBiz service providers rely on one
> of the release branches, less and less the trunk HEAD.

One would think that this would generate a lot of support for backporting.

>
> But yes, there are also maybe few OFBiz service providers who start
> with a static packaged releases for a client custom project.
> Thought it's far easier to svn update a release branch where bug fixes
> are "routinely" backported by committers than to muck around with
> patches to apply on a static packaged releases or anything else static
> (static meaning here with no connection with the OFBiz svn repo).
>
> This is actually even true for anybody working from OFBiz.
>
> Jacques
>
>>
>> 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
>>>> <[hidden email]> 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
>>>>>>>> <[hidden email]> 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 includes"nightly 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: [hidden email]
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Ron Wheeler

Re: specialpurpose in R13.07 demo

In reply to this post by Jacques Le Roux

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

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.

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 includes"nightly 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
>>>>
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Jacques Le Roux

Re: specialpurpose in R13.07 demo

Administrator

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

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
>>> includes"nightly 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
>>>>>
>>>>
>>>
>>>
>>
>
>

Jacopo Cappellato-4

Re: specialpurpose in R13.07 demo

On Oct 24, 2014, at 9:58 AM, Jacques Le Roux <[hidden email]> 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