Suggest branch rather than release strategy?

[Ron Wheeler]

Sounds like we are thinking the same thing at the same time.
Specificity will help.

On 14/11/2014 8:20 AM, Jacopo Cappellato wrote:

> It was a long discussion that was done in the public lists and I wouldn't
> want to rehash it (you have been part of it for sure): there were concerns
> and discussions about duplicated jars, poor quality code, stale code, files
> with questionable licenses etc... on the other side there were people
> worried about removing features from the system etc...
> I think it would be better to address each component individually and,
> since you would like to "cope with missing specialpurpose components in
> released packages", this is why I am asking you what are the components
> that should be included in the trunk/release branch/releases.
>
> Jacopo
>
> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> I think we need to be sure of what we are doing.
>>
>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>
>> Jacques
>>
>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>
>>   What is your preference? Would you like to see them all in the release
>>> packages? Some of them only? Which ones?
>>>
>>>
>>>
>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>   This is the easiest part, I was more thinking about how much is
>>>> downloaded
>>>> by users.
>>>>
>>>> Anyway this was just an idea to help user to cope with missing
>>>> specialpurpose components in released packages.
>>>>
>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>> decided to remove them. Why keeping them in the releases branches but not
>>>> not in released packages is not clear to me.
>>>>
>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>> w3xw6lipifdeks3z
>>>> Actually we need to clarify 1st which components to keep active in
>>>> release
>>>> branches. For now it seems only ecommerce which is for me too
>>>> restrictive.
>>>> And then discuss about why not doing the same in released packages (sorry
>>>> if I missed some arguments here).
>>>> For that we need first to exactly know which components affect which
>>>> ones.
>>>> I believe at this stage we don't want to send any specialpurpose
>>>> component
>>>> to Attic, but this might be discussed also.
>>>>
>>>> Jacques
>>>>
>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>
>>>>    That is not difficult to assess. Do a download from trunk, and see how
>>>>
>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download
>>>>> and
>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>
>>>>> Now multiply that with the number of branches you had in mind.
>>>>>
>>>>> Verstuurd vanaf mijn iPad
>>>>>
>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>
>>>>>> [hidden email]> het volgende geschreven:
>>>>>>
>>>>>>
>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>
>>>>>>   Is it Apache's concern that while people may be free to choose, ASF
>>>>>>> server capacity is not free nor unlimited?
>>>>>>>
>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>> but
>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>
>>>>>>>   You said it :) At the moment I don't fear any overload on the svn
>>>>>> server
>>>>>> from users downloading from releases branches instead of released
>>>>>> packages.
>>>>>> OFBiz is not Tomcat ;)
>>>>>> But I must say I have no measures, so you got a point
>>>>>> until-we/if-we-can
>>>>>> discover that. Because users can already do that, I think it's fair to
>>>>>> use
>>>>>> this method as long as it's reasonable.
>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>> the
>>>>>> truth (if can get them)
>>>>>>
>>>>>>    That may be the practical side of Apache's urging to get the releases
>>>>>>
>>>>>>> following their guidelines.
>>>>>>>
>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>> "fear"
>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>> hiding behind unknown numbers?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>    Ron
>>>>>>
>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>
>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>> servers?
>>>>>>>>>
>>>>>>>>>   I don't try to solve an issue, just to propose an alternative.
>>>>>>>> It's a
>>>>>>>> free user choice, but with more elements
>>>>>>>>
>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>
>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>
>>>>>>>>>   Things stay as they are, it's only that we inform our users than
>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>> comparison to
>>>>>>>> choice, it's called freedom
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>    Ron
>>>>>>>>
>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>> explained
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>> release
>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>> files
>>>>>>>>>>> thru
>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>> trunk.
>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>> than the
>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>> required
>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>> guarantee
>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>    Hi,
>>>>>>>>>>>
>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>> strategy
>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>> or maybe
>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>> wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>> all know
>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>> and I have
>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>> them.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

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

[Pierre Smits]

You'll be the first?

Verstuurd vanaf mijn iPad

> Op 14 nov. 2014 om 14:26 heeft Ron Wheeler <[hidden email]> het volgende geschreven:
>
> Can we start by separating the list into
> Case 1 - Required. Were released in the past so have an implied warranty,  known to be used in production situations,  were part of previous releases or have current activity
> Case 2 - Definitely don't need. Never finished. Tests that never worked.
> Case 3 - Not sure. Can not remember who started this.
>
> This would add some specificity to the discussion and would allow people to come forward with objections or offers of support.
>
> Can we start to develop a KB about what modules interfere with other modules, where this shows up and how does one fix the problem if we need to run multiple modules that normally interfere?
> This would help determine the work required to support releasing them and might lead to useful discussions about dynamic configuration tools that allow conflicting modules to co-exist.
>
> Is there a wiki page for each of the case 1 modules?
>
> Do we have volunteers to create and maintain the wiki pages at least?
>
> Ron
>
>
>
>> On 14/11/2014 7:55 AM, Jacques Le Roux wrote:
>> I think we need to be sure of what we are doing.
>>
>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>
>> Jacques
>>
>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>> What is your preference? Would you like to see them all in the release
>>> packages? Some of them only? Which ones?
>>>
>>>
>>>
>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> This is the easiest part, I was more thinking about how much is downloaded
>>>> by users.
>>>>
>>>> Anyway this was just an idea to help user to cope with missing
>>>> specialpurpose components in released packages.
>>>>
>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>> decided to remove them. Why keeping them in the releases branches but not
>>>> not in released packages is not clear to me.
>>>>
>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>> w3xw6lipifdeks3z
>>>> Actually we need to clarify 1st which components to keep active in release
>>>> branches. For now it seems only ecommerce which is for me too restrictive.
>>>> And then discuss about why not doing the same in released packages (sorry
>>>> if I missed some arguments here).
>>>> For that we need first to exactly know which components affect which ones.
>>>> I believe at this stage we don't want to send any specialpurpose component
>>>> to Attic, but this might be discussed also.
>>>>
>>>> Jacques
>>>>
>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>
>>>>  That is not difficult to assess. Do a download from trunk, and see how
>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download and
>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>
>>>>> Now multiply that with the number of branches you had in mind.
>>>>>
>>>>> Verstuurd vanaf mijn iPad
>>>>>
>>>>>  Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>> [hidden email]> het volgende geschreven:
>>>>>>
>>>>>>
>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>
>>>>>>> Is it Apache's concern that while people may be free to choose, ASF
>>>>>>> server capacity is not free nor unlimited?
>>>>>>>
>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure but
>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>> You said it :) At the moment I don't fear any overload on the svn server
>>>>>> from users downloading from releases branches instead of released packages.
>>>>>> OFBiz is not Tomcat ;)
>>>>>> But I must say I have no measures, so you got a point until-we/if-we-can
>>>>>> discover that. Because users can already do that, I think it's fair to use
>>>>>> this method as long as it's reasonable.
>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us the
>>>>>> truth (if can get them)
>>>>>>
>>>>>>  That may be the practical side of Apache's urging to get the releases
>>>>>>> following their guidelines.
>>>>>> Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I "fear"
>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>> hiding behind unknown numbers?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>  Ron
>>>>>>>
>>>>>>>>  On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>
>>>>>>>>> Does this solve ASF's issue about having users access the main
>>>>>>>>> servers?
>>>>>>>> I don't try to solve an issue, just to propose an alternative. It's a
>>>>>>>> free user choice, but with more elements
>>>>>>>>
>>>>>>>>  What do you put on the mirrors and how do you stop users from
>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>> Things stay as they are, it's only that we inform our users than
>>>>>>>> another way is possible and we give them enough elements of comparison to
>>>>>>>> choice, it's called freedom
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>  Ron
>>>>>>>>>
>>>>>>>>>>  On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>> disclaimer in the wiki page where all alternatives would be explained
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>> In the past the ASF Board asked to the OFBiz PMC to fix the release
>>>>>>>>>>> strategy of the project by providing officially voted release files
>>>>>>>>>>> thru
>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>> trunk.
>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>> than the
>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>> required
>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>> guarantee
>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Hi,
>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>> strategy
>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>> or maybe
>>>>>>>>>>>> better with a link to an explaining page (in details) in the wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>> all know
>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>> and I have
>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>> them.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>

[Ron Wheeler]

I don't know anything but I will help wherever ignorance is some sort of
advantage to the process.

Ron

On 14/11/2014 9:13 AM, Pierre Smits wrote:

> You'll be the first?
>
> Verstuurd vanaf mijn iPad
>
>> Op 14 nov. 2014 om 14:26 heeft Ron Wheeler <[hidden email]> het volgende geschreven:
>>
>> Can we start by separating the list into
>> Case 1 - Required. Were released in the past so have an implied warranty,  known to be used in production situations,  were part of previous releases or have current activity
>> Case 2 - Definitely don't need. Never finished. Tests that never worked.
>> Case 3 - Not sure. Can not remember who started this.
>>
>> This would add some specificity to the discussion and would allow people to come forward with objections or offers of support.
>>
>> Can we start to develop a KB about what modules interfere with other modules, where this shows up and how does one fix the problem if we need to run multiple modules that normally interfere?
>> This would help determine the work required to support releasing them and might lead to useful discussions about dynamic configuration tools that allow conflicting modules to co-exist.
>>
>> Is there a wiki page for each of the case 1 modules?
>>
>> Do we have volunteers to create and maintain the wiki pages at least?
>>
>> Ron
>>
>>
>>
>>> On 14/11/2014 7:55 AM, Jacques Le Roux wrote:
>>> I think we need to be sure of what we are doing.
>>>
>>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>>
>>> Jacques
>>>
>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>> What is your preference? Would you like to see them all in the release
>>>> packages? Some of them only? Which ones?
>>>>
>>>>
>>>>
>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> This is the easiest part, I was more thinking about how much is downloaded
>>>>> by users.
>>>>>
>>>>> Anyway this was just an idea to help user to cope with missing
>>>>> specialpurpose components in released packages.
>>>>>
>>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>>> decided to remove them. Why keeping them in the releases branches but not
>>>>> not in released packages is not clear to me.
>>>>>
>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>> w3xw6lipifdeks3z
>>>>> Actually we need to clarify 1st which components to keep active in release
>>>>> branches. For now it seems only ecommerce which is for me too restrictive.
>>>>> And then discuss about why not doing the same in released packages (sorry
>>>>> if I missed some arguments here).
>>>>> For that we need first to exactly know which components affect which ones.
>>>>> I believe at this stage we don't want to send any specialpurpose component
>>>>> to Attic, but this might be discussed also.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>
>>>>>   That is not difficult to assess. Do a download from trunk, and see how
>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download and
>>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>>
>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>
>>>>>> Verstuurd vanaf mijn iPad
>>>>>>
>>>>>>   Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>
>>>>>>>
>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>
>>>>>>>> Is it Apache's concern that while people may be free to choose, ASF
>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>
>>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure but
>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>> You said it :) At the moment I don't fear any overload on the svn server
>>>>>>> from users downloading from releases branches instead of released packages.
>>>>>>> OFBiz is not Tomcat ;)
>>>>>>> But I must say I have no measures, so you got a point until-we/if-we-can
>>>>>>> discover that. Because users can already do that, I think it's fair to use
>>>>>>> this method as long as it's reasonable.
>>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us the
>>>>>>> truth (if can get them)
>>>>>>>
>>>>>>>   That may be the practical side of Apache's urging to get the releases
>>>>>>>> following their guidelines.
>>>>>>> Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I "fear"
>>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>>> hiding behind unknown numbers?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>   Ron
>>>>>>>>>   On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>
>>>>>>>>>> Does this solve ASF's issue about having users access the main
>>>>>>>>>> servers?
>>>>>>>>> I don't try to solve an issue, just to propose an alternative. It's a
>>>>>>>>> free user choice, but with more elements
>>>>>>>>>
>>>>>>>>>   What do you put on the mirrors and how do you stop users from
>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>> Things stay as they are, it's only that we inform our users than
>>>>>>>>> another way is possible and we give them enough elements of comparison to
>>>>>>>>> choice, it's called freedom
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>   Ron
>>>>>>>>>>>   On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be explained
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> In the past the ASF Board asked to the OFBiz PMC to fix the release
>>>>>>>>>>>> strategy of the project by providing officially voted release files
>>>>>>>>>>>> thru
>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>>> trunk.
>>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>>> than the
>>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>>> required
>>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>>> guarantee
>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>> strategy
>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>> better with a link to an explaining page (in details) in the wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>>> all know
>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>>> and I have
>>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>>> them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>

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

