Looks promising Olivier,
Looking forward
Jacques
From: "Olivier Heintz"
All you proposed sound good to me.
Since first discussion about "Lose Weight Program for OFBiz" we (the company I am working for) have continue to work on addon
definition, rule, goal.
In my current plan, I am 3 week l
So the concerns, as I read the thread, is review of code for release
needs to be minimized.
Instead of shrinking the SVN Image, I present the following.
1) expand the tests to verify each component/folder. This would reduce
release review.
2) expand the ant script or create seperate one for Dist
All you proposed sound good to me.
Since first discussion about "Lose Weight Program for OFBiz" we (the
company I am working for) have continue to work on addon definition,
rule, goal.
In my current plan, I am 3 week late, but this week (or next one ) I
should create in apache-extra some proje
2012/7/10 Jacopo Cappellato
>
> The idea is to not include the specialpurpose folder from future releases:
> 13.04, 14.04 etc...
>
>
> -1
It is difficult to groups components in this way because it is based on your
personal experience (mine would be completely different, for example).
The fact that they are not part of the future "OFBiz releases" doesn't mean
that they will not be used, in fact they can be downloaded separately.
J
On Jul 9, 2012, at 10:28 PM, Jacques Le Roux wrote:
> Ha, I forgot about the release aspect of the discussion. I agree, to have
> less burden on committers shoulders when releasing, we could put the
> specialpurpose folder out of releases branches. But then I wonder how they
> will be maintain
Ha, I forgot about the release aspect of the discussion. I agree, to have less burden on committers shoulders when releasing, we
could put the specialpurpose folder out of releases branches. But then I wonder how they will be maintained in future. This is what
is worrying me a bit: releases will
I have nothing against these ideas. It seems to me though that some applications currently in specialpurpose are more used and/or
have a larger scope than some others.
Roughly said I see 2 kinds of components there:
"1st class citizens" would be
assetmaint
ecommerce
example*
pos
maybe myportal?
Yes, this could be the easiest way to implement it.
And if and when we will release the "specialpurpose" applications we could
simply create a tag (if we do not plan to backport fixes for "specialpurpose"
releases) or we could create a release branch specific for "specialpurpose" (if
we do not w
So, we would remove the specialpurpose folder from the release branch?
That sounds fine to me.
-Adrian
On 7/9/2012 1:55 PM, Jacopo Cappellato wrote:
Adrian,
all you proposed sounds good to me, I like it.
What about the idea of not including specialpurpose in the releases? I think it
is impor
Adrian,
all you proposed sounds good to me, I like it.
What about the idea of not including specialpurpose in the releases? I think it
is important because it simplifies the task of reviewing the code that we
officially publish when we do a release; releasing separately will help to
focus on a
I like the general direction, but I think the steps are overly
complicated. I would prefer to keep the specialpurpose folder name, and
keep its components in the build scripts and test runs. This is
important because higher level component tests can reveal problems in
the core logic (those test
A few months ago we discussed about moving out of OFBiz some components from
framework and specialpurpose and introduce the concept of "OFBiz Extras"
projects, managed out of the ASF infrastructure.
I still think it is a good way to go, especially because it will help to grow
an ecosystem of pro
13 matches
Mail list logo
