Administrator
|
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 |
Administrator
|
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 > > |
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 <[hidden email] > 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 >> >> >> > |
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 <[hidden email]> 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 < > [hidden email]> 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 >>> >>> >>> >> > |
Administrator
|
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 <[hidden email]> > 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 < >> [hidden email]> 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 >>>> >>>> >>>> |
Administrator
|
In reply to this post by Scott Gray-3
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 <[hidden email] >> 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 >>> >>> >>> |
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 >> <[hidden email] >>> 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 >>>> >>>> >>>> > smime.p7s (5K) Download Attachment |
Administrator
|
In reply to this post by 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&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 <[hidden email]> >> 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 < >>> [hidden email]> 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 >>>>> >>>>> >>>>> > > |
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 < [hidden email]> 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 <[hidden email]> >>> 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 < >>>> [hidden email]> 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 >>>>>> >>>>>> >>>>>> >>>>>> >> >> > |
Administrator
|
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 |
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 < [hidden email]> 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 > > |
Free forum by Nabble | Edit this page |