[Pierre Smits]

Well, it is clear that despite what some are assuming or potentially regard
as worrisome, special purpose applications are used and evaluated by our
users.

Just read the testimonal by Simon about implementing OFBiz and using the
HHFacility component. Or the posting by Mandeep in the user ML about having
issues when trying to work with the POS component. And there are more
(ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc).

We have contributors providing issues and patches. That some of our
committers feel that they don't have help - because of whatever reason -
these issues to closure, we shouldn't have such arguments as the reason(s)
for this project to exclude good components from releases.

The best course of action is that we revert this mess, that was created by
excluding these components.

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
[hidden email]> wrote:

> I think we need to be sure of what we are doing.
>
> 1st question, is why in the 1st place we did that? What pushed us to do so?
>
> Jacques
>
> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>
>  What is your preference? Would you like to see them all in the release
>> packages? Some of them only? Which ones?
>>
>>
>>
>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>  This is the easiest part, I was more thinking about how much is
>>> downloaded
>>> by users.
>>>
>>> Anyway this was just an idea to help user to cope with missing
>>> specialpurpose components in released packages.
>>>
>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>> decided to remove them. Why keeping them in the releases branches but not
>>> not in released packages is not clear to me.
>>>
>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>> w3xw6lipifdeks3z
>>> Actually we need to clarify 1st which components to keep active in
>>> release
>>> branches. For now it seems only ecommerce which is for me too
>>> restrictive.
>>> And then discuss about why not doing the same in released packages (sorry
>>> if I missed some arguments here).
>>> For that we need first to exactly know which components affect which
>>> ones.
>>> I believe at this stage we don't want to send any specialpurpose
>>> component
>>> to Attic, but this might be discussed also.
>>>
>>> Jacques
>>>
>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>
>>>   That is not difficult to assess. Do a download from trunk, and see how
>>>
>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>> hidden files in .svn folders. Finally do a zip of the cleaned download
>>>> and
>>>> compare the original amount of Mb's with the size of the zip file. That
>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>
>>>> Now multiply that with the number of branches you had in mind.
>>>>
>>>> Verstuurd vanaf mijn iPad
>>>>
>>>>   Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>
>>>>> [hidden email]> het volgende geschreven:
>>>>>
>>>>>
>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>
>>>>>  Is it Apache's concern that while people may be free to choose, ASF
>>>>>> server capacity is not free nor unlimited?
>>>>>>
>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>> but
>>>>>> users are not supposed to be downloading from the SVN.
>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>
>>>>>>  You said it :) At the moment I don't fear any overload on the svn
>>>>> server
>>>>> from users downloading from releases branches instead of released
>>>>> packages.
>>>>> OFBiz is not Tomcat ;)
>>>>> But I must say I have no measures, so you got a point
>>>>> until-we/if-we-can
>>>>> discover that. Because users can already do that, I think it's fair to
>>>>> use
>>>>> this method as long as it's reasonable.
>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>> the
>>>>> truth (if can get them)
>>>>>
>>>>>   That may be the practical side of Apache's urging to get the releases
>>>>>
>>>>>> following their guidelines.
>>>>>>
>>>>>>  Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>> "fear"
>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>> hiding behind unknown numbers?
>>>>>
>>>>> Jacques
>>>>>
>>>>>   Ron
>>>>>
>>>>>>
>>>>>>   On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>
>>>>>>>  Does this solve ASF's issue about having users access the main
>>>>>>>> servers?
>>>>>>>>
>>>>>>>>  I don't try to solve an issue, just to propose an alternative.
>>>>>>> It's a
>>>>>>> free user choice, but with more elements
>>>>>>>
>>>>>>>   What do you put on the mirrors and how do you stop users from
>>>>>>>
>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>
>>>>>>>>  Things stay as they are, it's only that we inform our users than
>>>>>>> another way is possible and we give them enough elements of
>>>>>>> comparison to
>>>>>>> choice, it's called freedom
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>   Ron
>>>>>>>
>>>>>>>>
>>>>>>>>   On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>> explained
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>
>>>>>>>>>  In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>> release
>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>> files
>>>>>>>>>> thru
>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>> trunk.
>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>> than the
>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>> required
>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>> guarantee
>>>>>>>>>> License free issues etc...
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>>   Hi,
>>>>>>>>>>
>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>> strategy
>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>> or maybe
>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>> wiki.
>>>>>>>>>>>
>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>> all know
>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>> mostly libs,
>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>> and I have
>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>> them.
>>>>>>>>>>>
>>>>>>>>>>> What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

[Ron Wheeler]

Is it possible to separate them out while making it easy to install them
into a working deployment?
This will help identify the community around these modules and will make
it simpler for this community to document and maintain the modules.

Ron


On 14/11/2014 6:47 AM, Jacopo Cappellato wrote:

> What is your preference? Would you like to see them all in the release
> packages? Some of them only? Which ones?
>
>
>
> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> This is the easiest part, I was more thinking about how much is downloaded
>> by users.
>>
>> Anyway this was just an idea to help user to cope with missing
>> specialpurpose components in released packages.
>>
>> Now a question comes to my mind, I don't clearly remember the reasons we
>> decided to remove them. Why keeping them in the releases branches but not
>> not in released packages is not clear to me.
>>
>> I believe Jacopo kind of answered  at http://markmail.org/message/
>> w3xw6lipifdeks3z
>> Actually we need to clarify 1st which components to keep active in release
>> branches. For now it seems only ecommerce which is for me too restrictive.
>> And then discuss about why not doing the same in released packages (sorry
>> if I missed some arguments here).
>> For that we need first to exactly know which components affect which ones.
>> I believe at this stage we don't want to send any specialpurpose component
>> to Attic, but this might be discussed also.
>>
>> Jacques
>>
>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>
>>   That is not difficult to assess. Do a download from trunk, and see how
>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>> hidden files in .svn folders. Finally do a zip of the cleaned download and
>>> compare the original amount of Mb's with the size of the zip file. That
>>> difference is what is saved on storage and transfer cost of trunk code.
>>>
>>> Now multiply that with the number of branches you had in mind.
>>>
>>> Verstuurd vanaf mijn iPad
>>>
>>>   Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>> [hidden email]> het volgende geschreven:
>>>>
>>>>
>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>
>>>>> Is it Apache's concern that while people may be free to choose, ASF
>>>>> server capacity is not free nor unlimited?
>>>>>
>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure but
>>>>> users are not supposed to be downloading from the SVN.
>>>>> They are supposed to get downloads from local mirrors.
>>>>>
>>>> You said it :) At the moment I don't fear any overload on the svn server
>>>> from users downloading from releases branches instead of released packages.
>>>> OFBiz is not Tomcat ;)
>>>> But I must say I have no measures, so you got a point until-we/if-we-can
>>>> discover that. Because users can already do that, I think it's fair to use
>>>> this method as long as it's reasonable.
>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>> abuse from the Board, but let's be pragmatic, numbers should tell us the
>>>> truth (if can get them)
>>>>
>>>>   That may be the practical side of Apache's urging to get the releases
>>>>> following their guidelines.
>>>>>
>>>> Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I "fear"
>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>> hiding behind unknown numbers?
>>>>
>>>> Jacques
>>>>
>>>>   Ron
>>>>>
>>>>>   On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>
>>>>>>> Does this solve ASF's issue about having users access the main
>>>>>>> servers?
>>>>>>>
>>>>>> I don't try to solve an issue, just to propose an alternative. It's a
>>>>>> free user choice, but with more elements
>>>>>>
>>>>>>   What do you put on the mirrors and how do you stop users from
>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>
>>>>>> Things stay as they are, it's only that we inform our users than
>>>>>> another way is possible and we give them enough elements of comparison to
>>>>>> choice, it's called freedom
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>   Ron
>>>>>>>
>>>>>>>   On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>> disclaimer in the wiki page where all alternatives would be explained
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> In the past the ASF Board asked to the OFBiz PMC to fix the release
>>>>>>>>> strategy of the project by providing officially voted release files
>>>>>>>>> thru
>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>> trunk.
>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>> than the
>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>> required
>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>> guarantee
>>>>>>>>> License free issues etc...
>>>>>>>>>
>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>   Hi,
>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>> strategy
>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>> or maybe
>>>>>>>>>> better with a link to an explaining page (in details) in the wiki.
>>>>>>>>>>
>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>> all know
>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>> mostly libs,
>>>>>>>>>> and even mostly jars.
>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>> and I have
>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>> them.
>>>>>>>>>>
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>

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

[Jacques Le Roux]

Hi Jacopo,

I looked a bit back. Even if it's not clearly related I trace this back to the slim-down effort. We can forget it since nobody never complained (pfew...).

Then you proposed to move some component from specialpurpose to extras.
As you said, not every people were happy with it (at least Pierre and in a less measure I)
I then suggested some components to keep markmail.org/message/4camcprzximkcftc

<<assetmaint
ecommerce
example*
pos
maybe myportal?
projectmgr
scrum
and maybe webpos?>>

In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I suggested to associate people with components
<<project manager (Pierre Smits?)

     scrum (Hans?)

     examples and ext (at least me)

     myportal (French people use portals, not sure for myportal?)
>>
When I look now at my 1st list, obviously I can also support the POS even if I have less interest in it now.

Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
I don't like the etc. ;) but I can agree to add
HHFacility and CMSSITE to my list

