While working with Jinghai on https://issues.apache.org/jira/browse/OFBIZ-6659
I got an idea.
We tried to remove all special purpose components but ecommerce in R13.07. We can't say it was a success, because some users complained they could not
find the component they were looking for (POS or
Afterthought: we agreed about having the same setting in both the releases branches and the trunk. So if we disable a component in the releases
branches it will be also in the trunk.
Then, even we enable tests, we will not be aware of UI related issues and globally all those which are no covered
On Nov 28, 2014, at 11:24 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
Also if you remember this thread started with my idea of creating a wiki page
to explain to our users the alternative strategy of using release branches
rather than released packages.
I'd like to have a
Hello all !
I followed the discussion, a bit late :
Le 28/11/2014 11:24, Jacques Le Roux a écrit :
Afterthought: we agreed about having the same setting in both the
releases branches and the trunk. So if we disable a component in the
releases branches it will be also in the trunk.
Then, even
What is the downside if the non-core components are released on their
own with a clear set of documentation that describes the state of the
component?
My feeling is that it is better to release a clean core and framework
where ALL component are warranteed by the team to be tested and
What is the effect of this strategy on the implied warranty?
What is guaranteed to be tested?
Where will the test results for the release be available?
What is the responsibility of someone who changes the release branch
after it is released in terms of testing, support and documentation?
Is
First I might be a bit confuse in this email, sorry for that, quite
ideas came up while writing it, some organization missing.
Le 28/11/2014 14:31, Ron Wheeler a écrit :
What is the downside if the non-core components are released on their
own with a clear set of documentation that describes
The components not supported as part of the core and framework would not
leave Apache.
They become separate sub-projects under OFBiz so that they stay in the
community but are released and supported separately so that there is
more transparency about their state.
The release of new core and
Oh, sorry i did miss a big point :)
I miss-interpreted Adrian proposal on seperate project, not enough
self-explanatory for me I guess :).
Gil
Le 28/11/2014 17:01, Ron Wheeler a écrit :
The components not supported as part of the core and framework would
not leave Apache.
They become
Can someone on the PMC or a current committer find out what has to be
done to set up an Apacahe sub-project in terms of administration (might
be nothing) and fixing the SCM access so that committers to the
sub-project are not required to be committers to the core and framework.
This may not be
As has been discussed in this thread, we can spin off special purpose
components to their own projects - where they can form their own
communities and support structure.
I am willing to use the Asset Maintenance component as a trial run. Here
are some of my initial thoughts, comments are
NP.
This is a new idea for OfBiz.
Some Apache examples
http://db.apache.org/ where Derby is a sub-project with some others.
http://xmlgraphics.apache.org/ is an example where the skill sets and
interests of the sub-projects are very different from the core
http://portals.apache.org/ is more of
I agree with Jacopo that OFBiz sub-projects will be nearly impossible to
maintain. That is why I suggested moving special purpose components to
separate projects.
I am willing to move one component to a separate project as a trial run.
I have no interest in being a chair of a sub-PMC.
On 28/11/2014 11:23 AM, Adrian Crum wrote:
I agree with Jacopo that OFBiz sub-projects will be nearly impossible
to maintain. That is why I suggested moving special purpose components
to separate projects.
Apache sub-projects seem to be very easy to maintain for other projects.
Perhaps we
On 28/11/2014 11:23 AM, Adrian Crum wrote:
I agree with Jacopo that OFBiz sub-projects will be nearly impossible
to maintain. That is why I suggested moving special purpose components
to separate projects.
I am willing to move one component to a separate project as a trial
run. I have no
This conversation has stopped making any sense.
The special purpose components are removed from releases because we
don't have enough resources to maintain them. Now there is interest in
putting them back, but we STILL don't have the resources to maintain
them. A suggestion was made to make
Hi Adrian and everyone,
I think this issue was discussed in multiple threads before. There seems to
be a general agreement that resources are low. The question is then why
sub-projects or forks or spinoffs? Why not just keep specialpurpose in the
project? It's live functioning code even if not
!) Sub-projects allow worthwhile projects to find new supporters through
better transparency, focused mission and clearer borders around the
knowledge needed to contribute.
2) I thought that Adrian was suggesting that Asset Management was an
effort that he would support
3) Just when people
Ron, we get that you really like the idea of sub-projects. The only
positive I can see about a sub-project is that the component gets to
stick with the Apache brand/trademark, I'm pretty sure that's the only
positive I've seen you mention that doesn't also apply to an external
project. With the
On 28/11/2014 5:49 PM, Scott Gray wrote:
Ron, we get that you really like the idea of sub-projects. The only
positive I can see about a sub-project is that the component gets to
stick with the Apache brand/trademark, I'm pretty sure that's the only
positive I've seen you mention that doesn't
A few responses below but all I really have left to say is that if Adrian
or anyone else wants to take a fork of any special purpose component and
maintain it outside of the OFBiz project then I'm all for it. Assuming
those forks made good progress on improving the component then I'd also be
in
On 28/11/2014 7:06 PM, Scott Gray wrote:
A few responses below but all I really have left to say is that if Adrian
or anyone else wants to take a fork of any special purpose component and
maintain it outside of the OFBiz project then I'm all for it. Assuming
those forks made good progress on
Hi Adrian,
Sounds like a good plan to me. I think there should probably be some sort
of a delay in step #5 and it should ultimately be decided by a PMC vote at
that point in time as well. I totally support the concept though.
Regards
Scott
On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum
On Nov 29, 2014, at 12:09 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:
Can the Apache project abandon a component if someone says that they will
make a private fork?
Everyone can start a new open (or closed) source project forking a component
from OFBiz: it doesn't require any
On Nov 28, 2014, at 5:20 PM, Adrian Crum adrian.c...@sandglass-software.com
wrote:
1. Check with the ASF legal department before doing anything.
You can do step #1 without any approval from the ASF or the OFBiz project.
2. Create a project on a popular hosting site (like SourceForge, but it
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
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
On Nov 27, 2014, at 3:16 PM, Jacques Le Roux jacques.le.r...@les7arts.com
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
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
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
Le 27/11/2014 16:30, Jacopo Cappellato a écrit :
On Nov 27, 2014, at 3:16 PM, Jacques Le Roux jacques.le.r...@les7arts.com
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
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,
On Nov 27, 2014, at 6:25 PM, Jacques Le Roux jacques.le.r...@les7arts.com
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
On Nov 27, 2014, at 6:25 PM, Jacques Le Roux jacques.le.r...@les7arts.com
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
Le 27/11/2014 18:41, Jacopo Cappellato a écrit :
On Nov 27, 2014, at 6:25 PM, Jacques Le Rouxjacques.le.r...@les7arts.com
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
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
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.
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
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
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
That sounds like a good enough solution to me
Jacques
Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
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
Sounds like a good idea.
What do you need from Sharan and I in terms of documentation support and
space in the wiki for project management, functional documentation and
marketing/promotional details.
Any suggestions about wiki structure for this as a separate sub-project?
Ron
On 27/11/2014
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:
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
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.
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
jacques.le.r...@les7arts.com wrote:
This is the easiest part, I was more thinking about how much is downloaded
by users.
Anyway
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?
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
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
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
You'll be the first?
Verstuurd vanaf mijn iPad
Op 14 nov. 2014 om 14:26 heeft Ron Wheeler rwhee...@artifact-software.com
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
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 rwhee...@artifact-software.com het
volgende
Hi,
In a recent user ML thread http://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
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
We are talking about components (applications) that are good and nobody
complains about. Code that is being used by our users. Code that is being
evaluated and contributors work on to improve it. And this is left out of
releases? Crazy
If that were to be the policy, we could also start to
Jacopo, Pierre,
I did not speak about forcing users, just suggesting and explaining why. Then
their choice, which is available anyway, but maybe hidden for some...
Jacques
Le 13/11/2014 13:44, Pierre Smits a écrit :
We are talking about components (applications) that are good and nobody
That last sentence should have been: And not by forcing an implementation
methodology upon us that doesn't have the consensus of the community, that
leads to more misunderstanding (within the user part of the community) and
more work for the rest.
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
As an outsider, I can see what is bothering the ASF.
The voting out process is Apache's way of ensuring that the PMC and
contributors are putting their stamp of approval on the release.
It is the last chance to raise an objection about some bug/deficiency
before you put the warranty on the
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
Does this solve ASF's issue about having users access the main servers?
What do you put on the mirrors and how do you stop users from accessing
the development SVN which is ASF's concern?
Ron
On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
For the licence free issues (an other related stuff)
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
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
As I already have explained in
https://issues.apache.org/jira/browse/OFBIZ-5464, in the first quarter of
this year, a release could even be more compact.
Regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail
63 matches
Mail list logo
