Re: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

2016-10-18 Thread Arun Patidar 
Thanks Jacques.

-- 
Thanks & Regards
---
Arun Patidar
Manager,Enterprise Software Development
HotWax Mediawww.hotwaxsystems.com


On Tue, Oct 18, 2016 at 2:14 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Arun,
>
> Inline...
>
> Le 17/10/2016 à 18:30, Arun Patidar a écrit :
>
>> Hi Jacques,
>>
>> Thanks for looking into this and help. I agree with your concern that it
>> is
>> hard to review many subtickets.
>>
>
> Actually I don't review patches when they are so many and *especially*
> dispatched with so *many subtasks.* It would be quite a waste of time (Jira
> is not always responding quickly if you see what I mean, and yes this is an
> euphemism ;))
> I wait they are committed and then review commits.
>
> Also it would be more easy to apply/review
>> patch from one relevant ticket. For the same reason I started commiting
>> multiple patches from different ticket in one commit.
>>
>
> That does not change much for the reviews. It's just slightly easier,
> because you have not to open several commits emails. I still appreciate :)
>
> The reason behind the current approach with OFBIZ-7828 is that, on
>> community day multiple people can work on different part of a same ticket.
>> Devs working on subtickets are responsible for development, self review
>> and
>> testing. Small chunks facilitate devs to follow this procedure for each
>> entity. So we can say, all services added till now completely tested from
>> webtools by devs.
>>
>
> OK, I can understand that, and I also remember myself for advocating on
> doing so. It was though when things are complicated.  But then anyway I'll
> simply not help but will continue to review
>
> So its easy to do distributed efforts on this long on going ticket by
>> sub-tickets. And for reviewing purpose I started committing multiple
>> tickets in single commit. I'll continue on picking multiple tickets and do
>> single commit.
>>
>
> Sounds good to me, thanks for your answer
>
> Jacques
>
>

Re: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

2016-10-18 Thread Jacques Le Roux 

Hi Arun,

Inline...

Le 17/10/2016 à 18:30, Arun Patidar a écrit :

Hi Jacques,

Thanks for looking into this and help. I agree with your concern that it is
hard to review many subtickets.


Actually I don't review patches when they are so many and *especially* dispatched with so *many subtasks.* It would be quite a waste of time (Jira is 
not always responding quickly if you see what I mean, and yes this is an euphemism ;))

I wait they are committed and then review commits.


Also it would be more easy to apply/review
patch from one relevant ticket. For the same reason I started commiting
multiple patches from different ticket in one commit.


That does not change much for the reviews. It's just slightly easier, because 
you have not to open several commits emails. I still appreciate :)


The reason behind the current approach with OFBIZ-7828 is that, on
community day multiple people can work on different part of a same ticket.
Devs working on subtickets are responsible for development, self review and
testing. Small chunks facilitate devs to follow this procedure for each
entity. So we can say, all services added till now completely tested from
webtools by devs.


OK, I can understand that, and I also remember myself for advocating on doing so. It was though when things are complicated.  But then anyway I'll 
simply not help but will continue to review



So its easy to do distributed efforts on this long on going ticket by
sub-tickets. And for reviewing purpose I started committing multiple
tickets in single commit. I'll continue on picking multiple tickets and do
single commit.


Sounds good to me, thanks for your answer

Jacques

Re: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

2016-10-17 Thread Arun Patidar 
Hi Jacques,

Thanks for looking into this and help. I agree with your concern that it is
hard to review many subtickets. Also it would be more easy to apply/review
patch from one relevant ticket. For the same reason I started commiting
multiple patches from different ticket in one commit.

The reason behind the current approach with OFBIZ-7828 is that, on
community day multiple people can work on different part of a same ticket.
Devs working on subtickets are responsible for development, self review and
testing. Small chunks facilitate devs to follow this procedure for each
entity. So we can say, all services added till now completely tested from
webtools by devs.

So its easy to do distributed efforts on this long on going ticket by
sub-tickets. And for reviewing purpose I started committing multiple
tickets in single commit. I'll continue on picking multiple tickets and do
single commit.


-- 
Thanks & Regards
---
Arun Patidar
Manager,Enterprise Software Development
HotWax Mediawww.hotwaxsystems.com