Also in this list birt is missing, clearly at least Chatree has an interest in it and knows how to maintain it.
I don't know if Anil or/and Adrian have still an interest in ASSETMAINT but anyway it seems it's worth to keep it.
HHFacility does not need much work to maintain
For CMSSITE I'm unsure, but it's interesting for the online help (too bad BJ is no longer with us)
BTWcmssite/cms/APACHE_OFBIZ_HTML  <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML>  is no longer working (was still in August in trunk demo) I will investigate why

 
At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
<<A moment I even thought about Attic for some unmaintained components
(ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
cares?>>

But this is not a good idea. Obviously we have some responsabilities with our users.
Now I still wonder about who is really using appserver, ebaystore, googlebase, googlecheckou, oagis and jetty components...

This is what I can say so far

HTH

Jacques


Le 14/11/2014 14:20, Jacopo Cappellato a écrit :

> It was a long discussion that was done in the public lists and I wouldn't
> want to rehash it (you have been part of it for sure): there were concerns
> and discussions about duplicated jars, poor quality code, stale code, files
> with questionable licenses etc... on the other side there were people
> worried about removing features from the system etc...
> I think it would be better to address each component individually and,
> since you would like to "cope with missing specialpurpose components in
> released packages", this is why I am asking you what are the components
> that should be included in the trunk/release branch/releases.
>
> Jacopo
>
> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> I think we need to be sure of what we are doing.
>>
>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>
>> Jacques
>>
>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>
>>   What is your preference? Would you like to see them all in the release
>>> packages? Some of them only? Which ones?
>>>
>>>
>>>
>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>   This is the easiest part, I was more thinking about how much is
>>>> downloaded
>>>> by users.
>>>>
>>>> Anyway this was just an idea to help user to cope with missing
>>>> specialpurpose components in released packages.
>>>>
>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>> decided to remove them. Why keeping them in the releases branches but not
>>>> not in released packages is not clear to me.
>>>>
>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>> w3xw6lipifdeks3z
>>>> Actually we need to clarify 1st which components to keep active in
>>>> release
>>>> branches. For now it seems only ecommerce which is for me too
>>>> restrictive.
>>>> And then discuss about why not doing the same in released packages (sorry
>>>> if I missed some arguments here).
>>>> For that we need first to exactly know which components affect which
>>>> ones.
>>>> I believe at this stage we don't want to send any specialpurpose
>>>> component
>>>> to Attic, but this might be discussed also.
>>>>
>>>> Jacques
>>>>
>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>
>>>>    That is not difficult to assess. Do a download from trunk, and see how
>>>>
>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download
>>>>> and
>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>
>>>>> Now multiply that with the number of branches you had in mind.
>>>>>
>>>>> Verstuurd vanaf mijn iPad
>>>>>
>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>
>>>>>> [hidden email]> het volgende geschreven:
>>>>>>
>>>>>>
>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>
>>>>>>   Is it Apache's concern that while people may be free to choose, ASF
>>>>>>> server capacity is not free nor unlimited?
>>>>>>>
>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>> but
>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>
>>>>>>>   You said it :) At the moment I don't fear any overload on the svn
>>>>>> server
>>>>>> from users downloading from releases branches instead of released
>>>>>> packages.
>>>>>> OFBiz is not Tomcat ;)
>>>>>> But I must say I have no measures, so you got a point
>>>>>> until-we/if-we-can
>>>>>> discover that. Because users can already do that, I think it's fair to
>>>>>> use
>>>>>> this method as long as it's reasonable.
>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>> the
>>>>>> truth (if can get them)
>>>>>>
>>>>>>    That may be the practical side of Apache's urging to get the releases
>>>>>>
>>>>>>> following their guidelines.
>>>>>>>
>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>> "fear"
>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>> hiding behind unknown numbers?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>    Ron
>>>>>>
>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>
>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>> servers?
>>>>>>>>>
>>>>>>>>>   I don't try to solve an issue, just to propose an alternative.
>>>>>>>> It's a
>>>>>>>> free user choice, but with more elements
>>>>>>>>
>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>
>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>
>>>>>>>>>   Things stay as they are, it's only that we inform our users than
>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>> comparison to
>>>>>>>> choice, it's called freedom
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>    Ron
>>>>>>>>
>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>> explained
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>> release
>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>> files
>>>>>>>>>>> thru
>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>> trunk.
>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>> than the
>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>> required
>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>> guarantee
>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>    Hi,
>>>>>>>>>>>
>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>> strategy
>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>> or maybe
>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>> wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>> all know
>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>> and I have
>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>> them.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

[Jacques Le Roux]

Le 27/11/2014 15:16, Jacques Le Roux a écrit :
> For CMSSITE I'm unsure, but it's interesting for the online help (too bad BJ is no longer with us)
> BTWcmssite/cms/APACHE_OFBIZ_HTML <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML> is no longer working (was still in August in
> trunk demo) I will investigate why

This is due to r1635232.

Jacques

[Jacopo Cappellato-4]

On Nov 27, 2014, at 3:16 PM, Jacques Le Roux <[hidden email]> wrote:

> Hi Jacopo,
>
> I looked a bit back. Even if it's not clearly related I trace this back to the slim-down effort. We can forget it since nobody never complained (pfew...).
>
> Then you proposed to move some component from specialpurpose to extras.
> As you said, not every people were happy with it (at least Pierre and in a less measure I)
> I then suggested some components to keep markmail.org/message/4camcprzximkcftc
>
> <<assetmaint
> ecommerce
> example*
> pos
> maybe myportal?
> projectmgr
> scrum
> and maybe webpos?>>
>
> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I suggested to associate people with components

I don't like the idea of associating code to persons: this is not in line with the spirit of the project in the ASF. Once the code has been contributed, it is owned by the community and not by a group of persons.

As regards the list of components, I am having an hard time at following what you would like to release or not: could you please (changing the subject would be great) provide the list of components that you think are worth of being part of the release and why? Others will comment with their own. In this way we will understand how many volunteers we have to maintain them, make sure the vulnerabilities are fixed, that they comply the analysis performed by tools like RAT etc...
Just one (important) clarification: we are talking about the components that you would like to have in the releases, not the component that should go to attic.
One final point: do we all agree that all the components that either override the web applications of other components or modify the entities defined by other components or override service definitions in order to provide more specialized features should be set as "disabled" by default? In my opinion this is an important point because otherwise, even when you install OFBiz in production (ant load-seed) you will get a data model with a specialized set of fields. Special components and special behavior can be released but should be disabled by default.

Best regards,

Jacopo

> <<project manager (Pierre Smits?)
>
>    scrum (Hans?)
>
>    examples and ext (at least me)
>
>    myportal (French people use portals, not sure for myportal?)
>>>
> When I look now at my 1st list, obviously I can also support the POS even if I have less interest in it now.
>
> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
> I don't like the etc. ;) but I can agree to add
> HHFacility and CMSSITE to my list
>
> Also in this list birt is missing, clearly at least Chatree has an interest in it and knows how to maintain it.
> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT but anyway it seems it's worth to keep it.
> HHFacility does not need much work to maintain
> For CMSSITE I'm unsure, but it's interesting for the online help (too bad BJ is no longer with us)
> BTWcmssite/cms/APACHE_OFBIZ_HTML  <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML>  is no longer working (was still in August in trunk demo) I will investigate why
>
> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
> <<A moment I even thought about Attic for some unmaintained components
> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
> cares?>>
>
> But this is not a good idea. Obviously we have some responsabilities with our users.
> Now I still wonder about who is really using appserver, ebaystore, googlebase, googlecheckou, oagis and jetty components...
>
> This is what I can say so far
>
> HTH
>
> Jacques
>
>
> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>> It was a long discussion that was done in the public lists and I wouldn't
>> want to rehash it (you have been part of it for sure): there were concerns
>> and discussions about duplicated jars, poor quality code, stale code, files
>> with questionable licenses etc... on the other side there were people
>> worried about removing features from the system etc...
>> I think it would be better to address each component individually and,
>> since you would like to "cope with missing specialpurpose components in
>> released packages", this is why I am asking you what are the components
>> that should be included in the trunk/release branch/releases.
>>
>> Jacopo
>>
>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> I think we need to be sure of what we are doing.
>>>
>>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>>
>>> Jacques
>>>
>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>
>>>  What is your preference? Would you like to see them all in the release
>>>> packages? Some of them only? Which ones?
>>>>
>>>>
>>>>
>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>  This is the easiest part, I was more thinking about how much is
>>>>> downloaded
>>>>> by users.
>>>>>
>>>>> Anyway this was just an idea to help user to cope with missing
>>>>> specialpurpose components in released packages.
>>>>>
>>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>>> decided to remove them. Why keeping them in the releases branches but not
>>>>> not in released packages is not clear to me.
>>>>>
>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>> w3xw6lipifdeks3z
>>>>> Actually we need to clarify 1st which components to keep active in
>>>>> release
>>>>> branches. For now it seems only ecommerce which is for me too
>>>>> restrictive.
>>>>> And then discuss about why not doing the same in released packages (sorry
>>>>> if I missed some arguments here).
>>>>> For that we need first to exactly know which components affect which
>>>>> ones.
>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>> component
>>>>> to Attic, but this might be discussed also.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>
>>>>>   That is not difficult to assess. Do a download from trunk, and see how
>>>>>
>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download
>>>>>> and
>>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>>
>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>
>>>>>> Verstuurd vanaf mijn iPad
>>>>>>
>>>>>>   Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>
>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>
>>>>>>>
>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>
>>>>>>>  Is it Apache's concern that while people may be free to choose, ASF
>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>
>>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>>> but
>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>
>>>>>>>>  You said it :) At the moment I don't fear any overload on the svn
>>>>>>> server
>>>>>>> from users downloading from releases branches instead of released
>>>>>>> packages.
>>>>>>> OFBiz is not Tomcat ;)
>>>>>>> But I must say I have no measures, so you got a point
>>>>>>> until-we/if-we-can
>>>>>>> discover that. Because users can already do that, I think it's fair to
>>>>>>> use
>>>>>>> this method as long as it's reasonable.
>>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>>> the
>>>>>>> truth (if can get them)
>>>>>>>
>>>>>>>   That may be the practical side of Apache's urging to get the releases
>>>>>>>
>>>>>>>> following their guidelines.
>>>>>>>>
>>>>>>>>  Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>>> "fear"
>>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>>> hiding behind unknown numbers?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>   Ron
>>>>>>>
>>>>>>>>   On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>
>>>>>>>>>  Does this solve ASF's issue about having users access the main
>>>>>>>>>> servers?
>>>>>>>>>>
>>>>>>>>>>  I don't try to solve an issue, just to propose an alternative.
>>>>>>>>> It's a
>>>>>>>>> free user choice, but with more elements
>>>>>>>>>
>>>>>>>>>   What do you put on the mirrors and how do you stop users from
>>>>>>>>>
>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>
>>>>>>>>>>  Things stay as they are, it's only that we inform our users than
>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>> comparison to
>>>>>>>>> choice, it's called freedom
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>   Ron
>>>>>>>>>
>>>>>>>>>>   On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>> explained
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>
>>>>>>>>>>>  In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>> release
>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>> files
>>>>>>>>>>>> thru
>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>>> trunk.
>>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>>> than the
>>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>>> required
>>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>>> guarantee
>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>> strategy
>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>>> all know
>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>>> and I have
>>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>>> them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>

[Adrian Crum-3]

I would be willing to spin off Asset Maintenance to a separate project.
I was thinking it could be a good test-run of the concept.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 11/27/2014 2:16 PM, Jacques Le Roux wrote:

