+1 and the committer should leave the ticket open with the comment 'Need to
backport the issue to the previous versions'
Thanks & Regards,
Devanshu Vyas.
On Mon, Jul 10, 2017 at 5:32 PM, Michael Brohl
wrote:
> Hi everyone,
>
> I think we should setup some kind of policy for the bugfixing in
We have developed a test component called growerptest which uses
webdriver with configuration in xml files separating re-usable
commandstepgroups and testdata. The component uses the ofbiz test hook
to integrate it with the standard junit tests
all available at
https://gerrit.antwebsystems.com
I'll refrain to speak about swallowed exceptions ;)
I still want to continue on OFBIZ-8341 but accepted to get sidetracked in multi
ways :)
Jacques
Le 10/07/2017 à 21:36, Taher Alkhateeb a écrit :
Fixed it in the JIRA, the EntitySaxReader (should be the next class to
refactor) is logging an
Fixed it in the JIRA, the EntitySaxReader (should be the next class to
refactor) is logging an error but suppressing an exception. The logic
for "continue-on-error" had to go 3 classes deep to work correctly. I
always underestimate how much spaghetti code we have :)
On Mon, Jul 10, 2017 at 8:14 PM
Quick update, to my surprise an exception is swallowed
dp in the call stack. So getting this
feature might require some intrusive changes. I'm still working on it
and will keep you posted, but as of right now, no exception is
bubbling up to be caught with "continue-on-fa
Hi Jacques,
I'll wait a few days if there are any objections and take care of it then.
Michael
Am 10.07.17 um 16:27 schrieb Jacques Le Roux:
If we agree (I guess we do) then we should update the committer page
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Respo
If we agree (I guess we do) then we should update the committer page
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities
Thanks
Jacques
Le 10/07/2017 à 15:05, Michael Brohl a écrit :
Additional idea: we can also flag the issue with a label "backport-
Additional idea: we can also flag the issue with a label
"backport-needed" to easily find open issues which need a backport.
Am 10.07.17 um 14:55 schrieb Jacques Le Roux:
+1 for leaving open with a comment
Jacques
Le 10/07/2017 à 14:19, Deepak Dixit a écrit :
+1 , I think instead of openin
+1 for leaving open with a comment
Jacques
Le 10/07/2017 à 14:19, Deepak Dixit a écrit :
+1 , I think instead of opening new issue, we can leave it open with
comment
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Mon, Jul 10, 2017 at 5:32 PM, Michael Brohl
wrote:
+1 , I think instead of opening new issue, we can leave it open with
comment
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Mon, Jul 10, 2017 at 5:32 PM, Michael Brohl
wrote:
> Hi everyone,
>
> I think we should setup some kind of policy for the bugfixing in the
> pro
Hi everyone,
I think we should setup some kind of policy for the bugfixing in the
project.
While every committer is free to decide if he does a backport himself,
we should make sure that bugfixes go into the supported release branches
also.
I propose to define the following policies:
1. b
Thank you everyone for your feedback, I will let this discussion
continue for a few days before committing anything (testing is going
to take some time anyway).
Now, I need help, I have a big patch in [1] that does what we
discussed in this thread and a whole lot more. If you have the time, I
real
Rishi,
yes, that's what I am proposing.
I'll create the page, it should serve as an Index page for the case
It would be cool if we can collect some more cases studies here.
Thanks,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 10.07.17 um 12:46 schrieb Rishi Solanki:
Thanks Michael,
Just t
I agree with option #3 and the 'continue-on-failure' flag with default
value=false. :)
Thanks & Regards,
Devanshu Vyas.
On Mon, Jul 10, 2017 at 3:07 PM, Taher Alkhateeb wrote:
> Hi Rishi,
>
> So my suggestion is that if anything does not load, then immediately fail.
>
> Why am I suggesting this
Thanks Michael,
Just to be super clear you are proposing;
Instead of moving to here: Document > Case Studies > Brewing with OFBiz at
a small or medium sized brewery
Better place is: Community/ References/ Case Studies > Brewing with OFBiz
at a small or medium sized brewery
And in case anyone wa
Thanks Taher for your reply. I was just pushing the types to set some type
of data as in ignoring. But, now I am completely agree with you on point
"The data will automatically get cleaned by committers because no failing
data will be committed to the code base".
Again +1 for #3 with option contin
+1
Michael
Am 10.07.17 um 07:03 schrieb Taher Alkhateeb:
Historically the data loader boolean props are false if ommitted and the
code expects that, but you have a point about the double negative. We can
instead call it "continue-on-failure" for example.
On Jul 10, 2017 3:48 AM, "Paul Foxworth
Hi Rishi,
it's a good idea to move this out of the Uses Cases Library. I think
that it does not belong in the documentation section at all.
The documentation section should, after the restructure, only contain
documentation which belongs to the core OFBiz system.
I propose to move this to C
Hi Rishi,
So my suggestion is that if anything does not load, then immediately fail.
Why am I suggesting this?
- You have to intentionally ignore data failure after being aware of
it (it does not slip between the cracks)
- The data will automatically get cleaned by committers because no
failing d
I'm good to go with option #3 and continue-on-failure.
Just wanted to mention one thing here; for which type of data we will be
failing build. That means, we have several options seed, ext, demo. Do we
need to discuss these points or we are fine for all type of data. Like demo
data fails only affe
> Historically the data loader boolean props are false if ommitted and the
> code expects that, but you have a point about the double negative. We can
> instead call it "continue-on-failure" for example.
>
+1 continue-on-failure with default value false
Thanks & Regards
--
Deepak Dixit
www.hotwax
On Mon, Jul 10, 2017 at 7:03 AM, Taher Alkhateeb wrote:
> Historically the data loader boolean props are false if ommitted and the
> code expects that, but you have a point about the double negative. We can
> instead call it "continue-on-failure" for example.
+1
On 10 July 2017 at 15:03, Taher Alkhateeb
wrote:
> Historically the data loader boolean props are false if ommitted and the
> code expects that, but you have a point about the double negative. We can
> instead call it "continue-on-failure" for example.
>
Hi Taher,
I'm happy with that.
Cheers
Option 3 with with a default value of "false" for "continue-on-failure is fine
with me
Jacques
Le 10/07/2017 à 07:03, Taher Alkhateeb a écrit :
Historically the data loader boolean props are false if ommitted and the
code expects that, but you have a point about the double negative. We can
in
24 matches
Mail list logo