You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2016/09/25 07:42:14 UTC

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

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 <sc...@hotwaxsystems.com>
> 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.roux@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: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

Posted by Arun Patidar <ar...@hotwaxsystems.com>.
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.roux@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]

Posted by Jacques Le Roux <ja...@les7arts.com>.
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]

Posted by Arun Patidar <ar...@hotwaxsystems.com>.
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.roux@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&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 <sc...@hotwaxsystems.com>
>>> 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.roux@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: Opinions on the "Community Days" and alike days by HotWax [Was Re: Wiki page for the "monthly Jira issues list" creation in the blog]

Posted by Jacques Le Roux <ja...@les7arts.com>.
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&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 <sc...@hotwaxsystems.com>
>> 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.roux@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
>>>>>
>>>>>
>>>>>
>
>