> Hi Jacopo,
>
> I looked a bit back. Even if it's not clearly related I trace this back
> to the slim-down effort. We can forget it since nobody never complained
> (pfew...).
>
> Then you proposed to move some component from specialpurpose to extras.
> As you said, not every people were happy with it (at least Pierre and in
> a less measure I)
> I then suggested some components to keep
> markmail.org/message/4camcprzximkcftc
>
> <<assetmaint
> ecommerce
> example*
> pos
> maybe myportal?
> projectmgr
> scrum
> and maybe webpos?>>
>
> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I
> suggested to associate people with components
> <<project manager (Pierre Smits?)
>
>      scrum (Hans?)
>
>      examples and ext (at least me)
>
>      myportal (French people use portals, not sure for myportal?)
>>>
> When I look now at my 1st list, obviously I can also support the POS
> even if I have less interest in it now.
>
> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
> I don't like the etc. ;) but I can agree to add
> HHFacility and CMSSITE to my list
>
> Also in this list birt is missing, clearly at least Chatree has an
> interest in it and knows how to maintain it.
> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT
> but anyway it seems it's worth to keep it.
> HHFacility does not need much work to maintain
> For CMSSITE I'm unsure, but it's interesting for the online help (too
> bad BJ is no longer with us)
> BTWcmssite/cms/APACHE_OFBIZ_HTML
> <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML>  is
> no longer working (was still in August in trunk demo) I will investigate
> why
>
>
> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
> <<A moment I even thought about Attic for some unmaintained components
> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
> cares?>>
>
> But this is not a good idea. Obviously we have some responsabilities
> with our users.
> Now I still wonder about who is really using appserver, ebaystore,
> googlebase, googlecheckou, oagis and jetty components...
>
> This is what I can say so far
>
> HTH
>
> Jacques
>
>
> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>> It was a long discussion that was done in the public lists and I wouldn't
>> want to rehash it (you have been part of it for sure): there were
>> concerns
>> and discussions about duplicated jars, poor quality code, stale code,
>> files
>> with questionable licenses etc... on the other side there were people
>> worried about removing features from the system etc...
>> I think it would be better to address each component individually and,
>> since you would like to "cope with missing specialpurpose components in
>> released packages", this is why I am asking you what are the components
>> that should be included in the trunk/release branch/releases.
>>
>> Jacopo
>>
>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> I think we need to be sure of what we are doing.
>>>
>>> 1st question, is why in the 1st place we did that? What pushed us to
>>> do so?
>>>
>>> Jacques
>>>
>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>
>>>   What is your preference? Would you like to see them all in the release
>>>> packages? Some of them only? Which ones?
>>>>
>>>>
>>>>
>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>   This is the easiest part, I was more thinking about how much is
>>>>> downloaded
>>>>> by users.
>>>>>
>>>>> Anyway this was just an idea to help user to cope with missing
>>>>> specialpurpose components in released packages.
>>>>>
>>>>> Now a question comes to my mind, I don't clearly remember the
>>>>> reasons we
>>>>> decided to remove them. Why keeping them in the releases branches
>>>>> but not
>>>>> not in released packages is not clear to me.
>>>>>
>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>> w3xw6lipifdeks3z
>>>>> Actually we need to clarify 1st which components to keep active in
>>>>> release
>>>>> branches. For now it seems only ecommerce which is for me too
>>>>> restrictive.
>>>>> And then discuss about why not doing the same in released packages
>>>>> (sorry
>>>>> if I missed some arguments here).
>>>>> For that we need first to exactly know which components affect which
>>>>> ones.
>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>> component
>>>>> to Attic, but this might be discussed also.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>
>>>>>    That is not difficult to assess. Do a download from trunk, and
>>>>> see how
>>>>>
>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently
>>>>>> remove all
>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned
>>>>>> download
>>>>>> and
>>>>>> compare the original amount of Mb's with the size of the zip file.
>>>>>> That
>>>>>> difference is what is saved on storage and transfer cost of trunk
>>>>>> code.
>>>>>>
>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>
>>>>>> Verstuurd vanaf mijn iPad
>>>>>>
>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>
>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>
>>>>>>>
>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>
>>>>>>>   Is it Apache's concern that while people may be free to choose,
>>>>>>> ASF
>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>
>>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>>> but
>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>
>>>>>>>>   You said it :) At the moment I don't fear any overload on the svn
>>>>>>> server
>>>>>>> from users downloading from releases branches instead of released
>>>>>>> packages.
>>>>>>> OFBiz is not Tomcat ;)
>>>>>>> But I must say I have no measures, so you got a point
>>>>>>> until-we/if-we-can
>>>>>>> discover that. Because users can already do that, I think it's
>>>>>>> fair to
>>>>>>> use
>>>>>>> this method as long as it's reasonable.
>>>>>>> Of course, having that suggested in a TLP project could be viewed
>>>>>>> as an
>>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>>> the
>>>>>>> truth (if can get them)
>>>>>>>
>>>>>>>    That may be the practical side of Apache's urging to get the
>>>>>>> releases
>>>>>>>
>>>>>>>> following their guidelines.
>>>>>>>>
>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>>> "fear"
>>>>>>> it's not a problem. Can we discuss with the board in case,
>>>>>>> instead of
>>>>>>> hiding behind unknown numbers?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>    Ron
>>>>>>>
>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>
>>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>>> servers?
>>>>>>>>>>
>>>>>>>>>>   I don't try to solve an issue, just to propose an alternative.
>>>>>>>>> It's a
>>>>>>>>> free user choice, but with more elements
>>>>>>>>>
>>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>>
>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>
>>>>>>>>>>   Things stay as they are, it's only that we inform our users
>>>>>>>>>> than
>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>> comparison to
>>>>>>>>> choice, it's called freedom
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>    Ron
>>>>>>>>>
>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> For the licence free issues (an other related stuff) we could
>>>>>>>>>>> put a
>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>> explained
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>
>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>> release
>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>> files
>>>>>>>>>>>> thru
>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to
>>>>>>>>>>>> get the
>>>>>>>>>>>> trunk.
>>>>>>>>>>>> Officially asking the user to use a release branch would be
>>>>>>>>>>>> better
>>>>>>>>>>>> than the
>>>>>>>>>>>> trunk but would bring back similar concerns: an official
>>>>>>>>>>>> vote is
>>>>>>>>>>>> required
>>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>>> guarantee
>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>> strategy
>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>> And that we could  expose this way of doing in our download
>>>>>>>>>>>>> page,
>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF.
>>>>>>>>>>>>> But we
>>>>>>>>>>>>> all know
>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>> Most of us are actually using this way in their custom
>>>>>>>>>>>>> projects
>>>>>>>>>>>>> and I have
>>>>>>>>>>>>> a feeling it would not only help our users but also us to
>>>>>>>>>>>>> support
>>>>>>>>>>>>> them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
>

[Jacques Le Roux]

You mean outside of OFBiz? As a sub-project like suggested Ron? Or in Github or something like that?

Jacques

Le 27/11/2014 16:31, Adrian Crum a écrit :

> I would be willing to spin off Asset Maintenance to a separate project. I was thinking it could be a good test-run of the concept.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 11/27/2014 2:16 PM, Jacques Le Roux wrote:
>> Hi Jacopo,
>>
>> I looked a bit back. Even if it's not clearly related I trace this back
>> to the slim-down effort. We can forget it since nobody never complained
>> (pfew...).
>>
>> Then you proposed to move some component from specialpurpose to extras.
>> As you said, not every people were happy with it (at least Pierre and in
>> a less measure I)
>> I then suggested some components to keep
>> markmail.org/message/4camcprzximkcftc
>>
>> <<assetmaint
>> ecommerce
>> example*
>> pos
>> maybe myportal?
>> projectmgr
>> scrum
>> and maybe webpos?>>
>>
>> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I
>> suggested to associate people with components
>> <<project manager (Pierre Smits?)
>>
>>      scrum (Hans?)
>>
>>      examples and ext (at least me)
>>
>>      myportal (French people use portals, not sure for myportal?)
>>>>
>> When I look now at my 1st list, obviously I can also support the POS
>> even if I have less interest in it now.
>>
>> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
>> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
>> I don't like the etc. ;) but I can agree to add
>> HHFacility and CMSSITE to my list
>>
>> Also in this list birt is missing, clearly at least Chatree has an
>> interest in it and knows how to maintain it.
>> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT
>> but anyway it seems it's worth to keep it.
>> HHFacility does not need much work to maintain
>> For CMSSITE I'm unsure, but it's interesting for the online help (too
>> bad BJ is no longer with us)
>> BTWcmssite/cms/APACHE_OFBIZ_HTML
>> <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML> is
>> no longer working (was still in August in trunk demo) I will investigate
>> why
>>
>>
>> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
>> <<A moment I even thought about Attic for some unmaintained components
>> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
>> cares?>>
>>
>> But this is not a good idea. Obviously we have some responsabilities
>> with our users.
>> Now I still wonder about who is really using appserver, ebaystore,
>> googlebase, googlecheckou, oagis and jetty components...
>>
>> This is what I can say so far
>>
>> HTH
>>
>> Jacques
>>
>>
>> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>>> It was a long discussion that was done in the public lists and I wouldn't
>>> want to rehash it (you have been part of it for sure): there were
>>> concerns
>>> and discussions about duplicated jars, poor quality code, stale code,
>>> files
>>> with questionable licenses etc... on the other side there were people
>>> worried about removing features from the system etc...
>>> I think it would be better to address each component individually and,
>>> since you would like to "cope with missing specialpurpose components in
>>> released packages", this is why I am asking you what are the components
>>> that should be included in the trunk/release branch/releases.
>>>
>>> Jacopo
>>>
>>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> I think we need to be sure of what we are doing.
>>>>
>>>> 1st question, is why in the 1st place we did that? What pushed us to
>>>> do so?
>>>>
>>>> Jacques
>>>>
>>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>>
>>>>   What is your preference? Would you like to see them all in the release
>>>>> packages? Some of them only? Which ones?
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>   This is the easiest part, I was more thinking about how much is
>>>>>> downloaded
>>>>>> by users.
>>>>>>
>>>>>> Anyway this was just an idea to help user to cope with missing
>>>>>> specialpurpose components in released packages.
>>>>>>
>>>>>> Now a question comes to my mind, I don't clearly remember the
>>>>>> reasons we
>>>>>> decided to remove them. Why keeping them in the releases branches
>>>>>> but not
>>>>>> not in released packages is not clear to me.
>>>>>>
>>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>>> w3xw6lipifdeks3z
>>>>>> Actually we need to clarify 1st which components to keep active in
>>>>>> release
>>>>>> branches. For now it seems only ecommerce which is for me too
>>>>>> restrictive.
>>>>>> And then discuss about why not doing the same in released packages
>>>>>> (sorry
>>>>>> if I missed some arguments here).
>>>>>> For that we need first to exactly know which components affect which
>>>>>> ones.
>>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>>> component
>>>>>> to Attic, but this might be discussed also.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>>
>>>>>>    That is not difficult to assess. Do a download from trunk, and
>>>>>> see how
>>>>>>
>>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently
>>>>>>> remove all
>>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned
>>>>>>> download
>>>>>>> and
>>>>>>> compare the original amount of Mb's with the size of the zip file.
>>>>>>> That
>>>>>>> difference is what is saved on storage and transfer cost of trunk
>>>>>>> code.
>>>>>>>
>>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>>
>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>
>>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>>
>>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>>
>>>>>>>>   Is it Apache's concern that while people may be free to choose,
>>>>>>>> ASF
>>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>>
>>>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>>>> but
>>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>>
>>>>>>>>>   You said it :) At the moment I don't fear any overload on the svn
>>>>>>>> server
>>>>>>>> from users downloading from releases branches instead of released
>>>>>>>> packages.
>>>>>>>> OFBiz is not Tomcat ;)
>>>>>>>> But I must say I have no measures, so you got a point
>>>>>>>> until-we/if-we-can
>>>>>>>> discover that. Because users can already do that, I think it's
>>>>>>>> fair to
>>>>>>>> use
>>>>>>>> this method as long as it's reasonable.
>>>>>>>> Of course, having that suggested in a TLP project could be viewed
>>>>>>>> as an
>>>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>>>> the
>>>>>>>> truth (if can get them)
>>>>>>>>
>>>>>>>>    That may be the practical side of Apache's urging to get the
>>>>>>>> releases
>>>>>>>>
>>>>>>>>> following their guidelines.
>>>>>>>>>
>>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>>>> "fear"
>>>>>>>> it's not a problem. Can we discuss with the board in case,
>>>>>>>> instead of
>>>>>>>> hiding behind unknown numbers?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>    Ron
>>>>>>>>
>>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>>
>>>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>>>> servers?
>>>>>>>>>>>
>>>>>>>>>>>   I don't try to solve an issue, just to propose an alternative.
>>>>>>>>>> It's a
>>>>>>>>>> free user choice, but with more elements
>>>>>>>>>>
>>>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>>>
>>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>>
>>>>>>>>>>>   Things stay as they are, it's only that we inform our users
>>>>>>>>>>> than
>>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>>> comparison to
>>>>>>>>>> choice, it's called freedom
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>    Ron
>>>>>>>>>>
>>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>>
>>>>>>>>>>>> For the licence free issues (an other related stuff) we could
>>>>>>>>>>>> put a
>>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>>> explained
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>>> release
>>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>>> files
>>>>>>>>>>>>> thru
>>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to
>>>>>>>>>>>>> get the
>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>> Officially asking the user to use a release branch would be
>>>>>>>>>>>>> better
>>>>>>>>>>>>> than the
>>>>>>>>>>>>> trunk but would bring back similar concerns: an official
>>>>>>>>>>>>> vote is
>>>>>>>>>>>>> required
>>>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>>>> guarantee
>>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>>> And that we could  expose this way of doing in our download
>>>>>>>>>>>>>> page,
>>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF.
>>>>>>>>>>>>>> But we
>>>>>>>>>>>>>> all know
>>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>>> Most of us are actually using this way in their custom
>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>> and I have
>>>>>>>>>>>>>> a feeling it would not only help our users but also us to
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
>>
>