On Sun, Oct 16, 2016 at 3:46 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I have a proposition about tasks with many trivial subtasks like
> OFBIZ-8413, OFBIZ-7828 or OFBIZ-7334, etc.
>
> When I look at https://issues.apache.org/jira
> /secure/Dashboard.jspa?selectPageId=12310800 I see that we have some
> difficulties to cope with all these subtasks
>
> Yesterday, while reviewing one related commit by Arun with 20 subtasks
> embedded : http://svn.apache.org/viewvc?view=revision=1765077
>
> I wanted to help on OFBIZ-7828 but it's really a pain to
>
> 1. open so many subtasks
> 2. download the patches
> 3. apply them one by one
>
> When it's actually so easy to review the commit Arun did, so it would be
> the same before committing.
>
> So I suggest we don't create so many subtasks when they are trivial. We
> could rather create component, class or alike named patches and attach them
> to only 1 Jira.
>
> Then using a tool to download simultaneously a bunch of files from a page
> (I use http://www.downthemall.net/) and catenate them in one file it's
> very easy to achieve the same.
>
> Jacques
>
>
>
> Le 25/09/2016 à 09:42, Jacques Le Roux a écrit :
>
>> I have proposed a remedy with my answer in a new thread forked from the
>> flat grey vote one.
>>
>> BTW, what are you opinions on the "Community Days" and  alike days by
>> HotWax?
>>
>> I understand they happen on weekends when people have more spare time and
>> it's amazing to see people working together.
>> So I much appreciate the result of these days, but I find hard to follow
>> and review those bursts of activity.
>>
>> I have though nothing to remedy that, apart delaying reviews which is not
>> always a good solution.
>> Because it's sometimes too late when commits results are entangled and
>> then hard to ask to revert.
>>
>> Jacques
>>
>>
>> Le 25/09/2016 à 01:44, Scott Gray a écrit :
>>
>>> As an aside to this, and also what I mentioned in the flat grey vote
>>> thread:
>>>
>>> I think you rely on lazy consensus too much.  Not many contributors have
 as much time as you to give to the project and formulating an argument
 against something (and then continuing the discussion) can take up a
 lot of
 time and energy.  In my experience people are generally very quick to
 agree
 to good ideas (because it takes no effort other than to reply +1) so if
 you
 get *no* responses then you should IMO take pause before pushing ahead.

 Out of curiosity I took a look at your activity this month:
>>> 24 discussion begun
>>> 11 commits that triggered a discussion
>>> 80 other commits that presumably required some level of review
>>>
>>> While your contributions are appreciated, please be aware of the burden
>>> this high level of activity places on the rest of the active contributors
>>> and the time consumed is time that those contributors could be putting
>>> into
>>> pursuing their own priorities.
>>>
>>> Given this, do you really think it is fair to get annoyed when people
>>> don't
>>> respond quickly enough for you?  Does it seem wise to apply lazy
>>> consensus
>>> to decisions that don't receive much feedback?
>>>
>>> Regards
>>> Scott
>>>
>>> On 25 September 2016 at 11:00, Scott Gray 
>>> wrote:
>>>
>>> Calm down Jacques, I'm sure Michael will respond when he has a chance.
 This isn't a big deal and I don't see why there would be any rush to
 fill
 your request.

 Regards
 Scott

 On 23 September 2016 at 21:38, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 After 4 days clearly nobody cares. I guess Michael does not want to
> "open
> source" his process and nobody cares about having this information
> monthly
> in the blog or not.
>
> Closed
>
> Jacques
>
>
>
> Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :
>
> Hi All, Michael,
>>
>> Like we have a

Re: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

2016-10-16 Thread Jacques Le Roux 

I have a proposition about tasks with many trivial subtasks like OFBIZ-8413, 
OFBIZ-7828 or OFBIZ-7334, etc.

When I look at https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12310800 I see that we have some difficulties to cope with all these 
subtasks


Yesterday, while reviewing one related commit by Arun with 20 subtasks embedded : 
http://svn.apache.org/viewvc?view=revision=1765077

I wanted to help on OFBIZ-7828 but it's really a pain to

1. open so many subtasks
2. download the patches
3. apply them one by one

When it's actually so easy to review the commit Arun did, so it would be the 
same before committing.

So I suggest we don't create so many subtasks when they are trivial. We could rather create component, class or alike named patches and attach them to 
only 1 Jira.


Then using a tool to download simultaneously a bunch of files from a page (I use http://www.downthemall.net/) and catenate them in one file it's very 
easy to achieve the same.


Jacques


Le 25/09/2016 à 09:42, Jacques Le Roux a écrit :

I have proposed a remedy with my answer in a new thread forked from the flat 
grey vote one.

BTW, what are you opinions on the "Community Days" and  alike days by HotWax?

I understand they happen on weekends when people have more spare time and it's 
amazing to see people working together.
So I much appreciate the result of these days, but I find hard to follow and 
review those bursts of activity.

I have though nothing to remedy that, apart delaying reviews which is not 
always a good solution.
Because it's sometimes too late when commits results are entangled and then 
hard to ask to revert.

Jacques


Le 25/09/2016 à 01:44, Scott Gray a écrit :

As an aside to this, and also what I mentioned in the flat grey vote thread:


I think you rely on lazy consensus too much.  Not many contributors have
as much time as you to give to the project and formulating an argument
against something (and then continuing the discussion) can take up a lot of
time and energy.  In my experience people are generally very quick to agree
to good ideas (because it takes no effort other than to reply +1) so if you
get *no* responses then you should IMO take pause before pushing ahead.


Out of curiosity I took a look at your activity this month:
24 discussion begun
11 commits that triggered a discussion
80 other commits that presumably required some level of review

While your contributions are appreciated, please be aware of the burden
this high level of activity places on the rest of the active contributors
and the time consumed is time that those contributors could be putting into
pursuing their own priorities.

Given this, do you really think it is fair to get annoyed when people don't
respond quickly enough for you?  Does it seem wise to apply lazy consensus
to decisions that don't receive much feedback?

Regards
Scott

On 25 September 2016 at 11:00, Scott Gray 
wrote:


Calm down Jacques, I'm sure Michael will respond when he has a chance.
This isn't a big deal and I don't see why there would be any rush to fill
your request.

Regards
Scott

On 23 September 2016 at 21:38, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


After 4 days clearly nobody cares. I guess Michael does not want to "open
source" his process and nobody cares about having this information monthly
in the blog or not.

Closed

Jacques



Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :


Hi All, Michael,

Like we have a dedicated page for releases creation[1] in wiki, and
though it's of less importance, I think we should have a such page for the
"monthly Jira issues list" creation in the blog

Currently it's done by Michael, based on a work he previously did and
continue to do but only in German (eg https://www.ecomify.de/blog/ap
ache-ofbiz-news-august-2016-1250/)

It should be at least documented in order to not only depend on Michael
but to also possibly lighten the burden brought on him.

I know you voluntarily proposed to do it Michael, and again I thank you
for that!

Unfortunately this adds again some burden on you, because AFAIK you are
currently the one person able to create this wiki page. Thanks!

[1] https://cwiki.apache.org/confluence/display/OFBADMIN/Release
+Management+Guide+for+OFBiz

Jacques

Re: Wiki page for the "monthly Jira issues list" creation in the blog

2016-10-06 Thread Michael Brohl 

Thanks, Jacques,

appreciated!

Regards,

Michael


Am 06.10.16 um 13:36 schrieb Jacques Le Roux:
OK, nobody seems to love my idea of having the choice to pick between 
eg Fix, Fixes or Fixed.

And Fixed is accepted/used by everyone.

My goal was not to make things harder to Michael when he creates the 
monthly Jira issues list in the OFBiz blog; but to offer more 
flexibility  for committers when creating their commits messages.


So I have decided to use the same than everyone and so I'll soon 
commit an adapted tsvn:logtemplatecommit


Jacques


Le 25/09/2016 à 00:00, Scott Gray a écrit :

Calm down Jacques, I'm sure Michael will respond when he has a chance.
This isn't a big deal and I don't see why there would be any rush to 
fill

your request.

Regards
Scott

On 23 September 2016 at 21:38, Jacques Le Roux

Re: Wiki page for the "monthly Jira issues list" creation in the blog

2016-10-06 Thread Jacques Le Roux 

OK, nobody seems to love my idea of having the choice to pick between eg Fix, 
Fixes or Fixed.
And Fixed is accepted/used by everyone.

My goal was not to make things harder to Michael when he creates the monthly Jira issues list in the OFBiz blog; but to offer more flexibility  for 
committers when creating their commits messages.


So I have decided to use the same than everyone and so I'll soon commit an 
adapted tsvn:logtemplatecommit

Jacques


Le 25/09/2016 à 00:00, Scott Gray a écrit :

Calm down Jacques, I'm sure Michael will respond when he has a chance.
This isn't a big deal and I don't see why there would be any rush to fill
your request.

Regards
Scott

On 23 September 2016 at 21:38, Jacques Le Roux

Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

2016-09-25 Thread Jacques Le Roux 

I have proposed a remedy with my answer in a new thread forked from the flat 
grey vote one.

BTW, what are you opinions on the "Community Days" and  alike days by HotWax?

I understand they happen on weekends when people have more spare time and it's 
amazing to see people working together.
So I much appreciate the result of these days, but I find hard to follow and 
review those bursts of activity.

I have though nothing to remedy that, apart delaying reviews which is not 
always a good solution.
Because it's sometimes too late when commits results are entangled and then 
hard to ask to revert.

Jacques


Le 25/09/2016 à 01:44, Scott Gray a écrit :

As an aside to this, and also what I mentioned in the flat grey vote thread:


I think you rely on lazy consensus too much.  Not many contributors have
as much time as you to give to the project and formulating an argument
against something (and then continuing the discussion) can take up a lot of
time and energy.  In my experience people are generally very quick to agree
to good ideas (because it takes no effort other than to reply +1) so if you
get *no* responses then you should IMO take pause before pushing ahead.


Out of curiosity I took a look at your activity this month:
24 discussion begun
11 commits that triggered a discussion
80 other commits that presumably required some level of review

While your contributions are appreciated, please be aware of the burden
this high level of activity places on the rest of the active contributors
and the time consumed is time that those contributors could be putting into
pursuing their own priorities.

Given this, do you really think it is fair to get annoyed when people don't
respond quickly enough for you?  Does it seem wise to apply lazy consensus
to decisions that don't receive much feedback?

Regards
Scott

On 25 September 2016 at 11:00, Scott Gray 
wrote:


Calm down Jacques, I'm sure Michael will respond when he has a chance.
This isn't a big deal and I don't see why there would be any rush to fill
your request.

Regards
Scott

On 23 September 2016 at 21:38, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


After 4 days clearly nobody cares. I guess Michael does not want to "open
source" his process and nobody cares about having this information monthly
in the blog or not.

Closed

Jacques



Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :


Hi All, Michael,

Like we have a dedicated page for releases creation[1] in wiki, and
though it's of less importance, I think we should have a such page for the
"monthly Jira issues list" creation in the blog

Currently it's done by Michael, based on a work he previously did and
continue to do but only in German (eg https://www.ecomify.de/blog/ap
ache-ofbiz-news-august-2016-1250/)

It should be at least documented in order to not only depend on Michael
but to also possibly lighten the burden brought on him.

I know you voluntarily proposed to do it Michael, and again I thank you
for that!

Unfortunately this adds again some burden on you, because AFAIK you are
currently the one person able to create this wiki page. Thanks!

[1] https://cwiki.apache.org/confluence/display/OFBADMIN/Release
+Management+Guide+for+OFBiz

Jacques

Re: Wiki page for the "monthly Jira issues list" creation in the blog

2016-09-24 Thread Scott Gray 
As an aside to this, and also what I mentioned in the flat grey vote thread:

> I think you rely on lazy consensus too much.  Not many contributors have
> as much time as you to give to the project and formulating an argument
> against something (and then continuing the discussion) can take up a lot of
> time and energy.  In my experience people are generally very quick to agree
> to good ideas (because it takes no effort other than to reply +1) so if you
> get *no* responses then you should IMO take pause before pushing ahead.
>

Out of curiosity I took a look at your activity this month:
24 discussion begun
11 commits that triggered a discussion
80 other commits that presumably required some level of review

While your contributions are appreciated, please be aware of the burden
this high level of activity places on the rest of the active contributors
and the time consumed is time that those contributors could be putting into
pursuing their own priorities.

Given this, do you really think it is fair to get annoyed when people don't
respond quickly enough for you?  Does it seem wise to apply lazy consensus
to decisions that don't receive much feedback?

Regards
Scott

On 25 September 2016 at 11:00, Scott Gray 
wrote:

> Calm down Jacques, I'm sure Michael will respond when he has a chance.
> This isn't a big deal and I don't see why there would be any rush to fill
> your request.
>
> Regards
> Scott
>
> On 23 September 2016 at 21:38, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> After 4 days clearly nobody cares. I guess Michael does not want to "open
>> source" his process and nobody cares about having this information monthly
>> in the blog or not.
>>
>> Closed
>>
>> Jacques
>>
>>
>>
>> Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :
>>
>>> Hi All, Michael,
>>>
>>> Like we have a dedicated page for releases creation[1] in wiki, and
>>> though it's of less importance, I think we should have a such page for the
>>> "monthly Jira issues list" creation in the blog
>>>
>>> Currently it's done by Michael, based on a work he previously did and
>>> continue to do but only in German (eg https://www.ecomify.de/blog/ap
>>> ache-ofbiz-news-august-2016-1250/)
>>>
>>> It should be at least documented in order to not only depend on Michael
>>> but to also possibly lighten the burden brought on him.
>>>
>>> I know you voluntarily proposed to do it Michael, and again I thank you
>>> for that!
>>>
>>> Unfortunately this adds again some burden on you, because AFAIK you are
>>> currently the one person able to create this wiki page. Thanks!
>>>
>>> [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Release
>>> +Management+Guide+for+OFBiz
>>>
>>> Jacques
>>>
>>>
>>>
>>
>

Re: Wiki page for the "monthly Jira issues list" creation in the blog

2016-09-24 Thread Scott Gray 
Calm down Jacques, I'm sure Michael will respond when he has a chance.
This isn't a big deal and I don't see why there would be any rush to fill
your request.

Regards
Scott

On 23 September 2016 at 21:38, Jacques Le Roux  wrote:

> After 4 days clearly nobody cares. I guess Michael does not want to "open
> source" his process and nobody cares about having this information monthly
> in the blog or not.
>
> Closed
>
> Jacques
>
>
>
> Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :
>
>> Hi All, Michael,
>>
>> Like we have a dedicated page for releases creation[1] in wiki, and
>> though it's of less importance, I think we should have a such page for the
>> "monthly Jira issues list" creation in the blog
>>
>> Currently it's done by Michael, based on a work he previously did and
>> continue to do but only in German (eg https://www.ecomify.de/blog/ap
>> ache-ofbiz-news-august-2016-1250/)
>>
>> It should be at least documented in order to not only depend on Michael
>> but to also possibly lighten the burden brought on him.
>>
>> I know you voluntarily proposed to do it Michael, and again I thank you
>> for that!
>>
>> Unfortunately this adds again some burden on you, because AFAIK you are
>> currently the one person able to create this wiki page. Thanks!
>>
>> [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Release
>> +Management+Guide+for+OFBiz
>>
>> Jacques
>>
>>
>>
>

Re: Wiki page for the "monthly Jira issues list" creation in the blog

2016-09-23 Thread Jacques Le Roux 
After 4 days clearly nobody cares. I guess Michael does not want to "open source" his process and nobody cares about having this information monthly 
in the blog or not.


Closed

Jacques


Le 19/09/2016 à 10:26, Jacques Le Roux a écrit :

Hi All, Michael,

Like we have a dedicated page for releases creation[1] in wiki, and though it's of less importance, I think we should have a such page for the 
"monthly Jira issues list" creation in the blog


Currently it's done by Michael, based on a work he previously did and continue to do but only in German (eg 
https://www.ecomify.de/blog/apache-ofbiz-news-august-2016-1250/)


It should be at least documented in order to not only depend on Michael but to 
also possibly lighten the burden brought on him.

I know you voluntarily proposed to do it Michael, and again I thank you for 
that!

Unfortunately this adds again some burden on you, because AFAIK you are 
currently the one person able to create this wiki page. Thanks!

[1] 
https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Management+Guide+for+OFBiz

Jacques