Clearly I'm feeling some guilt about not helping with releases. :-D
Thanks for clarifying.
- "Jacopo Cappellato" wrote:
> I was actually referring to Hans, because I was surprised that he was trying
> to influence the way we were preparing our release after he clearly mentioned
> in sev
Ean,
I was actually referring to Hans, because I was surprised that he was trying to
influence the way we were preparing our release after he clearly mentioned in
several occasions that he was not interested in releases... but the discussion
is now resolved after we realized there was a misunde
Hi Jacopo,
Good to hear the background reason of the slimdown activity. First of
all we are member of the Apache foundation and we should follow its
general directions and policies.
Now with the branch of 13.05 only general accepted production code will
be included which is the first release
Ah ok, yes, here we are only talking about the upcoming new release branch
13.05, not the trunk... we are in a good spot then.
Jacopo
On Apr 25, 2013, at 10:01 AM, Hans Bakker wrote:
> Hi Jacopo,
>
> I was not aware, that the changes only affect the release and in the trunk
> these component
Hi Jacopo,
I was not aware, that the changes only affect the release and in the
trunk these components are still active. If that is the case, it is fine
with me.
Regards,
Hans
On 04/25/2013 01:13 PM, Jacopo Cappellato wrote:
On Apr 24, 2013, at 6:47 PM, Hans Bakker wrote:
If you think, t
Looks like a good approach indeed. Could this be contributed?
For the rest, I simply agree with Jacopo.
Jacques
From: "Adrian Crum"
> The approach we take at 1Tech Ltd is to enable easy third-party
> reporting tools integration - via database meta-data. Unless the client
> has no infrastructu
- "Jacopo Cappellato" wrote:
> please also consider that who is pushing to keep this component in the
> release until now has shown zero interest in releases and did not help the
> community to maintain them or publish them or respond to vulnerability
> reports.
I stand suitably chastised
On Apr 24, 2013, at 6:47 PM, Hans Bakker wrote:
> If you think, that it is not good enough, feel free to improve it what should
> be the goal of our community and not order me to solve the problems you seem
> to have with this part of the system
I am not ordering you to do the job.
As regards
On Apr 24, 2013, at 7:03 PM, Ean Schuessler wrote:
> I do have issues with the way BIRT is integrated (which I can elaborate
> separately).
Here the problem is that the ASF asks us to publish in releases only high
quality and production code.
We can say that the current implementation of the b
The approach we take at 1Tech Ltd is to enable easy third-party
reporting tools integration - via database meta-data. Unless the client
has no infrastructure whatsoever, they usually prefer to use their
existing reporting tool with OFBiz, and exposing database meta-data
makes that easy.
We co
I have to concur that the reporting feature feels "core" to me for business
users. BIRT seems to be the most widely accepted standard since Jasper has gone
"freemium" and BI seems like a huge selling point for us if we get it right.
I do have issues with the way BIRT is integrated (which I ca
Jacopo,
For me is the BI, Eclipse and help system essential for the operation of
our system and that of our customers. For me there are no bocking
problems and this part is working fine.
If you think, that it is not good enough, feel free to improve it what
should be the goal of our communit
A good start would be fixing the many issues that are affecting the component
and its report make it unreliable in production (and in releases). I mentioned
them several times and you didn't take any action.
Also, that component was added (by you) to the project following the
commit-than-review
Jacopo,
As was discussed often before, we at least now have a standard reporting
system included in the system which was moved from the framework without
my agreement. I think this is an essential part of an ERP system and a
framework component.
So does it matter that I, as a PMC member with
It sounds like a plan; we will postpone the decision of a few weeks and we will
probably create the new branch 13.05 in May.
Jacopo
On Apr 24, 2013, at 10:49 AM, Jacques Le Roux
wrote:
> Agreed on the plan. Indeed if in may, 13.05 should be the way.
> Just to say: I will not be available (v
Agreed on the plan. Indeed if in may, 13.05 should be the way.
Just to say: I will not be available (vacation) at the end of week and next
week. Anyway I have nothing pending.
Jacques
From: "Adrian Crum"
>I would like to postpone creation of the branch until I finish fixing
> the entity condi
I would like to postpone creation of the branch until I finish fixing
the entity condition cache problems. I should have it finished this weekend.
If we create the branch in May, then I think the branch should be
labeled according to the pattern we agreed upon earlier - 13.05.
-Adrian
On 4/2
Are we ready to create the new branch or we want to postpone it?
Based on what we discussed recently, the plan could be the following:
* before the end of April, create a branch (13.04) as a snapshot of the trunk
and without all specialpurpose components (except the ecommerce component that
will
18 matches
Mail list logo