[Jacques Le Roux]

Le 27/11/2014 16:30, Jacopo Cappellato a écrit :

> On Nov 27, 2014, at 3:16 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Hi Jacopo,
>>
>> I looked a bit back. Even if it's not clearly related I trace this back to the slim-down effort. We can forget it since nobody never complained (pfew...).
>>
>> Then you proposed to move some component from specialpurpose to extras.
>> As you said, not every people were happy with it (at least Pierre and in a less measure I)
>> I then suggested some components to keep markmail.org/message/4camcprzximkcftc
>>
>> <<assetmaint
>> ecommerce
>> example*
>> pos
>> maybe myportal?
>> projectmgr
>> scrum
>> and maybe webpos?>>
>>
>> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I suggested to associate people with components
> I don't like the idea of associating code to persons: this is not in line with the spirit of the project in the ASF. Once the code has been contributed, it is owned by the community and not by a group of persons.

Don't get me wrong, this is only to remind who are the interested persons and hopefully those who can help to maintain and contribute. The volunteers
you seek below.

> As regards the list of components, I am having an hard time at following what you would like to release or not: could you please (changing the subject would be great) provide the list of components that you think are worth of being part of the release and why?

Yes I thought about create a new thread for that but since you asked, I answered :).
I always like to have references that was also the reason of this message, a kind of summary of my thoughts and of the situation as I see it.

> Others will comment with their own.
> In this way we will understand how many volunteers we have to maintain them, make sure the vulnerabilities are fixed, that they comply the analysis performed by tools like RAT etc...
>
> Just one (important) clarification: we are talking about the components that you would like to have in the releases, not the component that should go to attic.

Do we want to keep all current components (some disabled) until we decide those which should  go to Attic? For instance we already kind of spoke about
appserver going to Attic.
This could be decided before for some components; the less components, the less discussions.  But yes, we can go with separate discussions, or we will
see that later...

> One final point: do we all agree that all the components that either override the web applications of other components or modify the entities defined by other components or override service definitions in order to provide more specialized features should be set as "disabled" by default? In my opinion this is an important point because otherwise, even when you install OFBiz in production (ant load-seed) you will get a data model with a specialized set of fields. Special components and special behavior can be released but should be disabled by default.

Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but
probably this one
1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
3) Components to keep enabled. They must be maintained and have no interactions with other components

For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at the
functionality or other levels.

Everybody agree?

Jacques

>
> Best regards,
>
> Jacopo
>
>> <<project manager (Pierre Smits?)
>>
>>     scrum (Hans?)
>>
>>     examples and ext (at least me)
>>
>>     myportal (French people use portals, not sure for myportal?)
>> When I look now at my 1st list, obviously I can also support the POS even if I have less interest in it now.
>>
>> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
>> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
>> I don't like the etc. ;) but I can agree to add
>> HHFacility and CMSSITE to my list
>>
>> Also in this list birt is missing, clearly at least Chatree has an interest in it and knows how to maintain it.
>> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT but anyway it seems it's worth to keep it.
>> HHFacility does not need much work to maintain
>> For CMSSITE I'm unsure, but it's interesting for the online help (too bad BJ is no longer with us)
>> BTWcmssite/cms/APACHE_OFBIZ_HTML  <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML>  is no longer working (was still in August in trunk demo) I will investigate why
>>
>> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
>> <<A moment I even thought about Attic for some unmaintained components
>> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
>> cares?>>
>>
>> But this is not a good idea. Obviously we have some responsabilities with our users.
>> Now I still wonder about who is really using appserver, ebaystore, googlebase, googlecheckou, oagis and jetty components...
>>
>> This is what I can say so far
>>
>> HTH
>>
>> Jacques
>>
>>
>> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>>> It was a long discussion that was done in the public lists and I wouldn't
>>> want to rehash it (you have been part of it for sure): there were concerns
>>> and discussions about duplicated jars, poor quality code, stale code, files
>>> with questionable licenses etc... on the other side there were people
>>> worried about removing features from the system etc...
>>> I think it would be better to address each component individually and,
>>> since you would like to "cope with missing specialpurpose components in
>>> released packages", this is why I am asking you what are the components
>>> that should be included in the trunk/release branch/releases.
>>>
>>> Jacopo
>>>
>>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> I think we need to be sure of what we are doing.
>>>>
>>>> 1st question, is why in the 1st place we did that? What pushed us to do so?
>>>>
>>>> Jacques
>>>>
>>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>>
>>>>   What is your preference? Would you like to see them all in the release
>>>>> packages? Some of them only? Which ones?
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>   This is the easiest part, I was more thinking about how much is
>>>>>> downloaded
>>>>>> by users.
>>>>>>
>>>>>> Anyway this was just an idea to help user to cope with missing
>>>>>> specialpurpose components in released packages.
>>>>>>
>>>>>> Now a question comes to my mind, I don't clearly remember the reasons we
>>>>>> decided to remove them. Why keeping them in the releases branches but not
>>>>>> not in released packages is not clear to me.
>>>>>>
>>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>>> w3xw6lipifdeks3z
>>>>>> Actually we need to clarify 1st which components to keep active in
>>>>>> release
>>>>>> branches. For now it seems only ecommerce which is for me too
>>>>>> restrictive.
>>>>>> And then discuss about why not doing the same in released packages (sorry
>>>>>> if I missed some arguments here).
>>>>>> For that we need first to exactly know which components affect which
>>>>>> ones.
>>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>>> component
>>>>>> to Attic, but this might be discussed also.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>>
>>>>>>    That is not difficult to assess. Do a download from trunk, and see how
>>>>>>
>>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
>>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned download
>>>>>>> and
>>>>>>> compare the original amount of Mb's with the size of the zip file. That
>>>>>>> difference is what is saved on storage and transfer cost of trunk code.
>>>>>>>
>>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>>
>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>
>>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>>
>>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>>
>>>>>>>>   Is it Apache's concern that while people may be free to choose, ASF
>>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>>
>>>>>>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure
>>>>>>>>> but
>>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>>
>>>>>>>>>   You said it :) At the moment I don't fear any overload on the svn
>>>>>>>> server
>>>>>>>> from users downloading from releases branches instead of released
>>>>>>>> packages.
>>>>>>>> OFBiz is not Tomcat ;)
>>>>>>>> But I must say I have no measures, so you got a point
>>>>>>>> until-we/if-we-can
>>>>>>>> discover that. Because users can already do that, I think it's fair to
>>>>>>>> use
>>>>>>>> this method as long as it's reasonable.
>>>>>>>> Of course, having that suggested in a TLP project could be viewed as an
>>>>>>>> abuse from the Board, but let's be pragmatic, numbers should tell us
>>>>>>>> the
>>>>>>>> truth (if can get them)
>>>>>>>>
>>>>>>>>    That may be the practical side of Apache's urging to get the releases
>>>>>>>>
>>>>>>>>> following their guidelines.
>>>>>>>>>
>>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I
>>>>>>>> "fear"
>>>>>>>> it's not a problem. Can we discuss with the board in case, instead of
>>>>>>>> hiding behind unknown numbers?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>    Ron
>>>>>>>>
>>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>>
>>>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>>>> servers?
>>>>>>>>>>>
>>>>>>>>>>>   I don't try to solve an issue, just to propose an alternative.
>>>>>>>>>> It's a
>>>>>>>>>> free user choice, but with more elements
>>>>>>>>>>
>>>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>>>
>>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>>
>>>>>>>>>>>   Things stay as they are, it's only that we inform our users than
>>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>>> comparison to
>>>>>>>>>> choice, it's called freedom
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>    Ron
>>>>>>>>>>
>>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>>
>>>>>>>>>>>> For the licence free issues (an other related stuff) we could put a
>>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>>> explained
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>>> release
>>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>>> files
>>>>>>>>>>>>> thru
>>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the
>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>> Officially asking the user to use a release branch would be better
>>>>>>>>>>>>> than the
>>>>>>>>>>>>> trunk but would bring back similar concerns: an official vote is
>>>>>>>>>>>>> required
>>>>>>>>>>>>> to publish a product to the outside of the project in order to
>>>>>>>>>>>>> guarantee
>>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>>> And that we could  expose this way of doing in our download page,
>>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we
>>>>>>>>>>>>>> all know
>>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which are
>>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>>> Most of us are actually using this way in their custom projects
>>>>>>>>>>>>>> and I have
>>>>>>>>>>>>>> a feeling it would not only help our users but also us to support
>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>

[Adrian Crum-3]

I think the term "separate project" is self-explanatory.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 11/27/2014 5:28 PM, Jacques Le Roux wrote:

> You mean outside of OFBiz? As a sub-project like suggested Ron? Or in
> Github or something like that?
>
> Jacques
>
> Le 27/11/2014 16:31, Adrian Crum a écrit :
>> I would be willing to spin off Asset Maintenance to a separate
>> project. I was thinking it could be a good test-run of the concept.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 11/27/2014 2:16 PM, Jacques Le Roux wrote:
>>> Hi Jacopo,
>>>
>>> I looked a bit back. Even if it's not clearly related I trace this back
>>> to the slim-down effort. We can forget it since nobody never complained
>>> (pfew...).
>>>
>>> Then you proposed to move some component from specialpurpose to extras.
>>> As you said, not every people were happy with it (at least Pierre and in
>>> a less measure I)
>>> I then suggested some components to keep
>>> markmail.org/message/4camcprzximkcftc
>>>
>>> <<assetmaint
>>> ecommerce
>>> example*
>>> pos
>>> maybe myportal?
>>> projectmgr
>>> scrum
>>> and maybe webpos?>>
>>>
>>> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I
>>> suggested to associate people with components
>>> <<project manager (Pierre Smits?)
>>>
>>>      scrum (Hans?)
>>>
>>>      examples and ext (at least me)
>>>
>>>      myportal (French people use portals, not sure for myportal?)
>>>>>
>>> When I look now at my 1st list, obviously I can also support the POS
>>> even if I have less interest in it now.
>>>
>>> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
>>> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
>>> I don't like the etc. ;) but I can agree to add
>>> HHFacility and CMSSITE to my list
>>>
>>> Also in this list birt is missing, clearly at least Chatree has an
>>> interest in it and knows how to maintain it.
>>> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT
>>> but anyway it seems it's worth to keep it.
>>> HHFacility does not need much work to maintain
>>> For CMSSITE I'm unsure, but it's interesting for the online help (too
>>> bad BJ is no longer with us)
>>> BTWcmssite/cms/APACHE_OFBIZ_HTML
>>> <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML> is
>>> no longer working (was still in August in trunk demo) I will investigate
>>> why
>>>
>>>
>>> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
>>> <<A moment I even thought about Attic for some unmaintained components
>>> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
>>> cares?>>
>>>
>>> But this is not a good idea. Obviously we have some responsabilities
>>> with our users.
>>> Now I still wonder about who is really using appserver, ebaystore,
>>> googlebase, googlecheckou, oagis and jetty components...
>>>
>>> This is what I can say so far
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>>
>>> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>>>> It was a long discussion that was done in the public lists and I
>>>> wouldn't
>>>> want to rehash it (you have been part of it for sure): there were
>>>> concerns
>>>> and discussions about duplicated jars, poor quality code, stale code,
>>>> files
>>>> with questionable licenses etc... on the other side there were people
>>>> worried about removing features from the system etc...
>>>> I think it would be better to address each component individually and,
>>>> since you would like to "cope with missing specialpurpose components in
>>>> released packages", this is why I am asking you what are the components
>>>> that should be included in the trunk/release branch/releases.
>>>>
>>>> Jacopo
>>>>
>>>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> I think we need to be sure of what we are doing.
>>>>>
>>>>> 1st question, is why in the 1st place we did that? What pushed us to
>>>>> do so?
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>>>
>>>>>   What is your preference? Would you like to see them all in the
>>>>> release
>>>>>> packages? Some of them only? Which ones?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>   This is the easiest part, I was more thinking about how much is
>>>>>>> downloaded
>>>>>>> by users.
>>>>>>>
>>>>>>> Anyway this was just an idea to help user to cope with missing
>>>>>>> specialpurpose components in released packages.
>>>>>>>
>>>>>>> Now a question comes to my mind, I don't clearly remember the
>>>>>>> reasons we
>>>>>>> decided to remove them. Why keeping them in the releases branches
>>>>>>> but not
>>>>>>> not in released packages is not clear to me.
>>>>>>>
>>>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>>>> w3xw6lipifdeks3z
>>>>>>> Actually we need to clarify 1st which components to keep active in
>>>>>>> release
>>>>>>> branches. For now it seems only ecommerce which is for me too
>>>>>>> restrictive.
>>>>>>> And then discuss about why not doing the same in released packages
>>>>>>> (sorry
>>>>>>> if I missed some arguments here).
>>>>>>> For that we need first to exactly know which components affect which
>>>>>>> ones.
>>>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>>>> component
>>>>>>> to Attic, but this might be discussed also.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>>>
>>>>>>>    That is not difficult to assess. Do a download from trunk, and
>>>>>>> see how
>>>>>>>
>>>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently
>>>>>>>> remove all
>>>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned
>>>>>>>> download
>>>>>>>> and
>>>>>>>> compare the original amount of Mb's with the size of the zip file.
>>>>>>>> That
>>>>>>>> difference is what is saved on storage and transfer cost of trunk
>>>>>>>> code.
>>>>>>>>
>>>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>>>
>>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>>
>>>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>>>
>>>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>>>
>>>>>>>>>   Is it Apache's concern that while people may be free to choose,
>>>>>>>>> ASF
>>>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>>>
>>>>>>>>>> I doubt that OFBiz really puts a big load on the ASF
>>>>>>>>>> infrastructure
>>>>>>>>>> but
>>>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>>>
>>>>>>>>>>   You said it :) At the moment I don't fear any overload on
>>>>>>>>>> the svn
>>>>>>>>> server
>>>>>>>>> from users downloading from releases branches instead of released
>>>>>>>>> packages.
>>>>>>>>> OFBiz is not Tomcat ;)
>>>>>>>>> But I must say I have no measures, so you got a point
>>>>>>>>> until-we/if-we-can
>>>>>>>>> discover that. Because users can already do that, I think it's
>>>>>>>>> fair to
>>>>>>>>> use
>>>>>>>>> this method as long as it's reasonable.
>>>>>>>>> Of course, having that suggested in a TLP project could be viewed
>>>>>>>>> as an
>>>>>>>>> abuse from the Board, but let's be pragmatic, numbers should
>>>>>>>>> tell us
>>>>>>>>> the
>>>>>>>>> truth (if can get them)
>>>>>>>>>
>>>>>>>>>    That may be the practical side of Apache's urging to get the
>>>>>>>>> releases
>>>>>>>>>
>>>>>>>>>> following their guidelines.
>>>>>>>>>>
>>>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For
>>>>>>>>>> OFBiz I
>>>>>>>>> "fear"
>>>>>>>>> it's not a problem. Can we discuss with the board in case,
>>>>>>>>> instead of
>>>>>>>>> hiding behind unknown numbers?
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>    Ron
>>>>>>>>>
>>>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>>>
>>>>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>>>>> servers?
>>>>>>>>>>>>
>>>>>>>>>>>>   I don't try to solve an issue, just to propose an
>>>>>>>>>>>> alternative.
>>>>>>>>>>> It's a
>>>>>>>>>>> free user choice, but with more elements
>>>>>>>>>>>
>>>>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>>>>
>>>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>>>
>>>>>>>>>>>>   Things stay as they are, it's only that we inform our users
>>>>>>>>>>>> than
>>>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>>>> comparison to
>>>>>>>>>>> choice, it's called freedom
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>    Ron
>>>>>>>>>>>
>>>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> For the licence free issues (an other related stuff) we could
>>>>>>>>>>>>> put a
>>>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>>>> explained
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>>>> files
>>>>>>>>>>>>>> thru
>>>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to
>>>>>>>>>>>>>> get the
>>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>>> Officially asking the user to use a release branch would be
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>> trunk but would bring back similar concerns: an official
>>>>>>>>>>>>>> vote is
>>>>>>>>>>>>>> required
>>>>>>>>>>>>>> to publish a product to the outside of the project in
>>>>>>>>>>>>>> order to
>>>>>>>>>>>>>> guarantee
>>>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>>>> And that we could  expose this way of doing in our download
>>>>>>>>>>>>>>> page,
>>>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF.
>>>>>>>>>>>>>>> But we
>>>>>>>>>>>>>>> all know
>>>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>>>> Most of us are actually using this way in their custom
>>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>>> and I have
>>>>>>>>>>>>>>> a feeling it would not only help our users but also us to
>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>
>>>
>>

[Jacopo Cappellato-4]

On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> wrote:

> Do we want to keep all current components (some disabled) until we decide those which should  go to Attic? For instance we already kind of spoke about appserver going to Attic.
> This could be decided before for some components; the less components, the less discussions.  But yes, we can go with separate discussions, or we will see that later...

Whatever you prefer... we can postpone/anticipate or do it in parallel the discussion; however I would like to make very clear that if a component is not good for a release it doesn't necessarily mean it should go to attic; also of a component is disabled it could still be good for a release: these are different concepts.

With this said, in your list please specify:
a) the components that should go to attic
b) the component that should go in a release (and why)

Regards,

Jacopo

[Jacopo Cappellato-4]

On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> wrote:

> Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but probably this one
> 1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
> 2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
> 3) Components to keep enabled. They must be maintained and have no interactions with other components

Components enabled and disabled must be maintained in the same way: it is not that a group is more important than the other.
Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components excluded from a release or vice versa.

>
> For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at the functionality or other levels.

I agree that the same settings should be maintained in the trunk and in the release branches.

Jacopo

[Jacques Le Roux]

Le 27/11/2014 18:41, Jacopo Cappellato a écrit :
> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux<[hidden email]>  wrote:
>
>> >Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but probably this one
>> >1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
>> >2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
>> >3) Components to keep enabled. They must be maintained and have no interactions with other components
> Components enabled and disabled must be maintained in the same way: it is not that a group is more important than the other.
> Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components excluded from a release or vice versa.
>
I agree, I hope things are clear to everybody now

Jacques

[Jacques Le Roux]

Just one thing is not clear to me: still based on OFBiz I guess?

Jacques

Le 27/11/2014 18:33, Adrian Crum a écrit :

> I think the term "separate project" is self-explanatory.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 11/27/2014 5:28 PM, Jacques Le Roux wrote:
>> You mean outside of OFBiz? As a sub-project like suggested Ron? Or in
>> Github or something like that?
>>
>> Jacques
>>
>> Le 27/11/2014 16:31, Adrian Crum a écrit :
>>> I would be willing to spin off Asset Maintenance to a separate
>>> project. I was thinking it could be a good test-run of the concept.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 11/27/2014 2:16 PM, Jacques Le Roux wrote:
>>>> Hi Jacopo,
>>>>
>>>> I looked a bit back. Even if it's not clearly related I trace this back
>>>> to the slim-down effort. We can forget it since nobody never complained
>>>> (pfew...).
>>>>
>>>> Then you proposed to move some component from specialpurpose to extras.
>>>> As you said, not every people were happy with it (at least Pierre and in
>>>> a less measure I)
>>>> I then suggested some components to keep
>>>> markmail.org/message/4camcprzximkcftc
>>>>
>>>> <<assetmaint
>>>> ecommerce
>>>> example*
>>>> pos
>>>> maybe myportal?
>>>> projectmgr
>>>> scrum
>>>> and maybe webpos?>>
>>>>
>>>> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I
>>>> suggested to associate people with components
>>>> <<project manager (Pierre Smits?)
>>>>
>>>>      scrum (Hans?)
>>>>
>>>>      examples and ext (at least me)
>>>>
>>>>      myportal (French people use portals, not sure for myportal?)
>>>>>>
>>>> When I look now at my 1st list, obviously I can also support the POS
>>>> even if I have less interest in it now.
>>>>
>>>> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
>>>> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
>>>> I don't like the etc. ;) but I can agree to add
>>>> HHFacility and CMSSITE to my list
>>>>
>>>> Also in this list birt is missing, clearly at least Chatree has an
>>>> interest in it and knows how to maintain it.
>>>> I don't know if Anil or/and Adrian have still an interest in ASSETMAINT
>>>> but anyway it seems it's worth to keep it.
>>>> HHFacility does not need much work to maintain
>>>> For CMSSITE I'm unsure, but it's interesting for the online help (too
>>>> bad BJ is no longer with us)
>>>> BTWcmssite/cms/APACHE_OFBIZ_HTML
>>>> <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML> is
>>>> no longer working (was still in August in trunk demo) I will investigate
>>>> why
>>>>
>>>>
>>>> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
>>>> <<A moment I even thought about Attic for some unmaintained components
>>>> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
>>>> cares?>>
>>>>
>>>> But this is not a good idea. Obviously we have some responsabilities
>>>> with our users.
>>>> Now I still wonder about who is really using appserver, ebaystore,
>>>> googlebase, googlecheckou, oagis and jetty components...
>>>>
>>>> This is what I can say so far
>>>>
>>>> HTH
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>>>>> It was a long discussion that was done in the public lists and I
>>>>> wouldn't
>>>>> want to rehash it (you have been part of it for sure): there were
>>>>> concerns
>>>>> and discussions about duplicated jars, poor quality code, stale code,
>>>>> files
>>>>> with questionable licenses etc... on the other side there were people
>>>>> worried about removing features from the system etc...
>>>>> I think it would be better to address each component individually and,
>>>>> since you would like to "cope with missing specialpurpose components in
>>>>> released packages", this is why I am asking you what are the components
>>>>> that should be included in the trunk/release branch/releases.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> I think we need to be sure of what we are doing.
>>>>>>
>>>>>> 1st question, is why in the 1st place we did that? What pushed us to
>>>>>> do so?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>>>>
>>>>>>   What is your preference? Would you like to see them all in the
>>>>>> release
>>>>>>> packages? Some of them only? Which ones?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>   This is the easiest part, I was more thinking about how much is
>>>>>>>> downloaded
>>>>>>>> by users.
>>>>>>>>
>>>>>>>> Anyway this was just an idea to help user to cope with missing
>>>>>>>> specialpurpose components in released packages.
>>>>>>>>
>>>>>>>> Now a question comes to my mind, I don't clearly remember the
>>>>>>>> reasons we
>>>>>>>> decided to remove them. Why keeping them in the releases branches
>>>>>>>> but not
>>>>>>>> not in released packages is not clear to me.
>>>>>>>>
>>>>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>>>>> w3xw6lipifdeks3z
>>>>>>>> Actually we need to clarify 1st which components to keep active in
>>>>>>>> release
>>>>>>>> branches. For now it seems only ecommerce which is for me too
>>>>>>>> restrictive.
>>>>>>>> And then discuss about why not doing the same in released packages
>>>>>>>> (sorry
>>>>>>>> if I missed some arguments here).
>>>>>>>> For that we need first to exactly know which components affect which
>>>>>>>> ones.
>>>>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>>>>> component
>>>>>>>> to Attic, but this might be discussed also.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>>>>
>>>>>>>>    That is not difficult to assess. Do a download from trunk, and
>>>>>>>> see how
>>>>>>>>
>>>>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently
>>>>>>>>> remove all
>>>>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned
>>>>>>>>> download
>>>>>>>>> and
>>>>>>>>> compare the original amount of Mb's with the size of the zip file.
>>>>>>>>> That
>>>>>>>>> difference is what is saved on storage and transfer cost of trunk
>>>>>>>>> code.
>>>>>>>>>
>>>>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>>>>
>>>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>>>
>>>>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>>>>
>>>>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>>>>
>>>>>>>>>>   Is it Apache's concern that while people may be free to choose,
>>>>>>>>>> ASF
>>>>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>>>>
>>>>>>>>>>> I doubt that OFBiz really puts a big load on the ASF
>>>>>>>>>>> infrastructure
>>>>>>>>>>> but
>>>>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>>>>
>>>>>>>>>>>   You said it :) At the moment I don't fear any overload on
>>>>>>>>>>> the svn
>>>>>>>>>> server
>>>>>>>>>> from users downloading from releases branches instead of released
>>>>>>>>>> packages.
>>>>>>>>>> OFBiz is not Tomcat ;)
>>>>>>>>>> But I must say I have no measures, so you got a point
>>>>>>>>>> until-we/if-we-can
>>>>>>>>>> discover that. Because users can already do that, I think it's
>>>>>>>>>> fair to
>>>>>>>>>> use
>>>>>>>>>> this method as long as it's reasonable.
>>>>>>>>>> Of course, having that suggested in a TLP project could be viewed
>>>>>>>>>> as an
>>>>>>>>>> abuse from the Board, but let's be pragmatic, numbers should
>>>>>>>>>> tell us
>>>>>>>>>> the
>>>>>>>>>> truth (if can get them)
>>>>>>>>>>
>>>>>>>>>>    That may be the practical side of Apache's urging to get the
>>>>>>>>>> releases
>>>>>>>>>>
>>>>>>>>>>> following their guidelines.
>>>>>>>>>>>
>>>>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For
>>>>>>>>>>> OFBiz I
>>>>>>>>>> "fear"
>>>>>>>>>> it's not a problem. Can we discuss with the board in case,
>>>>>>>>>> instead of
>>>>>>>>>> hiding behind unknown numbers?
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>    Ron
>>>>>>>>>>
>>>>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>   Does this solve ASF's issue about having users access the main
>>>>>>>>>>>>> servers?
>>>>>>>>>>>>>
>>>>>>>>>>>>>   I don't try to solve an issue, just to propose an
>>>>>>>>>>>>> alternative.
>>>>>>>>>>>> It's a
>>>>>>>>>>>> free user choice, but with more elements
>>>>>>>>>>>>
>>>>>>>>>>>>    What do you put on the mirrors and how do you stop users from
>>>>>>>>>>>>
>>>>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Things stay as they are, it's only that we inform our users
>>>>>>>>>>>>> than
>>>>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>>>>> comparison to
>>>>>>>>>>>> choice, it's called freedom
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>    Ron
>>>>>>>>>>>>
>>>>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the licence free issues (an other related stuff) we could
>>>>>>>>>>>>>> put a
>>>>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>>>>> explained
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix the
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> strategy of the project by providing officially voted release
>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>> thru
>>>>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to
>>>>>>>>>>>>>>> get the
>>>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>>>> Officially asking the user to use a release branch would be
>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>> trunk but would bring back similar concerns: an official
>>>>>>>>>>>>>>> vote is
>>>>>>>>>>>>>>> required
>>>>>>>>>>>>>>> to publish a product to the outside of the project in
>>>>>>>>>>>>>>> order to
>>>>>>>>>>>>>>> guarantee
>>>>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>>>>> suggested we could propose our users to use a release branch
>>>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>>>>> And that we could  expose this way of doing in our download
>>>>>>>>>>>>>>>> page,
>>>>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>>>>> better with a link to an explaining page (in details) in the
>>>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF.
>>>>>>>>>>>>>>>> But we
>>>>>>>>>>>>>>>> all know
>>>>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>>>>> Most of us are actually using this way in their custom
>>>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>>>> and I have
>>>>>>>>>>>>>>>> a feeling it would not only help our users but also us to
>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>
>>>>
>>>
>

[Adrian Crum-3]

Yes, of course.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 11/27/2014 5:54 PM, Jacques Le Roux wrote:

> Just one thing is not clear to me: still based on OFBiz I guess?
>
> Jacques
>
> Le 27/11/2014 18:33, Adrian Crum a écrit :
>> I think the term "separate project" is self-explanatory.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 11/27/2014 5:28 PM, Jacques Le Roux wrote:
>>> You mean outside of OFBiz? As a sub-project like suggested Ron? Or in
>>> Github or something like that?
>>>
>>> Jacques
>>>
>>> Le 27/11/2014 16:31, Adrian Crum a écrit :
>>>> I would be willing to spin off Asset Maintenance to a separate
>>>> project. I was thinking it could be a good test-run of the concept.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 11/27/2014 2:16 PM, Jacques Le Roux wrote:
>>>>> Hi Jacopo,
>>>>>
>>>>> I looked a bit back. Even if it's not clearly related I trace this
>>>>> back
>>>>> to the slim-down effort. We can forget it since nobody never
>>>>> complained
>>>>> (pfew...).
>>>>>
>>>>> Then you proposed to move some component from specialpurpose to
>>>>> extras.
>>>>> As you said, not every people were happy with it (at least Pierre
>>>>> and in
>>>>> a less measure I)
>>>>> I then suggested some components to keep
>>>>> markmail.org/message/4camcprzximkcftc
>>>>>
>>>>> <<assetmaint
>>>>> ecommerce
>>>>> example*
>>>>> pos
>>>>> maybe myportal?
>>>>> projectmgr
>>>>> scrum
>>>>> and maybe webpos?>>
>>>>>
>>>>> In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I
>>>>> suggested to associate people with components
>>>>> <<project manager (Pierre Smits?)
>>>>>
>>>>>      scrum (Hans?)
>>>>>
>>>>>      examples and ext (at least me)
>>>>>
>>>>>      myportal (French people use portals, not sure for myportal?)
>>>>>>>
>>>>> When I look now at my 1st list, obviously I can also support the POS
>>>>> even if I have less interest in it now.
>>>>>
>>>>> Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
>>>>> HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
>>>>> I don't like the etc. ;) but I can agree to add
>>>>> HHFacility and CMSSITE to my list
>>>>>
>>>>> Also in this list birt is missing, clearly at least Chatree has an
>>>>> interest in it and knows how to maintain it.
>>>>> I don't know if Anil or/and Adrian have still an interest in
>>>>> ASSETMAINT
>>>>> but anyway it seems it's worth to keep it.
>>>>> HHFacility does not need much work to maintain
>>>>> For CMSSITE I'm unsure, but it's interesting for the online help (too
>>>>> bad BJ is no longer with us)
>>>>> BTWcmssite/cms/APACHE_OFBIZ_HTML
>>>>> <https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML> is
>>>>> no longer working (was still in August in trunk demo) I will
>>>>> investigate
>>>>> why
>>>>>
>>>>>
>>>>> At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
>>>>> <<A moment I even thought about Attic for some unmaintained components
>>>>> (ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
>>>>> cares?>>
>>>>>
>>>>> But this is not a good idea. Obviously we have some responsabilities
>>>>> with our users.
>>>>> Now I still wonder about who is really using appserver, ebaystore,
>>>>> googlebase, googlecheckou, oagis and jetty components...
>>>>>
>>>>> This is what I can say so far
>>>>>
>>>>> HTH
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
>>>>>> It was a long discussion that was done in the public lists and I
>>>>>> wouldn't
>>>>>> want to rehash it (you have been part of it for sure): there were
>>>>>> concerns
>>>>>> and discussions about duplicated jars, poor quality code, stale code,
>>>>>> files
>>>>>> with questionable licenses etc... on the other side there were people
>>>>>> worried about removing features from the system etc...
>>>>>> I think it would be better to address each component individually
>>>>>> and,
>>>>>> since you would like to "cope with missing specialpurpose
>>>>>> components in
>>>>>> released packages", this is why I am asking you what are the
>>>>>> components
>>>>>> that should be included in the trunk/release branch/releases.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> I think we need to be sure of what we are doing.
>>>>>>>
>>>>>>> 1st question, is why in the 1st place we did that? What pushed us to
>>>>>>> do so?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
>>>>>>>
>>>>>>>   What is your preference? Would you like to see them all in the
>>>>>>> release
>>>>>>>> packages? Some of them only? Which ones?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>>   This is the easiest part, I was more thinking about how much is
>>>>>>>>> downloaded
>>>>>>>>> by users.
>>>>>>>>>
>>>>>>>>> Anyway this was just an idea to help user to cope with missing
>>>>>>>>> specialpurpose components in released packages.
>>>>>>>>>
>>>>>>>>> Now a question comes to my mind, I don't clearly remember the
>>>>>>>>> reasons we
>>>>>>>>> decided to remove them. Why keeping them in the releases branches
>>>>>>>>> but not
>>>>>>>>> not in released packages is not clear to me.
>>>>>>>>>
>>>>>>>>> I believe Jacopo kind of answered  at http://markmail.org/message/
>>>>>>>>> w3xw6lipifdeks3z
>>>>>>>>> Actually we need to clarify 1st which components to keep active in
>>>>>>>>> release
>>>>>>>>> branches. For now it seems only ecommerce which is for me too
>>>>>>>>> restrictive.
>>>>>>>>> And then discuss about why not doing the same in released packages
>>>>>>>>> (sorry
>>>>>>>>> if I missed some arguments here).
>>>>>>>>> For that we need first to exactly know which components affect
>>>>>>>>> which
>>>>>>>>> ones.
>>>>>>>>> I believe at this stage we don't want to send any specialpurpose
>>>>>>>>> component
>>>>>>>>> to Attic, but this might be discussed also.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 13/11/2014 22:51, Pierre Smits a écrit :
>>>>>>>>>
>>>>>>>>>    That is not difficult to assess. Do a download from trunk, and
>>>>>>>>> see how
>>>>>>>>>
>>>>>>>>>> many Mb's are transferred. Do a ./ant clean-all. Subsequently
>>>>>>>>>> remove all
>>>>>>>>>> hidden files in .svn folders. Finally do a zip of the cleaned
>>>>>>>>>> download
>>>>>>>>>> and
>>>>>>>>>> compare the original amount of Mb's with the size of the zip
>>>>>>>>>> file.
>>>>>>>>>> That
>>>>>>>>>> difference is what is saved on storage and transfer cost of trunk
>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> Now multiply that with the number of branches you had in mind.
>>>>>>>>>>
>>>>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>>>>
>>>>>>>>>>    Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
>>>>>>>>>>
>>>>>>>>>>> [hidden email]> het volgende geschreven:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>>>>>>>>>
>>>>>>>>>>>   Is it Apache's concern that while people may be free to
>>>>>>>>>>> choose,
>>>>>>>>>>> ASF
>>>>>>>>>>>> server capacity is not free nor unlimited?
>>>>>>>>>>>>
>>>>>>>>>>>> I doubt that OFBiz really puts a big load on the ASF
>>>>>>>>>>>> infrastructure
>>>>>>>>>>>> but
>>>>>>>>>>>> users are not supposed to be downloading from the SVN.
>>>>>>>>>>>> They are supposed to get downloads from local mirrors.
>>>>>>>>>>>>
>>>>>>>>>>>>   You said it :) At the moment I don't fear any overload on
>>>>>>>>>>>> the svn
>>>>>>>>>>> server
>>>>>>>>>>> from users downloading from releases branches instead of
>>>>>>>>>>> released
>>>>>>>>>>> packages.
>>>>>>>>>>> OFBiz is not Tomcat ;)
>>>>>>>>>>> But I must say I have no measures, so you got a point
>>>>>>>>>>> until-we/if-we-can
>>>>>>>>>>> discover that. Because users can already do that, I think it's
>>>>>>>>>>> fair to
>>>>>>>>>>> use
>>>>>>>>>>> this method as long as it's reasonable.
>>>>>>>>>>> Of course, having that suggested in a TLP project could be
>>>>>>>>>>> viewed
>>>>>>>>>>> as an
>>>>>>>>>>> abuse from the Board, but let's be pragmatic, numbers should
>>>>>>>>>>> tell us
>>>>>>>>>>> the
>>>>>>>>>>> truth (if can get them)
>>>>>>>>>>>
>>>>>>>>>>>    That may be the practical side of Apache's urging to get the
>>>>>>>>>>> releases
>>>>>>>>>>>
>>>>>>>>>>>> following their guidelines.
>>>>>>>>>>>>
>>>>>>>>>>>>   Yes for Tomcat, HTTPD or such that's understandable. For
>>>>>>>>>>>> OFBiz I
>>>>>>>>>>> "fear"
>>>>>>>>>>> it's not a problem. Can we discuss with the board in case,
>>>>>>>>>>> instead of
>>>>>>>>>>> hiding behind unknown numbers?
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>    Ron
>>>>>>>>>>>
>>>>>>>>>>>>    On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Does this solve ASF's issue about having users access the
>>>>>>>>>>>>> main
>>>>>>>>>>>>>> servers?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   I don't try to solve an issue, just to propose an
>>>>>>>>>>>>>> alternative.
>>>>>>>>>>>>> It's a
>>>>>>>>>>>>> free user choice, but with more elements
>>>>>>>>>>>>>
>>>>>>>>>>>>>    What do you put on the mirrors and how do you stop users
>>>>>>>>>>>>> from
>>>>>>>>>>>>>
>>>>>>>>>>>>>> accessing the development SVN which is ASF's concern?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Things stay as they are, it's only that we inform our users
>>>>>>>>>>>>>> than
>>>>>>>>>>>>> another way is possible and we give them enough elements of
>>>>>>>>>>>>> comparison to
>>>>>>>>>>>>> choice, it's called freedom
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Ron
>>>>>>>>>>>>>
>>>>>>>>>>>>>>    On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the licence free issues (an other related stuff) we
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>> put a
>>>>>>>>>>>>>>> disclaimer in the wiki page where all alternatives would be
>>>>>>>>>>>>>>> explained
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   In the past the ASF Board asked to the OFBiz PMC to fix
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> strategy of the project by providing officially voted
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>> thru
>>>>>>>>>>>>>>>> the ASF mirrors: at that time we were pushing the users to
>>>>>>>>>>>>>>>> get the
>>>>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>>>>> Officially asking the user to use a release branch would be
>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>>> trunk but would bring back similar concerns: an official
>>>>>>>>>>>>>>>> vote is
>>>>>>>>>>>>>>>> required
>>>>>>>>>>>>>>>> to publish a product to the outside of the project in
>>>>>>>>>>>>>>>> order to
>>>>>>>>>>>>>>>> guarantee
>>>>>>>>>>>>>>>> License free issues etc...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In a recent user ML threadhttp://markmail.org/
>>>>>>>>>>>>>>>>> message/ivjocjr2ull7lwqe  I
>>>>>>>>>>>>>>>>> suggested we could propose our users to use a release
>>>>>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>>>>> rather than downloaded packages.
>>>>>>>>>>>>>>>>> And that we could  expose this way of doing in our
>>>>>>>>>>>>>>>>> download
>>>>>>>>>>>>>>>>> page,
>>>>>>>>>>>>>>>>> or maybe
>>>>>>>>>>>>>>>>> better with a link to an explaining page (in details)
>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I know it's not the recommended way of doing at the ASF.
>>>>>>>>>>>>>>>>> But we
>>>>>>>>>>>>>>>>> all know
>>>>>>>>>>>>>>>>> the OFBiz differences when compared with other TLPs which
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> mostly libs,
>>>>>>>>>>>>>>>>> and even mostly jars.
>>>>>>>>>>>>>>>>> Most of us are actually using this way in their custom
>>>>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>>>>> and I have
>>>>>>>>>>>>>>>>> a feeling it would not only help our users but also us to
>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>
>>>>>
>>>>
>>

[Adrian Crum-3]

Be aware that disabling a component does two things:

1. Speeds up unit tests because the disabled component is excluded from
them.
2. Increases the chance of regressions because the disabled component is
not being tested.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:

>
> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but probably this one
>> 1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
>> 2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
>> 3) Components to keep enabled. They must be maintained and have no interactions with other components
>
> Components enabled and disabled must be maintained in the same way: it is not that a group is more important than the other.
> Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components excluded from a release or vice versa.
>
>>
>> For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at the functionality or other levels.
>
> I agree that the same settings should be maintained in the trunk and in the release branches.
>
> Jacopo
>

[Jacopo Cappellato-4]

This is a good point. We could find a way to programmatically enable/disable the components just for the test run:

./ant -Denable-all=true clean-all load-demo run-tests

but this is just an idea; we could figure out the best way to go.

Jacopo


On Nov 27, 2014, at 7:14 PM, Adrian Crum <[hidden email]> wrote:

> Be aware that disabling a component does two things:
>
> 1. Speeds up unit tests because the disabled component is excluded from them.
> 2. Increases the chance of regressions because the disabled component is not being tested.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>
>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> wrote:
>>
>>> Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but probably this one
>>> 1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
>>> 2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
>>> 3) Components to keep enabled. They must be maintained and have no interactions with other components
>>
>> Components enabled and disabled must be maintained in the same way: it is not that a group is more important than the other.
>> Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components excluded from a release or vice versa.
>>
>>>
>>> For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at the functionality or other levels.
>>
>> I agree that the same settings should be maintained in the trunk and in the release branches.
>>
>> Jacopo
>>

[Ron Wheeler]

In an ideal world (according to me),
- we should follow the Apache models or precedents since they seem to
work for a large number of Apache projects.
- the individual projects would have their own committers who may or may
not commit to the core or framework. Perhaps someone can look into how
Apache handles access control to source repos when there are sub-projects.
- the sub-project would release their new versions separately from the
framework and core with a warranty that it works with the versions of
the core and framework which the sub-project has tested. The core and
framework team would not be responsible for testing or warrantying the
sub-projects. This does not mean that they should be reckless in
removing supported features without asking the sub-projects for comments
or being flexible about regressing changes that affect other projects.
Once a new version of the core and framework are released, it would be
up to the sub-projects to support it. This may slow adoption of new core
and framework releases but the users can support the sub-projects that
they need if they can't stand the wait. At least the core and framework
can get released without waiting for each sub-project to be updated and
tested.
- the core and framework projects should look for ways to clearly define
the API or interface points that the sub-projects should use.
- the core and framework team(s) would receive requests (JIRA issues)
from the sub-project for required changes that the sub-projects need to
advance their modules and make the changes in a release that would
permit the module to add the features. Having people who work on the
framework, the core and the sub-project is going to give some projects a
stronger position but "c'est la vie". This may be an incentive for new
people to take an active interest in maintaining some parts of the core
or framework for which  they spend a lot of time writing JIRA issues.
- the sub-project would make its own roadmap and maintain its own
section(s) in the wiki.
- sub-projects would manage their own meritocracies that might have a
completely different criteria that the current group (someone who is a
strong player in the project management community - lecturer, author,
consultant with no programming skills could be a very important
contributor but you would not value them highly in the framework or
core. ). Realistically, as we see from the current discussion, the
initial thought leaders are going to come from the people who built
these things in the first place.

This would simplify the work of the core and framework team and allow
them to release more frequently and to focus on the central tasks
without having to worry about all the modules.
It will also allow each of these sub-projects to "market" their projects
with more certainty and more focus.


Ron


On 27/11/2014 1:41 PM, Jacopo Cappellato wrote:

> This is a good point. We could find a way to programmatically enable/disable the components just for the test run:
>
> ./ant -Denable-all=true clean-all load-demo run-tests
>
> but this is just an idea; we could figure out the best way to go.
>
> Jacopo
>
>
> On Nov 27, 2014, at 7:14 PM, Adrian Crum <[hidden email]> wrote:
>
>> Be aware that disabling a component does two things:
>>
>> 1. Speeds up unit tests because the disabled component is excluded from them.
>> 2. Increases the chance of regressions because the disabled component is not being tested.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> wrote:
>>>
>>>> Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but probably this one
>>>> 1) Components to move to Attic. They will be freezed but still available in this state in Attic (in other words slowly dying)
>>>> 2) Components to disable. They will be maintained, but OOTB will not interfere with other components (applications or other specialpurpose)
>>>> 3) Components to keep enabled. They must be maintained and have no interactions with other components
>>> Components enabled and disabled must be maintained in the same way: it is not that a group is more important than the other.
>>> Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components excluded from a release or vice versa.
>>>
>>>> For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at the functionality or other levels.
>>> I agree that the same settings should be maintained in the trunk and in the release branches.
>>>
>>> Jacopo
>>>
>

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